Book Notes: Team Topologies

Team first thinking

  • The team is the means of delivery
  • design team for cognitive load. Team has a maximum size, of about 8 people. This will also naturally limit the size of the software that the team has to be responsible for, while still understanding their domain pretty well
  • Choosing boundaries for team ownership is a skill. Definitely not something that should be done by a manager with no technical awareness, as it impacts the architecture of your software - Conway’s law
  • On Conway’s Law: The way your teams are structured, dictates how your software architecture turns out.
    • Reverse Conway to mitigate worst effects

Four Different Types of Teams

1. Stream aligned teams

  • Organised around value streams. As Jeff Bezos says, this kind of team should have “line of sight to a customer”

A stream is the continuous flow of work aligned to a business domain or organizational capability.

  • Operate best when independent, & not requiring handoffs to other teams do parts of the work
  • They focus on a business mission

The other types of teams make the stream aligned teams go faster

2. Enabling team

  • These help manage scarcity. Eg there aren’t a lot of security engineers, user researchers, super good infrastructure okes going around. Enabling teams then act as consultants to the other teams
  • The nature of their work looks a lot like “from R&D -> Education/Coaching mode”

3. Complicated subsystem team

Think PhD math people working on a complex bit of the product, such as trip forcasting ML jobs for a logistics company.

4. Platform Team

  • These focus on a technical mission
  • Their customers are usually internal users.
    • Sometimes can be public, eg in the case of building a public facing SDK

Some literature on the topic:

Thinnest Viable Platform

  • What’s the thinnest platform that could work?
  • If your org decides “we use AWS”, your thinnest viable platform can be something as small as a wiki page saying “these are the 5 AWS services that we use for ABCD”

Team interaction modes

The book highlights that “Well defined interactions are key to effective teams”

A team may have been told it is autonomous and self-organizing, but team members find they have to interact with many other teams in order to complete their work; and this feels frustrating.

This is usually a smell for unbalanced teams in an organisation. Either not enough senior folk in the one team, or an improper mapping of service/domain ownership -> team.

What must be avoided is the need for all teams together communicate with all other teams in order to achieve their ends

Anyway, onto the interaction mode that were recommended.

1. Collaboration

  • 2 teams working together (or subsets of 2 teams). A useful constraint for managing dependencies is

Constraint: A team should use collaboration mode with, at most, one other team at a time

  • Watch that this isn’t happening too often though, as that’s an indication of teams not having been sliced properly.
  • Communication & coordination overhead is something to look out for.

2. X-as-a-service

  • 1 provides, 1 consumes.
  • Works best when the provider really takes into consideration the developer experience.

3. Facilitating

  • 1 team helps another

A combination of all three team interaction modes is likely needed for most medium-sized and large enterprises (and these modes are useful to introduce at smaller organizations sooner than many people expect).

Team interaction modes evolve over time

  • EG, an enabling team & stream aligned can go from collaboration to X-as-a-Service once patterns have been solidified and a platform has been built

On Team boundaries

Techniques from domain-driven design (DDD) such as event storming and context mapping can help accelerate awareness of appropriate boundaries.

Use Awkwardness in Team Interactions to Sense Missing Capabilities and Misplaced Boundaries

Related reading