Team Topologies is a great book by Matthew Skelton and Manuel Pais. It gives you methods to organise your technology teams for fast flow, and a simple way to categorise those teams.
It’s a short and punchy book broken into three key sections. We start with Org Charts, Conway’s Law and teams as the unit of development. The second section takes you into the meat of the book, covering team anti-patterns, the four fundamental topologies and how you might choose sensible boundaries. The last section is focused on interactions between the teams, and methods of iterating towards the structure.
The big ideas are really around long lived teams as the unit of software delivery, that there are only really a few types of team, and that we can choose to target high flow and iterate towards it over time.
Flow doesn’t mean efficiency, so a lot of the identified anti-patterns are where an organisation has attempted to be efficient (handing over work, creating queues and specialist groups), targeting least overall effort, rather than soonest delivery of value.
The book highlights a number of times that you must have good engineering practices as a pre-requisite. If you are not able to release software easily and with confidence, or to do so in an automated manner, then you will need to fix that before gaining value from this structure.
It’s also clear through the book that attempting to suddenly move all teams into the model on day 1 is unlikely to work, that iterative and adaptive approach is most likely to be successful, especially via the analysis of cognitive load on teams, and splitting responsibilities where they are overloaded.
I think it’s easy to get excited by the simplicity provided in the book, with four team types and three interaction modes, there’s a lovely easy classification system, and engineers love to put things into buckets or give them a label.
In a mature existing org it’s unlikely that you’ll get a perfect one to one mapping ever, but the taxonomy does give you a chance to start using the same language when describing teams, and an ideal to aim towards.
The case studies and tips scattered through the book bring this to life. Iterations on orgs take years not days, as they need to bed in and become part of the culture. The first thing you try is going to be wrong, so the examples where people have iterated over time are particularly enlightening.
I think that a lot of the core ideas will be familiar to org minded thinkers, but they are pulled together in a compelling way. There’s a lot of value in the approaches outlined, but they require discipline to understand fully, to recognise the foundations that must be in place to be successful and the willingness to iterate as the org continually moves forwards.
Simplicity is hard, don’t fall into the trap of thinking it’ll all be easy once your leadership team has read the book and you’ve rebadged all your teams in team topologies terms.
Be willing to put in the work, and you’ll be rewarded with a shared set of terminology, and a repeatable process for building out teams that deliver the maximum possible value in the shortest time.
James Osborn 