I recognise the friction points very well. It's very frustrating and limits product team velocity. That said, in my experience this is mainly due to a misinterpretation and mis-implementation of platform teams. Too often, platform teams are forced upon product teams. This misses an essential element of a platform, optionality. A platform should be a jumping board, that people can choose to accelerate development. When a platform is made mandatory it misses essential feedback mechanisms, such as rate of adoption, for it to steer in the right direction. While the rate of adoption is still often seen as a metric for a platform team's success, the mandate to enforce the platform onto product teams is fundamentally corrupting. In addition, the tools to truly accelerate development are not the same as time progresses. Without optionality, there is never the incentive to sunset anything the platform provides. Deviations of technology/pattern/solution use are often seen as negative aspects of the product team's performance, but rarely reflect back on the platform team's output.TLDR; platform teams without product team's freedom to deviate (optionality) is corrupt and can destroy a large chunk of engineering velocity.
tsimionescu|2 years ago
frankdejonge|2 years ago
Sorry in advanced if I state this a little bluntly, but this rhetoric of teams going off and building the same tools all over the place is in my experience not a fault of any team, it's that of the context/organisation they operate in. Framing it as such is IMO destructive for company culture. As if product teams, left to their own, will just degrade into building sub-par platform-esk tools that ruin the org. I don't buy it. Trying to make one thing do two things (the single source of tech complexity) is a trap often catching platform engineers who try to tailor to an audience that is not unified in their needs, still platform teams are incentivised to create just that.