Book Review:

Team Topologies

Team Topologies (Matthew Skelton and Manuel Pais, 2019) is, essentially, a book-length treatment of the Inverse Conway Maneuver. I recommend this book to folks looking to design or refactor product delivery organizations, especially those unfamiliar with the idea of aligning teams to delivery priorities. However, for reasons I’ll get into below, I found it a bit of a slog.

For those unfamiliar with that concept: Conway’s Law states that organizations produce systems that mirror their internal communications structure (e.g. an organization with separate Web and Mobile teams will tend to produce web and mobile apps that aren’t consistent with each other and obviously disparate products). The Inverse Conway Maneuver, then, is when an organization embraces this principle and deliberately designs its organizational structure to mirror what it wants to produce¹.

I wrote about this concept myself earlier this year. After publishing that article, several people recommended I read Team Topologies. I can see why: the authors come to very similar conclusions as I did, but in much more depth and with solid, specific, actionable advice on how to implement a delivery-aligned organizational structure.

The main thesis of the book is to engage in “team-first thinking”:

We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individuals; only to teams. In all aspects of software design, delivery, and operation, we start with the team.

It covers four common patterns² for teams:

1. Stream-aligned teams, that are aligned to a single delivery stream, such as a product or service (what others might call a “product team” or a “feature team”).
2. Enabling teams, specialists in a particular domain that guide stream-aligned teams
3. Complicated-subsystem teams that maintain a particularly complex subsystem, such as an ML model
4. Platform teams that provide internal services like deployment platforms or data services

Most of the book is taken up in carefully defining each of these teams, discussing how to form and build them, and enumerating how these kinds of teams communicate with each other. A key observation the book makes is that:

One key implication of Conway’s law is that not all communication and collaboration is good. Thus it is important to define “team interfaces” to set expectations around what kind of work requires strong collaboration and what doesn’t. Many organizations assume that more communication is always better, but this is not really the case. What we need is focused communication between specific teams.

Thus, the careful focus on communication mechanisms.

The book’s advice is practical and quite detailed; I have no trouble imagining using this book as a blueprint or guidebook to organizational design.

However, as I mentioned up top, I found the book something of a slog. I usually read books like this in a day or two, but this one took me several weeks (spent mostly avoiding reading it). I found myself putting it down after an hour each time and procrastinating picking it back up again.

I think this is because, for me, it’s essentially preaching to the choir. I’ve completely internalized the idea of delivery-aligned organizations, and implemented a few, so nothing in the book was particularly surprising. I think once you accept the premise that organizations should be aligned to what they want to deliver, and once you think in terms of teams, everything else flows from those principles. This is a good sign for the model: it’s internally consistent and quite logical. But it makes for fairly tedious reading in that each chapter felt rather obvious. I didn’t feel like I was learning much, merely exploring many minute details of a concept I already felt I understood.

Nevertheless, it’s a solid book, and one I expect I’ll find myself recommending relatively often. Delivery-aligned teams are not widely agreed-upon – e.g., the Hacker News comments on my article on the concept were extremely skeptical – and the implementation details are useful to have in one place. If you’re running a product/engineering organization and struggling with poor alignment, communication, and/or delivery cadence: give Team Topologies a try.