TeamTopologies
As someone who used to be part of a platform team, and is now actively working in the same organization to fight the creation of any more platform teams, I very much disagree with the article that this is a good working model.<p>What we have found is that platform teams are a huge point of frustration for product teams, since they cause unnecessary and unmanageable coupling between different business divisions, leading to impossible to balance priorities. What we&#x27;ve seen happen over and over is that product A needs Feature A, and product B needs Feature B, and they both need it tomorrow, and the platform team only has resources for one. And since Product A and Product B are in different business divisions, you end up needing to involve a senior VP or even an officer to make a prioritization decision for a simple software feature, and everyone gets frustrated by the process.<p>What we&#x27;re striving towards instead is an &quot;inner source&quot; model, where a platform is collaboratively developped and maintained by multiple product teams. Each product team is then empowered to build new features as needed into the platform, and others can reuse them.<p>Of course, the platform needs some architects and overall review, and all teams will not equally participate. But the key point is to encourage this collaboration mode, where no one team is a bottleneck for multiple products.<p>The inspiration for this structure is obviously the open-source world, where multiple corporations and foundations collaborate on a single code base without needing to rely on a single platform vendor to provide features for them.