Review - Team Topologies

This is a review of the book Team Topologies, by Manuel Pais and Matthew Skelton. I read it in the context of my personal studies habit, in which I set off 15-30 minutes of my free time each day to work through a technical book which is either a classic in the field or that I believe has an interesting point of view. I studied this book in 2024, from March 11th to May 11th. (Funnily enough, digging through my notes I found out that I had added this book to my backlog on May 28th of 2021 - so that is roughly three years from entering the backlog to being completed!)

I decided to pick up Team Topologies when I was working in an environment where the setup of the teams did not seem to be helping the developers to perform at their best. Having previously worked in scrum teams where things ran much smoother, I knew we could be aiming higher. So I turned to this book hoping that I could get some insight and a solid grounding on the best ways to structure development teams to help improve our environment.

Summary of main ideas

First a quick overview of the ideas in the book, before I add my thoughts about them.

The main framework that is presented consists of 4 topologies and 3 interaction modes. 

The topologies are: 

• Stream-Aligned Teams (i.e. your typical feature team)
• Enabling Teams (for example, an architecture team)
• Complicated-Subsystem Teams (highly-specialized knowledge, think something such as the team that implements facial-recognition algorithms)
• Platform Teams (develops and maintains the provisioning tools, for instance) 

The interaction modes are: 

• Collaboration (two teams working together in a flat hierarchy)
• X-as-a-Service (one team consuming the work of another as an end-product)
• Facilitating (one team coaching another towards a desired goal) 

The examples given here are, of course, somewhat simplified for conciseness, but they give the general idea of each type.

The authors base their ideas on several concepts that are well worth studying by themselves: Conway's Law, Dunbar's Number, cognitive load (both personal and of the team), among others. Just the brief presentation of these foundations and the idea of seeing the team as the smallest unit of delivery generation should already pay off the time invested in reading.

Personal highlights

Shared vocabulary

Moving on to some of my personal thoughts about the book, I think it does a good job of establishing a base language to discuss team composition, in a similar way as Design Patterns and the classic Refactoring book by Martin Fowler do to their particular topics. It might seem a small thing, but to be able to synthesize a concept into a term is very powerful because it allows for a more sophisticated manipulation of the idea without getting bogged down into the details of specific instances (as software developers, we all know the power of adding a layer of abstraction). 

One example of an exercise that becomes easier once a base vocabulary is established is to see the organization of the teams and their interactions as the first architectural structure of the system being built - an idea that is explored in the book and that flows naturally from Conway's Law (systems end up with a design that copies the communication structure of the organization that made them).

While most likely only people who are very high in the organization's hierarchy will be making decisions about how to structure teams at the level discussed in the book, I believe it is beneficial for everyone at any level to know about these concepts and to try to pinpoint which topology each team in their surroundings is closest to - this simple task might lead to a series of deeper questions about how interactions with these teams are happening and how effective they have been.

Deliberate collaboration

One of the ideas brought up in the book that I particularly like is using "deliberate collaboration" as a way to disseminate practices and knowledge across the organization. This is another point in which having a consolidated vocabulary helps: it is a reasonably natural idea and one that I am sure most of us have seen implemented several times. Yet, having Collaboration defined as a very specific type of interaction that we can choose to explicitly assign to teams helps to communicate to everyone what are the expected outcomes. It becomes more actionable and accountable at the same time. 

A further extension of this idea, that is not talked about in the book but that I would like to explore deeper, is using rotation of team members across different topologies with some frequency as a way to develop more well-rounded professionals and also to promote an appreciation for the different styles of work that each topology needs.

Organizational sensing

Another concept I found interesting was that of organizational sensing. This was the first time I read about it, but the concept precedes the book. The idea is to use teams and their communications as "senses" for the organization, in a similar way as we humans can see, hear, touch, and so on. I like this analogy because it is bigger than mere metrics or observability - while these are important mechanisms because they are concrete enough to be directly implemented, I feel that thinking solely in their terms leaves behind a family of signals and connections that play an important role in the success of any endeavour. And it also leads in nicely to my next point.

Sociotechnical systems

The last concept I highlighted was that an organization is a sociotechnical system. I particularly like the way the book puts it: "[...] we must shift our thinking from treating teams as collections of interchangeable individuals that will succeed as long as they follow the 'right' process and use the 'right' tools, to treating people and technology as a single human/computer carbon/silicon sociotechnical ecosystem". 

I want to zoom in and focus on our industry: software development involves both the people and the technology - we must understand both in order to be successful, bugs can arise out of both, and both are capable of bringing about marvelous things that disrupt everything that came before. Whenever we want to truly understand our work, it is a mistake to think we can consider either in isolation. 

While the association is never made in the book, to me that is a major part of my affiliation to the Agile mindset, as it is the best tool we have to really see our environment as a constant interaction of people and technology (sociotechnical system) that take feedback out of short and frequent experiments (sensing) to move towards a better outcome.

Comparing to expectations

So, those were the main insights I took out of the text. Now, for a comparison of my initial expectations to what I found in it, I must first say that there is some mismatch. I was looking for a very specific thing when I picked the book: I needed to find a solid theoretical grounding to serve as the basis to discuss how we could improve our team allocations. At the level of how many seniors to juniors, how to avoid bottlenecks and minimize external interference, how much pair programming versus solo programming should we strive for, and so on. Very low level, "I am just a developer trying to do actual development work here" kind of stuff. While reading the book brought some good ideas with regards to those, the main focus is at a different, far higher level. Not at the level of how to make one team work well and effectively within an organization, but at the level of how to organize the entire organization's development roster into more or less composable components. And that is not a bad thing, I enjoyed the content and think everyone at any level can benefit from the knowledge it contains. But it does leave unresolved my initial necessity. So, personally, I thought that the book could go deeper into the specifics of each one of the topologies and interaction modes.

To explore further

Some questions it does not answer and that I would like to have seen answered are: 

• What is the (approximate) optimal size for teams of each topology? 
• When there are two teams interacting in the Facilitating mode, how many people of each team should be communicating with people from the other team on a daily basis? (It seems horribly inefficient to have all members of both teams always communicating across teams every day) 
• How to prevent Complicated-Subsystem teams to get alienated from end-user needs and delivery flow? 

And several more along those lines. I am interested in finding out other works that explore these issues more deeply.

Another thing that appears in the book (albeit tangentially) and that I still want to investigate deeper is the usage of gardening as a metaphor to software development, in opposition to the metaphor of engineering. I had read the same argument on The Pragmatic Programmer, by David Thomas and Andy Hunt, a while ago and it is something that stayed in my thoughts. The more I work in this industry, the more I like this analogy. The rate of change of software seems to me much more akin to biological systems than to purely physical ones, and I mean both the changes that we, as developers, must implement and the changes that happen at every abstraction layer that we rely upon for our systems to function. Imagine trying to raise a building having to allow for the fact that you do not know if three weeks from now your bricks will still be bricks or will now be composed of inflammable foam. Oh, and the probability of that happening is different for every single brick. Individually. At different moments of time. And you know, beams are so old-school and verbose, we might just change them all to simple wires next sprint - with the building still standing up and people still living inside of it, of course!, do you think we can afford to stop operations just to rebuild the entire damn thing? Come on now. Engineers have it way too easy.

Conclusion

So, in summary, I found Team Topologies to be a good book for professionals at any level of the organization. Although people who are higher up in the org chart might benefit more from it due to acting more directly on creating and changing the structures discussed, the people who do not make these decisions but are present within these structures can still get a better view of the whole and start to evaluate their own environments with more clarity by studying the book. The framework presented in it is solid and can be applied immediately to any organization that develops software - maybe not by simply replicating the ideas but at least by analyzing and evaluating the current structure in light of them. Although I felt it did not go as deep as it could in some areas, I still learned enough to become more confident in discussions about team structure, and, hopefully, a more effective professional.