Book Review: Team Topologies

Team Topologies

Author(s)

Matthew Skelton, Manuel Pais


My Rating

star star star star star
"An innovative toolkit for designing technology teams optimised for your organization's needs"

As a growing junior software engineer, I started to wonder about the tools and frameworks managers used for organising teams. I was always so curious about rigorous engineering methodologies and architectural patterns, and I was becoming curious to see their equivalents in the domain of organisation design.

Slowly I started to realise that there was little rigour. It seemed like team design was an ad-hoc, arm-waving exercise based on whimsical project needs. There was no systems thinking. And then came the Spotify Model. I saw a number of organizations going "full spotify". I'll leave it there.

Things Began To Change

Round-about 2017, things started to change. I noticed Matthew Skelton presenting at conferences. Sharing his experience of team design across a large number of organization's he'd worked with. Matthew was different because he was digging into research and relating it to modern team design.

In 2019, Matthew Skelton and his friend Manuel Pais released the Book Team Topologies. Based on their years of experience and research, they promised a toolkit for designing organisations that went beyond superficial ideas and helped organizations to think rather than offering pre-baked solutions.

Did they deliver on their promise? Yes they did. I've read the book twice, I refer to it often, and I promote the Team Toplogies concepts whenever people will listen to me.

The Thinking Person's Book

If you're interested in improving the design of your organization to improve the quality and frequency of your software delivery, then this book is probably for you. The one condition is that you have the desire to think for yourself. There is no "let's go full Team Topologies" option.

It would be easy to reduce Team Topologies to its iconic patterns. It's Stream-aligned, Complicated Sub-system, Enabling, and Platform Teams, and it's X-as-a-Service, Collaborating, and Facilitating interaction modes. While these patterns are extremely useful for laying the foundations of an industry-wide shared vocabulary, there's a tonne more value to gain from the book.

As I sit here looking at the table of contents, trying to remember the parts that stand out the most, I'm overwhelmed with the amount of information I want to write about, from the clarification of Conway's Law and it's application to modern organizations, to the concepts of a Team API.

Other standout aspects of the book are the focus on platforms. Don't build big platforms, focus on the Thinnest Viable Platform (TVP). Don't treat the platform like a collection of internal tools, but treat it like a product. So much useful advice in this area.

At 200-ish pages, Team Topologies is one of the most information-dense books I can recollect, and yet there is no compromise on readibility. Every chapter is a compelling pleasure.

Where Next?

If you pushed me hard to criticise the book, then my top piece of constructive advice would be to make some of the concepts of more actionable with detailed examples. It would be unfair to say the authors haven't attempted to address these issues. There are around 10 case studies in the book and they have started to create a github project to document their tools, like the TVP template.

Let's build on the momentum of Team Topologies. Let's add rigour to the design of technology organizations so we can get more work done and be happier along the away.

Highlights

"For a safe, rapid flow of changes, we need to consider team-scoped flow and design the architecture to fit it."


"There is a danger of misinterpreting Conway's Law and creating a set of teams that appear to map well to the required architecture but, in fact, work strongly against fast flow."


"A stream-aligned team is a team aligned to a single, valuable stream of work."


"Flow is difficult to achieve when each team depends on a complicated web of interactions with many other teams."


"Collaborative is good for rapid discovery and avoiding hand-offs and delays, but on the downside is a higher level of cognitive load."


You may also like...

The Economist Guide to Organisation Design

Org Design for Design Orgs

Agile IT Organization Design

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design