Team Topologies

Why platform engineers read it

Team Topologies, first published by IT Revolution in 2019, is a book about organisation design, but it is the reason most platform teams exist in the shape they do. Its central claim is that software architecture follows team structure, so if you want services that can change independently, you design teams that can deliver independently. It gives a small, shared vocabulary for doing that:

• Four team types. Stream-aligned teams own a flow of work such as a product, a service or a user journey, end to end. Platform teams provide internal services that let stream-aligned teams deliver with substantial autonomy. Enabling teams are specialists who help other teams learn a capability. Complicated-subsystem teams own a part that needs deep expertise.
• Three interaction modes. Collaboration (working closely for a defined period), X-as-a-Service (one team consumes what another provides) and facilitation (one team coaches another).
• Team cognitive load. A team can only hold so much in its head. If a product team must also master Kubernetes, networking, observability and compliance, its delivery slows. A platform exists to take that load away.
• Thinnest viable platform. Build the smallest platform that actually helps. Sometimes that is a wiki page of agreed practices, not a portal.

Is it worth it, and which edition?

Yes, and it is one of the shortest books on this roadmap. The second edition, published in September 2025, keeps the model and adds a new foreword, case studies from many industries and an afterword on what the authors did not anticipate, including patterns that go wrong in practice. If you already own the first edition, the core ideas are unchanged, so you can read the free material on teamtopologies.com about common misuses of platform teams instead of buying again.

Prerequisites and time

No technical prerequisite. It helps to have worked in or with a team that waited on another team for infrastructure, because you will recognise every problem it describes. Around 300 pages, readable in one to two weeks.

Free or paid

The book is paid, in print, ebook and audio. The authors publish a lot for free on teamtopologies.com, including the key concepts, the team types and articles on platform teams, which make a good preview.

What you can do after it

• Explain why a platform team should treat developers as customers and its platform as a product.
• Spot when a team is overloaded and argue for moving work into a platform, or out of it.
• Choose the right interaction mode between your platform team and a product team, and change it deliberately over time.
• Start with a thinnest viable platform instead of a large portal nobody asked for.

Common questions

Is it a management book? Partly, but engineers get as much from it, because it explains why your platform work succeeds or fails for reasons that are not technical.

Does it tell me which tools to use? No. It is deliberately tool neutral. Pair it with the CNCF platforms white paper for the technical side.

Best for: engineers moving into platform, DevOps or SRE roles who want to understand what a platform team is for, not just what it runs.