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.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'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.What we're striving towards instead is an "inner source" 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.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.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.