I have realized that even though I have been writing lately quite a lot about platforms and platform teams, I didn’t write anything to describe my view on what a platform is.
I heard the first time about the term “platform team” some time after I started actually working in one. I read on a blog about this new book that was describing 4 team topologies that all companies doing modern software development should strive to adopt. One of these 4 team topologies was the platform team. The book is called “Team Topologies” by Matthew Skelton and Manuel Pais and I didn’t read it until this year (2022). Which was good because what I read resonated better with my experience over the years with platform teams. It is a great book and I think that anyone involved in software development should read it.
Reduce cognitive load
In my previous posts, I more or less defined platforms as pieces of software that abstract common pieces of concern across teams. In the book, there is one sentence describing “platform teams” from a different perspective:
The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services. - Team Topologies by Matthew Skelton and Manuel Pais
We could say that this is one of the purposes of platform teams: to reduce cognitive load of stream-aligned teams (one of the other 3 team topologies described in the book). But not in such a way that it reduces the ownership of stream-aligned teams of their product slice.
I think that Team Topologies does a way better job than I could do to describe platform teams, so if you are interested into this topic, I suggest you get the book and dive in! You will not regret it.
Bringing it all together
Given the quick definitions above of platforms and platform teams, I want to use some of my other posts to add more details to this picture:
- Platforms are also products and should be treated as such.
- Not providing feedback to the users of a platform on what is their impact of their usage to the platform can turn into a tragedy.
- Platform team members have to be experts in the problem matter their platform is solving. Otherwise the platform becomes unsustainable.
- Without an active community around the platform and the platform team, it is likely the platform becomes irrelevant and hard to develop and maintain.
- Timing around creating a platform is important, but better later than too early.
- Platform teams are making DevOps possible.
- Platform engineers might not impact the external product of the company, but they should be knowledgeable about it.
- Even though I mentioned mostly infrastructure platforms in my posts so far, a platform can also be one that generalizes how, for example, authentication or general UI is being done in the products slices. No post on this so far, but I though it is good to mention.
Does this mean this is all I had to say about platforms and platform teams? Not even close! But I wanted to have one-stop-shop post bringing everything together. I will update the list above as I add more posts.