I’m reading…”Team Topologies: Organising Business and Technology Teams for Fast Flow” by Matthew Skelton and Manuel Pais

There are a set of books that I have recommended to people more than any other. I’m a technical leader, but these books aren’t technical, they are all about designing and building teams.

The top three in this collection of books are:

• The Mythical Man Month by Frederick Brooks
• Peopleware by DeMarco and Lister
• Drive by Daniel Pink

I’m now pondering whether I should start with a different book – Team Topologies. It’s not that Team Topologies says anything different to the three books above, the readers of The Mythical Man Month, Peopleware and Drive will see a lot that they recognise in this book. What Team Topologies does is summarise many of the findings of these books into practical applicable structures, linking them to models and practices that others have found useful.

The basis of this book is a simple question based on Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway

In other words, your systems will reflect your people structures.

The question that Team Topologies asks is this – if you reverse Conway’s Law does it work the other way around?

In Graham’s overly simplistic phrasing – if you design your people structures will you get the systems that you want?

Spoiler alert: Yes, you will.

What are those people structures? That’s the bulk of the document in which Skelton and Pais outline Team First Thinking, Four Fundamental Team Types and Three Essential Team Interaction Models.

That’s pretty much where I’m going to stop the review of the book because I don’t want to rewrite the book, nor do I want to oversimplify what they have written. This book isn’t a long read after all, it’s only 185 pages without references, etc. If you want a summary, then this graphic is a good place to begin: Team Topologies in a nutshell.

What I will say is this though, this is a book of principles and concepts, types and models, it doesn’t contain team blueprints or a team design handbook. It’s not a Haynes Manual for teams and that’s a good thing. People aren’t components and teams aren’t vehicles.

Whilst there are types of teams, each team needs to be designed in its own way because each team is different. The people within a team make it unique and the context in which that team works makes it unique. The words model and type are there to tell us that these aren’t prescriptions. Prescribing a structure to a team is a folly that will probably cause more damage than good. Looking at a team structure through the lens of a model or a type may give insights into the frustrations that a team is experiencing and from that the next iteration of a team design will emerge, but that’s different to a team blueprint or a business process reorganisation.

We’ve learnt how to do iterative design for technical systems, it’s time that we applied that same design approach to the teams that build those technical systems. What Team Topologies tells us is that this Team First approach may have even greater rewards than the effort we spend designing the technical systems.

Header Image: This is Watendlath Tarn on a beautiful frosty autumnal day. My father-in-law was born in a house just to the left of this picture.