[frankdejonge]

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]

That is one important aspect, absolutely. But I don't think it's the main point. There are normally good reasons for which the platform itself is necessary and useful. Working around it, while a good option to have, is rarely ideal - or else you fall back to the model where every team invents and builds its own tools. Renouncing (or worse, forking) the whole platform because a feature can't be prioritized to be added to it is not exactly a great outcome.

[frankdejonge]

If you fall into the case where every team is forced to work around the platform and create their own solution, the problem is not enforcement, it's offering. The thing that is offered is not working for the teams and there is a negative impact because of it. Teams building their own solutions, for a while, after which they are consolidated into a platform offering is a healthy cycle. What is IMO unhealthy is a dysfunctional platform where product people are forced to endure it. I'd much rather empower teams to take on their own impediments then to suck away their motivation by not letting them fix whatever is holding them back.

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.

[tsimionescu]

I think we are mostly in agreement - platforms are good, but they should be driven by product teams who see value in them and feel empowered to improve and maintain them when needed. Whether there is also a dedicated platform team or it is more of a group collaboration between product teams is ultimately a detail, as long as the product teams do participate in building and maintaining the platform.