A simple idea is at the core of this post: to scale an organization of full-stack multi-disciplinary product teams in a sustainable way, we should move the common into central teams and keep the special in the product teams.
DevOps or Perspective X?
But I am getting ahead of myself. First, I feel the need to explain what I understand through some of the terms in the title. Let's start with the elephant in it: DevOps. There are out there essentially two quite different perspectives on what DevOps is:
Operations teams are more dev-y. DevOps teams full of DevOps engineers build infrastructure and tooling using all kind of scripting languages and YAML (🤡) based tools. These teams have names that many times include words like cloud, Kubernetes, infrastructure, reliability, and many others.
All teams are DevOps teams that own a full slice of a product, and each team is responsible for this slice end-to-end (from dev to ops and more).
And before you say it, both 1 and 2 are severe simplifications of their representations in the world, but I find these good enough for making my next points and the implications of these statements should complete the picture.
Before going further, I want to specify that I am a supporter of the second perspective, even though the first one seems quite more common (go on and search for how many jobs for DevOps Engineers are out there).
But even if we call perspective 2 DevOps or Perspective X, I hope we can agree that Perspective X is a desirable outcome, and we want to have teams like that as a company continues to grow.
Platform teams to the rescue!
Moving on, so DevOps or Perspective X should describe every product team. How can we scale the company full of these kind of product teams without having each of them re-inventing the wheel? And how can we keep the resulting work of the teams still be consistent (at least on some aspects)? One of the options that makes sense (to me) is to put common concerns for all or some of the teams into other teams, let's call these teams platform teams.
Note: In my view, the first perspective on DevOps I mentioned above actually describes a category of platform teams.
Platform teams build, well, platforms that are used by other internal teams. These platforms can be anything from an API, a SaaS, a framework, documentation, infrastructure platform, a service, you name it. In the same way we think of salaries that are calculated and paid centralised for the whole company or how we manage IT equipment, we should think of any other common concerns for teams. I really think this way of thinking can be applied for many concerns in the company and by applying this simple idea we can accelerate growth and make the company run smoother. BUT! There is a big but here, as we will discuss further.
By moving some of the common concerns outside of the product teams we free up some of the team's cognitive load, so there is more room to focus on the matters that are unique to each product team. We standardize and streamline these common parts. But we also create strong dependencies between product teams and platform teams. By the nature of platform teams, each of them would be supporting a larger number of product teams. Platforms done in a wrong way spells two things: bottlenecks and disaster. Platform teams have as a purpose to accelerate growth and not to slow it down to a standstill. Part of their DNA are the genes of self-service and effectiveness, the only ways to maintain as much as possible the independence of the teams using their platform.
Getting back to the title of this post, as the skyscraper of the company starts to rise, platform teams are part of the foundation and of the reinforcement structures that are added as the building grows. The better these structures are done, the more and faster the company can grow in a sustainable way, and here sustainable is a significant ingredient to not have the skyscraper crumble like a house of cards later.