Six Sins of Platform Teams
Platform teams are very common these days, and the approach has been widely adopted. When implemented successfully, platform teams become huge force multipliers, delivering a tremendous amount of value. But as with any engineering approach, there are common anti-patterns, let’s call them "sins", that can limit their potential. As someone who's been in various platform engineering roles and has committed many of these sins myself, I’ve built a certain mental model of the common sins that platform teams might commit and formed some opinions on how the sins can be avoided. And in this article, I’ll share this mental model with you.
I’ll go through the sins in their natural order and, for each one, I’ll suggest a possible solution. Note that I won’t be focusing on the surface issues that have largely been discussed already, e.g. excessive toil. Instead, I’ll focus on more subtle sins – the ones that don't immediately manifest themselves but that you can see if you know what to look for.
Before going further, let’s disambiguate the terminology, as platform teams is a very overloaded term. Within the scope of this article, platform teams are a way to implement the DevOps methodology at scale. The product teams are ultimately responsible for the complete lifecycle of the software they build, while being supported by platform teams. Even though there’s still a role separation, like in the pre-DevOps dev-and-sysadmin world, both platform and product teams take a software-first approach. Platform teams abstract the cross-cutting concerns into reusable platform components, helping product teams move faster while preserving their end-to-end ownership.
