Team Topologies

Review

I read this in April 2022 when I was thinking hard about why some team structures produce fast, clean software and others produce a tangle no one can unpick. The book gave me a vocabulary I hadn't realized I was missing. Four team types, three interaction modes, and suddenly a whole set of organizational frustrations had names you could actually use in a room.

The Reverse Conway Maneuver is the central idea worth carrying away. Conway's Law tells you that your communication structure will show up in your software architecture whether you planned it or not. This book tells you how to use that deliberately: design your teams around the software shape you want, and let the architecture follow. Your team assignments are the first draft of your software architecture, which reframes a lot of decisions that usually get treated as purely technical.

The cognitive load framing is the other piece I found genuinely useful. The argument that team boundaries should be drawn around what a team can actually hold in its head, not around technical convenience or shared component logic, is one that doesn't get stated clearly enough elsewhere.

It gets repetitive in the second half and some of the expected behaviors checklists feel like padding. The core model is solid though, the ideas are practical, and the vocabulary it gives you is worth having if you work in or near software organizations.

Key Takeaways

The parts worth keeping.

Conway's Law and the Reverse Conway Maneuver

• Conway's Law: organizations produce system designs that mirror their communication structures. Ruth Malan's formulation is sharper: if the architecture of the system and the architecture of the organization are at odds, the organization wins.
• Reverse Conway Maneuver: instead of mandating a software architecture, restructure your teams around the architecture you want. The software will follow. Your team assignments are the first draft of your system design.
• Technology leaders need to be involved in team design, not just system design.
• Goal: architecture that supports teams without requiring high-bandwidth communication across team boundaries. Low-bandwidth or zero-bandwidth between teams is desirable. Restricting communication paths to well-defined team interactions produces modular, decoupled systems.

The Four Fundamental Team Types

• All teams should move toward one of these four types. Simplifying to four reduces ambiguity and makes inter-team expectations explicit.
• 1) Stream-aligned: continuous flow of work aligned to a single business domain, product, service, or user journey. Owns delivery from idea to production, as independently as possible. The primary team type: aim for 6-9 out of every 10 teams being stream-aligned. All other team types exist to reduce the burden on stream-aligned teams.
• 2) Enabling: specialists who bridge capability gaps for stream-aligned teams by growing their autonomy. Often focused on build engineering, continuous delivery, or test automation. Knowledge transfer is typically temporary when a new technology is adopted. Goal: increase stream-aligned team autonomy, then step back.
• 3) Complicated-subsystem: builds and maintains a component that requires deep specialist knowledge. Exists to reduce cognitive load on stream-aligned teams. The decision to create one should be driven by cognitive load, not by the convenience of shared ownership.
• 4) Platform: provides self-service APIs, tools, and internal services so stream-aligned teams can deliver with autonomy. Measured by the value of the services it provides to product teams. Think of it as an internal product: ease of use and developer experience are fundamental.

• Don't group functional expertise (UX, architecture, data processing, QA) into functional silos. That model doesn't work for safe and rapid change.

Cognitive Load and Team Boundaries

• Restrict each team's cognitive load to what's manageable. Design system boundaries to fit what a team can hold in its head, not around technical convenience.
• Three types of cognitive load:
  • Intrinsic: fundamental complexity of the problem domain. Reduce through training, technology choices, hiring, pairing.
  • Extraneous: environmental noise and process overhead. Remove through automation and simplification.
  • Germane: the thinking that advances mastery. Create more space for this.
• Domain assignment heuristics:
  • Each domain owned by exactly one team. No shared ownership of components, libraries, or code.
  • A single team can manage 2-3 simple domains.
  • A team responsible for a complex domain shouldn't have additional domains.
  • Avoid giving one team two complicated domains simultaneously.
  • When in doubt, prioritize how the team feels about it.
• Use small, long-lived teams (5-9 people) as the standard. Teams take 2-12 weeks to reach effectiveness. Flow work to the team rather than reshuffling the team to fit the work.
• Define a Team API: a clear description of how to interact with the team, covering code, documentation, communication channels, and priorities. Advertise it, test it, and evolve it.

The Three Interaction Modes

• Explicitly agree on which interaction mode applies to each team relationship. This sets clear expectations and prevents ambiguity about ownership.
• 1) Collaboration: two teams work closely together with overlapping responsibility. Good for rapid discovery and innovation. Takes a productivity hit, so it should be high-value and temporary. One collaboration at a time. Both teams share ownership of outcomes.
• 2) X-as-a-service: one team provides a capability (library, API, platform) that another consumes with minimal coordination. Clear ownership, predictable delivery. The service boundary needs to be well chosen: a poor one creates flow problems. Needs strong product management of the service itself.
• 3) Facilitating: one team helps another grow capabilities or remove blockers. The main mode for enabling teams. Not about building: about improving how other teams build. Requires staff experienced enough to step back from direct delivery.

Common pairings by team type:

Sensing and Evolution

• Most org design happens at a single point in time. Think about how team topologies need to evolve, not just what they should look like today.
• Use awkwardness in team interactions as a signal. Friction often means missing capabilities or misplaced boundaries, not a people problem.
• Triggers for topology evolution:
  • Software has grown too large for one team
  • Delivery cadence is slowing without a clear technical cause
  • Multiple business services depend on a large set of underlying services
• Questions to ask regularly: Is flow as smooth as it could be? Is the current collaboration mode still effective, or should we shift? Are the promises between teams still valid?