Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow (Book Review)
This is essential reading for any engineering manager, leader, or executive who needs a well worked-out idea of how to organize tech teams and must understand the different types of teams and their interactions. I learned a lot!
The fundamental contribution here is that the book outlines four basic types of teams: A stream-aligned team that makes things; a platform team that provides internal services (to reduce the load on stream-aligned teams [p. 92]); an enabling team that conducts mentoring and team debugging, and a "complicated subsystem" team, that is highly specialized for a function that requires narrow expertise.
Then the book says that there are three interaction modes: collaboration, X-as-a-Service, and facilitating. The discussion of interaction modes is supplemented by diagrams that show how teams connect up, and, more importantly, how they change their relationships over time. There's a lot to think about here. But I think the real benefit of the book is that it provides names for things that many of us have seen in different organizations . . . Now we can talk about it.
There are some oddities in this book. It's kind of padded and repetitive, maybe for good reason: Sometimes you just have to beat useful concepts into the brain of the reader. Still, Oddities: To tease them out I'm going to have to write a longer review, but here are some of them:
You might think that the team types described above are exhaustive but they're not. Elsewhere in the book we learn about "tooling teams" and database teams and you wonder: Are there more team types?
Why are the four described above the team types? Also, what is the factual empirical basis for these team types? When the book mentions research, it only really sources one book, Forsgren, et al.'s, Accelerate. Fine, but this book speaks with the voice of god and I would say that there is no definitive taxonomy of teams. The team types here are great, but where do they come from, really?
The book acknowledges that there are three primary org structures: formal (which is about "compliance"), informal, and value-creating (p. 7) -- and then immediately goes on to say that the important orgs are the informal and the value-creating. OK, but what about compliance? It's almost like it's mentioned only to be discarded. The book doesn't really have a story around the kinds of accountability that many organizations must prove out owing to regulatory and security concerns.
Costs. The book instances a team of about 10 people (pp. 19-20) but when they are realigned to be more productive, there are 12 seats (p. 22). Who pays for those two extra seats? The book constantly talks about mid-sized and large companies where it is implied that the enterprise is always growing: But I think we need to understand how to re-org teams with the same cost basis.
The book says you need to re-org teams because teams must not be encumbered by too much cognitive load. But this concept of cognitive load needs a lot more definition. When we say "cognitive" we are generally talking about one mind. But teams are not one person. So what does it mean to talk about cognitive load with regard to a whole team? Could specialization inside the team help with the load? What about common techniques to offload cognitive load / short-term memory with notes, glossaries, etc.? There are other ways to reduce load. The book sort of takes a team's cognitive load as a given, but how is it measured? Suppose you have two teams that are burdened with a heavy cognitive load: How do you adjudicate which ones has a more urgent need for repair? I wish I knew.
So: A lot here but the closer the reading, the more you wonder about.
Originally reviewed on Goodreads on 10 March 2021.
Comments