I had a really bad experience in an organisation possessed by a platform team. A small number of individuals were rolling change after change that impacted hundreds of engineers, halving their productivity and halting all development to a grind once a month.
This is a typical challenge for platform teams. Because they are responsible for the underlying foundation on which applications are build, a mistake can easily impact all those applications.
An important realization in my opinion is that a platform team is just another development team. They should consider their platform as a product and the developers as their customers. To minimize any downtime they should use the typical mechanisms that developers are also using: automated tests, pair programming, rolling out changes to test environments first, etc.
I'm sorry to hear that as someone who has done this role in the past I can tell you that it's the opposite of what a platform team should be doing.
When done right a platform team should basically not be noticed except that the tooling, developer experience and overall reliability of a system goes up.
«When done right a platform team should basically not be noticed except that the tooling, developer experience and overall reliability of a system goes up.»
Did the platform team use their own platform? I have a theory that that's the right way to set up incentives, but I'm curious whether it works in practice.
