Team Topologies – Book Review
In many organisations where high-quality software development is essential for success, there is often a bias toward “immediate technological solutions” (automation, development tools, language adoption etc.). These things matter, but they aren’t the most important part. Often, less attention is paid to the culture and organisation of the groups of people who do the work. For success we need excellence in technology, sure, but we also need excellence in culture and organisation.
I don’t usually do detailed book reviews, but every now and again something really important comes along – “Team Topologies” by Matthew Skelton and Manuel Pais is one of those books.
It adds something important to our discipline: it defines an approach to using organisational structure as a tool to achieve better results in software.
“Team Topologies” is an excellent guide to structuring and keeping teams, processes and technologies aligned, for all kinds of organisations. It gives us a vocabulary and a model to direct our thinking in a way that allows for scaling up, and helps us to organise teams for effective software development. I think this is one of those “must read” books for anyone serious about professional software development!
The authors start by tying down some important assumptions, and establishing some key ideas and terms used throughout the book:
- ‘An organisation is a sociotechnical system or ecosystem that is shaped by the interaction of individuals and the teams within it.’ (my emphasis)
- ‘An organisation is the interaction between people and technology.’
- ‘… “the team” is something that behaves differently from a mere collection of individuals, and […] the team should be nurtured and supported in its evolution and operation.’ (my emphasis)
– “Team Topologies”
So what are some of the key elements that we should consider as essential to an effective team topology?
Team Size
It is very well established that small teams are vital to doing a good job in software development.
Fred Brooks said it in the 1970s, Kent Beck said it again in the 1990s and lots of people have repeated it in different forms ever since but still not every organisation listens!
A metadata research study on the impact of team size on software development looked at over 4,000 projects by dividing them into two groups of teams, as follows:
Teams of 20 people or more
Teams of five people or fewer
The researchers then measured how long it took each group to generate 100,000 lines of code.
The researchers’ findings were quite remarkable:
On average, for all of the teams, it took nine months to generate 100,000 lines of code.
On average, the teams of 20 people beat the teams of 5 to a 100,000 lines but they only beat them by a week over that same period of nine months.
Conclusion 1: a team of five is nearly four times as productive as a team of 20.
The study then looked at the quality of the code measured by the amount of defects:
On average, a team of 20 people produced five times as many defects as a team of five.
Conclusion 2: a team of five introduces fewer defects than a team of 20.
Small teams are more productive and produce work of higher quality.
Cognitive Load
Matt and Manuel have an explanation for these findings. As the complexity of a system increases, so do the cognitive demands on the team that is responsible for building it. This cognitive load is the amount of stuff that we need to think about to do our work: as team size goes up, complexity increases and so cognitive load goes up accordingly.
If a team’s cognitive load exceeds what it can cope with, this will result in a delivery bottleneck, causing delays, defects, poor quality and, unsurprisingly, a lack of motivation from members of the team
“We need to put the team first, advocating for restricting their cognitive loads.”
– Team Topologies
Keep Your Friends Close
Working in small teams isn’t principally about writing software – it is about humans. The Dunbar Number – around 150 – is a limit on the number of stable social relationships that humans can maintain. When we try to grow an organisation – such as a company – beyond this number of people we tend to experience a huge jump in complexity.
There are other numbers that seem to be common for effective human cooperation: five people is about the limit for close personal friendship, 15 people is the limit for how many
people can share deep trust and about and around 50 people for mutual trust.
So if we want teams to be efficient and effective, they must be small and we need to take these numbers seriously. Matt and Manuel suggest that a team should consist of five to nine people, or if you favour pairing, like I do, then select an even number between four to eight.
If a team gets bigger than this you should be looking for how to split it into two (or more!) teams.
Team is Primary Unit of Work
The team, not the individual – no matter how talented and smart they may think they are – is considered the primary unit of work.
The team owns responsibility and works as a unit to achieve shared agreed goals this gets us to the next vital aspect of a team-based type of organisational strategy.
Conway’s Law
“Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.”[2][3]
— Melvin E. Conway
Something that we often don’t consider, is that the human structures that we build in organisations are information systems too – remember the three assumptions of Team Topologies listed above?
How we structure our teams and organise our work is deeply related to how we are able to structure the code and systems that we build.
This is quite remarkable when we stop to think about it: Despite decades of management culture, the best that we can do is design systems that reflect the company org chart – in code!
Yet it goes even deeper than that. In information terms, this all comes down to coupling. The communication structure in an organisation implicitly defines how much or how little teams are coupled to one another.
For example, if team A needs to communicate with team B and team C to get work done that’s going to have a very different outcome to team A being able to make progress alone and in parallel with the others.
To enable that less constrained approach, we need to set the boundaries and responsibilities for the teams in a way that prefers teams that are loosely coupled with respect to other teams.
To do this we must organise in ways that allow teams more autonomy.
To achieve this autonomy, we must divide work in ways that minimises dependencies between the teams, a kind of team first approach to design.
We aim to organise the boundaries between teams so that they are loosely coupled enough that teams can make progress independently – even when they’re working on things that span teams.
One recommended strategy is dividing teams into what I used to call functional teams as the primary focus.
Aligning teams with a bounded context in a problem domain is often a good starting point for this since these boundaries usually mean that the problem is naturally more decoupled at these points.
Stream Aligned Teams
The “Team Topologies” authors have a different name, and a richer model, for these functional teams – they call them stream aligned teams.
A stream in this context is a continuous flow of work aligned to a business domain or organisational goal.
A stream aligned team is aligned with a single, valuable, stream of work.
The goal in terms of structure is to identify decoupled stream aligned teams, and then support them to work independently.
In high-functioning organisations Matt & Manuel say that you’d expect that the ratio between non-stream aligned teams and stream aligned teams to be probably one in six or one in ten so that most teams are focused on the stuff that really matters to the organisation.
Mama We’re All Agile Now…
When asked, many modern organisations would characterise themselves as taking an agile approach to their processes. Yet one of the anti-patterns that I see all the time in these self-described “agile” companies is a lack of team autonomy!
The State of Devops Report has long pointed out that one of the strongest predictors of success for a team is its ability to make decisions and progress without needing to coordinate or ask permission from people outside the team.
That’s a lot of responsibilities for a small team but that is what it takes to achieve autonomy in teams – and autonomy and teams predicts that they will build better software faster.
Handoffs
A stream aligned team has minimal – ideally zero – handoffs of work to other teams
This doesn’t only mean that you aim to limit work to reduce handoffs like “we’ve finished the backend services so now you can build the front-end ui”.
It also means that we don’t hand off responsibility to architecture upstream or to testing and release downstream.
All of these things are part of the responsibility of a stream aligned team.
Other Types of Teams
Other types of teams focus on reducing the cognitive load in stream aligned teams. That is, taking responsibility for some other parts of the problem so that stream
aligned teams can really be really productive. In Team Topology vocabulary there are three other types of team, they are:
Enabling Teams
Complicated Subsystem Teams
Platform Teams
The goal of these teams is to support the stream aligned teams.
Enabling teams may lend expertise to stream aligned teams, for example. Given that design and architecture, and ux are stream aligned responsibilities, it’s not reasonable to expect every team to have equal, deep expertise in these areas.
The goal in a well-designed organisation is to nurture the capability where it matters, and that is in stream aligned teams. Aim for every team to have the skills that it needs to make progress most of the time, and enough knowledge, enough understanding, to recognise when something is outside their experience. At that point they can call for help from an enabling team.
Enabling Teams
“…an enabling team’s job is to help stream aligned teams with acquiring missing capabilities”
– Team Topologies
The enabling team may lend the stream aligned team an expert for a short while to help them with a problem, or steer them in the direction of learning or resources that may help. The expert’s job is not only to help solve the stream-aligned team’s problem, but also to help to use fixing the problem as a chance to teach the borrowing team a little more about their area of expertise in that context.
Enabling teams can provide a vital role in helping organisations make the transition to more effective development practices.
Big organisations making the transition to continuous delivery often have strong enabling teams. These teams are focused on learning, and spreading, the skills and techniques of continuous delivery. These people typically start off building the pipelines and optimising build systems. These teams can have an enormous impact on moving the dial in an organisation.
Complicated Subsystem Teams
The focus of complicated subsystem teams is to reduce the cognitive load of stream aligned teams by taking responsibility for technically specialised complex parts of the problem. For example, these could be:
writing video codecs
financial trade matching
interfacing with complex hardware
specialised scientific/mathematical algorithms
A complicated subsystem team is characterised by needing people with deep expertise in a relatively narrow field. Their job is to provide code that can be used to deliver the complex value but doesn’t require such deep expertise to use it. This is more than just the idea of component ownership; this is a focus explicitly for complex components with very strong emphasis on hiding that complexity from the stream aligned teams.
Platform Teams
“…the purpose of a platform team is to enable stream aligned teams to deliver work with substantial autonomy”
– Team Topologies
If you can’t begin work on a feature until the platform team has delivered some change you aren’t working autonomously.
I have a video on my YouTube channel that explores approaches to design and team focus aimed at platform teams, including technical ways to help achieve this kind of autonomy:
The evolution of the platform product is not simply driven by feature requests from development teams. It is curated and carefully shaped to meet their needs in the long term.
Conclusion
I think that the book, Team Topologies is important, and adds a significant piece to the jigsaw puzzle of how to build great software.
The overall goal is to take autonomy seriously, and structure our organisations and teams so that they can take advantage of it. Teams need to be able to make progress independently of others – that is autonomy!
I really strongly recommend this book to every leader in every development organisation with more than 10 people and probably even to people in organisations with fewer people than that.