Book Review and Notes of Team Topologies

Book Review

In our book, “Building Evolutionary Architectures” we talked about the Inverse Conway Maneuver, or using Conway’s Law to your advantage. Conway’s Law implies software systems mirror communication paths eventually. Therefore if you want to deliberately shape your architecture, you need to shape the way teams communicate with each other. Team Topologies by Matthew Skelton (@matthewpskelton) and Manuel Pais (@manupaisable) explains this in-depth and offers simple approaches to achieve this.

Based on the name, I thought the book was going to be a team pattern catalogue. I thought it would highlight good and bad team configurations. It’s not. The book assumes you’re already starting with modern software teams or mostly small, cross-functional teams. Assuming you have a high-performing team, the book explores the best way to organise them. It focuses on 4 configurations, called a topology, and 3 different interaction methods. They show how these tools compose, scaling as an organisation scales up.

I found myself nodding along with many of the explanations, as I was familiar with a lot of the theory. Their stories and case studies also resonated with my personal experiences. I’ve used these approaches with teams although I often used different terms. I see a lot of value in the terms they present and sharing a common vocabulary within and across companies.

Who Will Benefit from This Book and How?

This book will be interesting for any technical leader, architect and engineering manager. It will be less relevant but still interesting for team members. I’d especially recommend Team Topologies to leaders who influence the shape and structure of software teams. Don’t think of the contents as a static model, as many think of the way Spotify works. Instead, treat the contents as a set of building blocks. You compose building blocks differently depending on your goals. Since goals change all the time you’ll need to change your building blocks to adapt.

Notes

These are notes I captured from the book for future reference.

4 team topologies:

• Stream-oriented teams (High %) – End-to-end cross-functional teams delivering a flow (stream) of value. An example is a traditional product application team.
• Complex sub-system team (Low %) – A specialised team focused on an area of extreme complexity. Examples include highly regulated, required specialist skills or complex business rules.
• Enabling teams (Low %) – A team whose members work with other teams to develop missing capabilities. An example may be a Continuous Delivery team who ensures teams have strong skills to build and evolve their CD pipelines.
• Platform team (Low %) – A team that provides stream-oriented teams with internal services to reduced cognitive load. An example is a cloud platform team that offers self-service infrastructure services.

3 team interaction modes:

• Collaboration – High bandwidth, interactive team interactions, ideal for discovery and innovation.
• X-as-a-Service – Consuming or providing something with minimal collaboration
• Facilitating – Helping or being helped by another team to clear impediments

Triggers for evolution:

• Software has grown too large for one team
• Delivery cadence is becoming slower
• Multiple business services rely on a large set of underlying services

Team First Thinking considers cognitive load, team APIs, team-sized architectures.

A Fracture Plane is a natural seam in the software system that allows the system to be split easily into two or more parts. This splitting of software is particularly useful with monolith software. We can look for similar fracture planes in software to find the natural split points that lead to software boundaries.

Buy the book here.