‘Team Topologies’ by Matthew Skelton & Manuel Pais

Who should read this book?

CIOs who want to assess and adapt the design of their IT organisation.

Consultants who want to coach the CIO or CEO.

Why you should read this book (or not)?

This is one of the most complex and abstract book I have ever read. I only finished it because I had to.

That said, it contains a couple of concepts that are definitely worth knowing. And hence, I am happy I read it. However, you might prefer getting that knowledge differently than crawling through this book.

The book contains very few

• Anecdotical, fun stories
• Practical, simple & specific examples
• Easy to understand analogies

Rather, you will find

• References to other literature, creating a nice overview
• Several applications of Conway’s Law
• Academic language
• A lot of repetition

It is a pity, because there is a value in the book that goes beyond an IT environment.

Interesting extracts

“The danger of allowing multiple teams to change the same system or subsystem is that no one owns either the changes made or the resulting mess. However, when a single team owns the system or subsystem, and the team has the autonomy to plan their own work, then that team can make sensible decisions about short-term fixes with the knowledge that they will be removing any dirty fixes in the next few weeks. Awareness of and ownership over these different time horizons helps a team care for the code more effectively.”

“The virtual environment is increasingly important as many organisations adopt a remote-first policy. the virtual environment comprises digital spaces such as a wiki, internal and external blogs and organization websites, chat tools, work tracking systems, and so forth. Effective remote work goes beyond having the necessary tools; teams need to agree on ground rules around working hours, response times, video conferencing, tone of communication, and other practical aspects that, if underestimated, can make or break a distributed team, even when all the right tools are available.”

“An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack. This allows the stream-aligned team the time to acquire and evolve capabilities without having to invest the associated effort.”

“A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem.

The goal of this team is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem. The team handles the subsystem complexity via specific capabilities and expertise that are typically hard to find or grow. We can’t expect to embed the necessary specialists in all the stream-aligned teams that make use of the subsystem; it would not be feasible, cost-effective, or in line with the stream-aligned team’s goals.

Examples of complicated subsystems might include a video processing codec, a mathematical model, a real-time trade reconciliation algorithm, a transaction reporting system for financial services or a face-recognition engine. (…) We expect to have only a few complicated-subsystem teams.”

“Formalizing the ways in which teams should interact when building software systems helps to more easily assess the effectiveness of many aspects of software delivery by more explicitely defining interfaces between teams; in turn, it is expected (from Conway’s law) that these interfaces will be reflected in the software systems being built.”

“Technology-driven splits typically introduce more constraints and reduce flow of work rather than improve it. That is because the separate teams are less autonomous, as product dependencies remain while each team has less visibility on the work as a whole, and interteam communication paths are slower than intra-team. There are situations where splitting off a subsystem based on technology can be effective, particularly for systems integrating older or less automatable technology.”