I recognize this problem, although my experience was a lot worse. It seems to me that this one is very, very hard for many people to realize: > Platform teams,

I recognize this problem, although my experience was a lot worse. It seems to me that this one is very, very hard for many people to realize: > Platform teams, however, need to build their services as products themselves, with a deep understanding of their customer's needs. If there is no malfunction like a monopoly or a scam, as a customer I just choose a different product if one is not meeting my needs. The same must be true of a platform, and if it happens a lot that its customers are choosing something else then its time for some hard reflection. This is not just an ideal, but a hard requirement, and something that a lot of orgs just don't have. So, what do I need as a developer? I can make excellent use of open source libraries within even a couple of minutes, but somehow for my enterprise platform I need to fire up a request and wait for weeks or months to even get to play with it. When I need a tiny little change I can't do anything myself, I need to request it and it is filed in the backlog. The same change, would I have composed it out of open source libraries or had cloud access myself, I could make in minutes. Now it takes days, weeks and I even experienced many months of waiting for a simple task I can do in 5 minutes. Thus, making use of the platform meant fighting for higher cloud privileges so we could do it ourselves and ship at least within a couple of month instead of a year, and dancing around bizarre compliance regulations, mostly in order to either evade or pleasing a chain of risk owners to satisfy audits required for certification. At some point we became almost incapable of shipping. Not every platform team is as kafkaesque as this though, and it doesn't need to be. We tried inner sourcing as well and it was quite hard honestly, because each team was just focused on their own goals and contributing to the shared platform or libraries was often an extra investment that defacto penalized their achievements - which _did_ have repercussions on their individual performance reviews. Furthermore, it was done in such an ad-hoc way that it was quite hard to get something sane off the ground. I think you do need a kind of dedicated ownership. Best experience was in a team where we did everything ourselves and had the required expertise. Second-best was in really close collaboration with a platform team where we also had members going from one team to the other. But even that team failed to build the features we really needed as a product team. Open source is a good model, and there is one essential thing that platform teams need to provide their users that open source has: autonomy. I have actually never seen this in a platform team in the org I am talking about. I can use a library, drop it, change it or exchange it for another one. The same _must_ be possible with a platform. It needs to be something that helps its users, not limits them in any way, and it can't ever be rammed down their throats. If your platform doesn't work for me, I should have the autonomy to just use a third party to get the job done. If your magic abstraction over AWS doesn't work, give me an AWS account with admin access and I do it myself. Bonus points if its not an all-or-nothing and I can just use what works and build the rest myself. If you don't have time to build feature B because feature A is more important, everything I need to build feature B myself should be readily available. For example, I must be able to just fork the platform, build feature B, and when done 'upstream' it to the platform again.