Team Topologies - by Matthew Skelton and Manuel Pais

Date finished 05 Apr 2020

The authors have pulled together a lot of wisdom to create some simple, easy to use patterns for team design. It provides many examples, diagrams and case studies which makes them “real”. The central points are simple (that’s the point), so the book could be a lot shorter but I’d certainly recommend it to anyone setting up teams and I’m sure I’ll refer back to it.

My notes

General rules to setting up teams

Conway’s law - that designs will reflect communication paths still applies, so set up your teams to reflect the architecture you want. Teams should be small, stable and long lived - limit responsibilities and stick to Dunbar’s number for those a person can trust deeply (up to 15) to limit cognitive load so you set them up for success.

Team types to choose from

The authors specify 4 types:

• Stream aligned (ie business stream), which delivers change across said stream.
• Enabling, which supports stream aligned teams, often bridging a capability gap - eg. a team of automation coaches.
• Complicated sub-system, which could be a team looking after a system that would otherwise take up a lot of time/cognitive load, so taking it off a stream aligned team’s plate for effectiveness and/or efficiency.
• Platform - provides internal services to a stream aligned team in order to reduce cognitive load. Allows stream align teams to focus and is an effective way at standardising the platform or tools the teams are using. Important that this is self service, otherwise you’re just creating more dependencies.

What’s crucial is that teams working in each of the types understand and abide by the expected behaviours detailed in the book, so that there’s clarity in when and how they interact with other teams. This saves a lot of headache.

How do you split up an existing system? As the saying goes, “there are many ways to skin a cat”, and many options for splitting a system and creating teams are listed - however by business domain is preferred.

How teams can interact

There are 3 patterns identified.

• Collaboration - working closely with the other team for a period of time.
• X-as-a-service, does what it says on the tin - providing a clearly defined service with low interaction.
• Facilitation - helping another team develop a capability or achieve a certain goal.

The authors state it’s possible for the interaction mode to change over time. For example, developing a service may need initial collaboration to understand the client team’s needs. The main thing to bear in mind here is limiting interaction to only what’s necessary so that you minimise the cognitive load on team members.