January 2024 – James Osborn

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.

We’re still doing work on our house (and will be for a while)! One really interesting thing that I’ve seen is that when we are getting quotes for work, a lot of tradespeople are very sure what a problem might be, before they’ve really looked into the issue.

We can get three quotes, and have three different root cause analyses of what’s going on.

This is happening because of their expertise in a particular area of a trade. If they are used to using nails, every solution is a hammer! If a job feels familiar, then it’s easy to assume it is exactly what it appears on first glance.

Sometimes it’s a preferred job or way of working, and sometimes it’s just the big expensive “fix it all”, rather than the intervention we actually need.

The best people we’ve worked with take their expertise, and then go with an open mind to find the right solution. They might have that initial idea, but they test it against the actual situation. They look at the problem from various angles, get up close, go up a ladder and really understand what’s going on.

By testing a hypothesis quickly and cheaply, we get to the real issue faster. That means the right work is done, things that can wait are put down the list, and we’re spending the right money at the right time.

We’ve fixed “damp” by repairing the drainpipes and cutting back shrubs, and replaced a single valve in our heating to bring it fully back to life on a cold winter’s day.

People that work this way don’t make the most money in a single transaction, but as they ‘ve built trust, we go back to them multiple times, and recommend them to our friends!

So, don’t get blinded by your expertise. Use it to shape your thinking and come to solutions quickly, but make sure they are informed by what’s going on in reality. Don’t just always reach for the hammer!