“Team Topologies” (Book Review)

In 2019 Matthew Skelton and Manuel Pais published “Team Topologies: Organizing Business and Technology Teams for Fast Flow”. The book sheds a light on four fundamental team types:

Stream-Aligned Teams: A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and delivered customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform the work.

Enabling Teams: 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 decisions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.

Complicated-subsystem Teams: 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.

Platform Teams: The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. The stream-aligned team maintains full ownership of building, running, and fixing their application in production. The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services.

In addition, Skelton and Pais outline three team interaction modes:

• Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
• X-as-a-Service: one team provides and one team consumes something “as a Service”
• Facilitation: one team helps and mentors another team

Image Credit: Yoan Thirion

Interestingly, Team Topologies covers “Conway’s Law” in depth and sees it as something that organisations should take advantage of. Conway’s Law states that “Organisations which design systems are constrained to produce systems which are copies of the communication structures of these organisations.” Skelton and Pais explain that thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any team is fundamentally wrong. An organisation that is arranged in functional silos (where teams specialise in a particular function like security or QA) is unlikely to ever produce software systems that are well-architected for end-to-end flow.

Instead, by applying a “reverse Conway manoeuvre”, we can design our teams to “match” the required software software architecture by having separate developers for the client applications and the API, and a database developer within the team rather than separate from it.

To limit the cognitive load of a team, Skelton and Pais suggest four key heuristics worth applying to team design:

1. Assign each domain to a single team — If a domain is too large for a team, instead of splitting responsibilities of a single domain to multiple teams, first split the domain into subdomains and then assign each new subdomain to a single team.
2. A single team should be able to accommodate two to three “simple” domains — Because such domains are quite procedural, the cost of context switching between domains is more bearable, as responses are more mechanical.
3. A team responsible for a complex domain should not have any more domains assigned to them — not even a simple one — This is due to the cost of disrupting the flow of work (solving complex problems takes time and focus) and prioritisation (there will be a tendency to resolve the simple, predictable problems as soon as they come in, causing further delay to the resolution of complex problems).
4. Avoid a single team responsible for two complicated domains — This might seem feasible with a larger team of eight or nine people, the team will behave as two subteams (one for each domain), yet everyone will be expected to know about both domains, which increases cognitive load and cost of coordination. Instead, it’s best to split the team into two separate teams of five people, so that each team can be more focused and autonomous.

Image Credit: Matthew Skelton and Manuel Pais

In the book, Skelton and Pais stress the importance of consciously designing teams. There is a relevant quote here from Jutta Eckstein, Agile coach, author and speaker, who states “Instead of structuring teams according to technical know-how or activities, organise teams according to business domains.” This might sound obvious, but there are team anti-patterns which I’m sure that most of us will have encountered at some point in our careers:

• The first anti-pattern is ad hoc team design. This includes teams that have grown too large and been broken up as the communication overhead starts taking a toll.
• The other common anti-pattern is shuffling team members. This leads to extremely volatile teams assembled on a project basis and disassembled immediately afterward.

To avoid these team anti patterns and to design teams intentionally, Skelton and Pais suggest asking these questions:

• Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results safer and faster?
• How can we reduce or avoid handovers between teams in the main flow of change?
• Where should the boundaries be in the software system in order to preserve system viability and encourage rapid flow? How can our teams align to such boundaries?

Finally, Skelton and Paid describe ways to break up monolithic software, splitting software into a more distributed system. Splitting software into different parts does carry certain risks: reducing consistency between parts of the software or duplicate data across different systems. One can use a “fracture plane” to split the software in a logical and sustainable way. A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts. The book covers several of these fracture planes to split the software. These are some sample fracture planes that I want to highlight:

• Business Domain Bounded Context — Here the software aligns to an internal business domain area. For example, at an online music streaming service software could be split into three sub-domains that align well to business areas: media discovery (finding new music), media delivery (streaming to listeners), and licensing (rights management and royalty payments).
• Regulatory compliance — In highly regulated industries like banking or pharmaceuticals, regulatory requirements can often provide hard boundaries for software.
• Change cadence — Another natural fracture plane is where different parts of the system need to change at different frequencies. With a monolith, every piece moves at the speed of the slowest part. Splitting off the parts of the system that typically change at different speeds allows them to change more quickly. The business needs now drive the speed of change, rather than the monolith imposing a fixed speed for all.
• Team location — Teams distributed geographically and across different timezones are obviously not colocated. Within distributed teams, communication is limited since they must explicitly request a physical or virtual space and time to communicate across locations. Skelton and Pais argue that for a team to communicate efficiently, the options are between full colocation or a true remote first approach.

Main learning point: “Team Topologies” encourages us to be intentional about team design, considering aspects such as the complexity of a domain and cognitive load. Most and foremost, Team Topologies provides valuable tips and tools on how to avoid “Conway’s Law” from happening in our organisations.