Team Topologies

Contents

• Part 01 · Teams as the Means of Delivery
  01The Problem with Org Charts
  02Conway's Law and Why It Matters
  03Team-First Thinking
• Part 02 · Team Topologies That Work for Flow
  04Static Team Topologies
  05The Four Fundamental Team Topologies
  06Choose Team-First Boundaries
• Part 03 · Evolving Team Interactions for Innovation and Rapid Delivery
  07Team Interaction Modes
  08Evolve Team Structures with Organizational Sensing
  09Conclusion: The Next-Generation Digital Operating Model

The Problem with Org Charts

Traditional org charts present a static, hierarchical view that consistently fails to reflect how work actually flows or how people communicate. Skelton and Pais argue that treating the org chart as a faithful map produces bottlenecks, painful reorgs, and systems too large for any team to own — so organizations must instead be designed as adaptive, team-first sociotechnical systems that respect cognitive limits and real communication patterns.

Three Organizational Structures

Drawing on Niels Pflaeging, every organization contains a formal structure (the official chart for compliance), an informal structure (the realm of influence and personal relationships), and a value creation structure (the inter-team reputation network through which work actually flows). Success in knowledge work depends primarily on the latter two — not on the chart.

Org Chart Drift

Like an outdated architecture document, the org chart is always out of sync with reality because people communicate laterally based on real dependencies, not up-and-down reporting lines. Decisions made along stale chart boundaries optimize for one slice of the organization while ignoring upstream and downstream effects.

Teams as Sociotechnical Systems

Organizations are not pure hierarchies of individuals but interconnected systems of people and technology that must be designed holistically. Performance depends on the joint design of people, teams, processes, and tooling.

Team-First Approach

The team — not the individual — is the fundamental unit of software delivery. The team should be stable, long-lived, and autonomous (not isolated), and treated as an indivisible delivery unit; architecture, process, and ownership all flow from that.

Finite Cognitive Capacity

Every team has a hard ceiling on what it can hold in working memory. Ignoring this ceiling produces delivery bottlenecks, quality issues, and missed deadlines, and is the deeper cause behind most "scaling" failures.

Trinity of Intrinsic Motivation

Following Dan Pink, knowledge workers are driven by autonomy, mastery, and purpose. Poor organizational design — handoffs, shared ownership, ceaseless reorgs — erodes all three and explains much of the disengagement seen on broken teams.

Org Chart

The formal hierarchical reporting diagram; useful for compliance but a misleading model of how work is done.

Formal Structure

Officially documented hierarchy and reporting lines.

Informal Structure

The relationship-based network of influence between people, independent of titles.

Value Creation Structure

The reputation-driven, inter-personal network through which work actually flows.

Sociotechnical System

A system whose performance depends on the joint design of people, teams, processes, and technology.

Cognitive Load

The total amount of mental effort being used in working memory by a person or team.

Fast Flow

The book's overarching goal — a steady, rapid stream of valuable change from idea to running software with minimal handoffs.

Delivery Bottleneck

A constraint on flow caused by exceeding team capacity or by org-chart-driven handoffs.

Multiple choice

According to Niels Pflaeging's three organizational structures (as Skelton and Pais use them), through which structure does work in a knowledge-work organization *actually* flow?

• AThe formal structure — the official org chart and reporting lines
• BThe value creation structure — the inter-team reputation network
• CThe informal structure — personal friendships and influence
• DThe matrix structure — dotted-line reporting between departments

True / False

Skelton and Pais treat the org chart as a reliable, up-to-date map of how communication and work happen in the organization.

• TrueTrue
• FalseFalse

Multiple choice

Per Dan Pink's "trinity of intrinsic motivation" that the chapter invokes, which trio drives knowledge workers?

• ASalary, status, security
• BRecognition, growth, balance
• CAutonomy, mastery, purpose
• DOwnership, accountability, alignment

Spot the issue

A 200-person engineering org keeps missing deadlines, so leadership doubles a struggling team from 8 to 16 people and reassigns three new projects to it. Six months later, throughput is even worse. What's the main thing they got wrong?

• AThey didn't hire senior enough engineers
• BThey ignored the team's finite cognitive load capacity and treated people as interchangeable resources
• CThey failed to update the formal org chart to reflect the new structure
• DThey didn't introduce a separate QA function to catch quality issues

Conway's Law and Why It Matters

Mel Conway's 1968 observation — that any system's architecture mirrors the communication structure of the organization that designed it — is treated here as a homomorphic force, not a curiosity. Because architecture and team structure are two sides of the same coin, organizations should deliberately design teams to produce the architecture they want, a practice known as the Reverse Conway Maneuver. The counterintuitive corollary is that not all communication is good; restricting unnecessary cross-team chatter is essential to producing loosely coupled systems.

Conway's Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Communication paths constrain the set of viable architectures, full stop.

Homomorphic Force

The structural mirroring between an organization's communication patterns and its software architecture is predictable and gravitational, not accidental. It is a structure-preserving mapping between the communication graph and the system graph.

Reverse Conway Maneuver

Deliberately evolve team structure and communication paths first so the desired software architecture emerges naturally. As Mike Nygard puts it, "team assignments are the first draft of the architecture."

Ruth Malan's Corollary

"If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins." Organizational shape always defeats wished-for architecture, so wishing harder is not a strategy.

Restricting Communication on Purpose

Not all collaboration is good — high-bandwidth communication between every team produces monolithic, tightly coupled systems. Healthy organizations design for intentional, low- or zero-bandwidth interfaces between most teams.

Software Architecture as an Ethical Activity

Because architecture decisions encode team structure (and vice versa), they have real consequences for people's autonomy, ownership, and well-being. Architecture is therefore a moral as well as a technical concern.

Tooling Shapes Communication

The choice of communication tools — chat platforms, ticket systems, repo layout — reinforces or breaks the team interactions that Conway's Law will then encode into the resulting system. Tools are part of the architecture.

Conway's Law

The principle that system design mirrors organizational communication structure.

Reverse Conway Maneuver

Pre-shaping team boundaries and communication paths to drive a target architecture.

Homomorphism

A structure-preserving mapping; here, between an organization's communication graph and its software architecture.

Loose Coupling

A property where components have few, well-defined dependencies, allowing independent change.

High Cohesion

A property where the elements inside a component belong together and serve a single, clear responsibility.

Inter-team Communication Bandwidth

A spectrum from high-bandwidth (rich, frequent, synchronous) to zero-bandwidth (none required); the goal is to match the level to the architectural intent.

Team Interface

The defined contract — APIs, docs, channels — through which one team is consumed by another, limiting incidental communication.

Bounded Responsibility

A clearly delineated scope of ownership for a team or component, with explicit edges.

Multiple choice

What does Ruth Malan's corollary to Conway's Law assert when the organization's architecture and the desired software architecture are in conflict?

• ASenior architects can override the organizational shape with strong design documents
• BThe software architecture eventually pulls the organization into its shape
• CThe architecture of the organization wins
• DBoth architectures converge on a hybrid form over time

Multiple choice

The Reverse Conway Maneuver is best described as:

• ADrawing the desired architecture first and asking teams to conform to it on paper
• BPre-shaping team boundaries and communication paths so the desired architecture emerges naturally
• CReorganizing teams *after* a new architecture is shipped to ratify the result
• DHiring specialists in every architectural layer so each layer has dedicated owners

True / False

According to Chapter 2, encouraging high-bandwidth communication between every pair of teams is the surest path to a loosely coupled, modular architecture.

• TrueTrue
• FalseFalse

Spot the issue

Leadership wants independently deployable microservices, so they keep the existing single 40-person team, mandate a microservice architecture in an ADR, and add a weekly all-hands sync where everyone discusses every service. A year later, the services can only be released together. What's the main reason this failed?

• AThe team didn't adopt enough automated testing to support microservices
• BMicroservices are the wrong pattern at that team size
• CThe communication structure (one big team, all-to-all sync) shaped the system into a distributed monolith — Conway's Law as a homomorphic force
• DThe ADR wasn't detailed enough about service boundaries

Team-First Thinking

Skelton and Pais argue that organizations should design around small, stable, long-lived teams that own software end-to-end — not around individuals or projects. They draw on Dunbar's research to set hard limits on team and group sizes, and on cognitive-load theory to argue that each team's scope must fit its mental capacity. The chapter introduces the idea of a Team API and lays out heuristics for ownership, longevity, and decomposition along fracture planes.

Team-First Thinking

The team — typically five to nine people working toward a shared goal — is the primary unit of delivery. Individuals serve the team; architecture, processes, and ownership are designed for teams first, with hiring and seating as supporting decisions.

Dunbar's Numbers

Cognitive limits on stable human relationships, used here to size groups: ~5 (close trust), ~15 (deep trust), ~50 (mutual trust), ~150 (recognized capabilities). Organizations should be composed of nested groupings that respect these thresholds.

Three Types of Cognitive Load

Following John Sweller: intrinsic (fundamentals of the problem — the language, the platform), extraneous (incidental environment friction — deployment toil, ticketing), and germane (value-adding learning — the business domain). The strategy is to minimize intrinsic, eliminate extraneous, and protect capacity for germane.

Team Cognitive Load Limit

A team's responsibilities — services, domains, tools — must be bounded so that total cognitive load stays within capacity. Overload destroys flow and quality; assign at most one *complex* domain per team, or two-to-three *simple* domains.

Stable, Long-Lived Teams

Teams need roughly 2–3 months to start performing and should remain stable for at least 1–2 years. Every membership change restarts the Tuckman cycle (forming, storming, norming, performing), so shuffling members destroys accumulated trust and context.

Exclusive Team Ownership

Every software component, service, or subsystem should be owned by exactly one team. Shared ownership produces ambiguity and slows flow; this embodies the "you build it, you run it" principle.

Team API

Each team exposes a well-defined interface to the rest of the organization: code endpoints and libraries, versioning, documentation, working practices, communication channels, and visibility into current and upcoming work. Other teams should be able to consume it with minimal coordination.

Team

A stable group of five to nine people working toward a shared goal as a unit, with collective responsibility and a defined cognitive load.

Dunbar's Number

Robin Dunbar's cognitive limits on the number of stable relationships a human can maintain, applied here at the 5/15/50/150 thresholds.

Intrinsic Cognitive Load

Mental effort tied to the inherent difficulty of the technical task.

Extraneous Cognitive Load

Mental effort caused by environment or process — toil, ceremony, awkward tooling — that adds no value.

Germane Cognitive Load

Mental effort spent on the value-adding thinking the team is paid for, typically mastering the business domain.

Team API

The explicit, documented surface area a team presents — code interfaces, docs, practices, comms channels, roadmap visibility.

Tuckman Model

The forming–storming–norming–performing stages of team development that reset with personnel changes.

Bounded Context

A Domain-Driven Design concept used as a primary fracture plane — an explicit boundary around a coherent domain model owned by one team.

Multiple choice

Following John Sweller's framing as the chapter uses it, which kind of cognitive load should a team deliberately *eliminate* (not merely minimize or protect)?

• AIntrinsic — the fundamentals of the platform and programming language
• BExtraneous — incidental environment friction like deployment toil and ticketing
• CGermane — value-adding learning of the business domain
• DEmotional — interpersonal stress between team members

Multiple choice

What are the four Dunbar thresholds the book uses to size nested organizational groupings?

• A3, 7, 30, 100
• B7, 20, 70, 200
• C5, 15, 50, 150
• D10, 25, 100, 250

Spot the issue

A platform group is rotating engineers between four product teams every quarter "to spread knowledge and avoid silos." Velocity keeps dropping after each rotation. What's the primary problem in Team Topologies terms?

• AThe rotations are too infrequent — they should rotate monthly to build broader skills
• BEach rotation restarts the Tuckman cycle and destroys the trust and shared context stable teams take 2–3 months to build
• CThe platform group should be larger so rotations have less per-team impact
• DThe teams need stronger individual performance reviews to motivate the rotators

Multiple choice

According to the Team API concept, which of the following is not part of a team's published API to the rest of the organization?

• ACode endpoints, libraries, and their versioning
• BDocumentation, working practices, and communication channels
• CVisibility into current and upcoming work
• DInternal performance review scores for each member

Static Team Topologies

Organizations must consciously design stable team structures that fit their specific context — size, technical maturity, and engineering culture — rather than let teams form by accident. The chapter surveys team anti-patterns, reviews the DevOps Topologies catalog of successful and unsuccessful Dev/Ops arrangements, and explains how the right topology must account for flow of change, cognitive load, and inter-team dependencies.

Designed Team Structures

A "topology" is a deliberate arrangement of team types and interactions chosen to match a specific organizational context — not an accident of org-chart inertia. The choice is contingent on size, scale, engineering maturity, and culture.

Static vs. Evolving Topologies

A topology that fits the current context at a given moment is "static" only in the sense of being deliberate today. Organizations must revisit and evolve their topology as engineering maturity, scale, and product complexity change.

DevOps Topologies Catalog

A reference set of patterns and anti-patterns (originally from devopstopologies.com) for arranging Dev and Ops — used as a diagnostic to identify whether current team shapes will support or block flow.

Ad-hoc Team Design Anti-pattern

Creating teams reactively to solve immediate problems and then leaving "skeleton crews" behind produces unstable, incoherent structures with no long-term ownership. The fix is to design topology intentionally, with cognitive load and flow in mind.

Shuffling Team Members Anti-pattern

Treating people as interchangeable resources moved between projects destroys the trust and shared context that high-performing teams take months to build. Long-lived stable teams are the alternative.

Design for Flow of Change

Teams should be organized around the flow of change from idea to running software, not around technical specialties or activities. Activity-aligned teams (e.g., a separate QA team) create handoffs that block flow.

Strode and Huff Dependency Types

Three categories the book uses to analyze inter-team friction: knowledge dependencies (needing info from another team), task dependencies (waiting on another team's work), and resource dependencies (competing for shared people or tools). Minimizing these is a primary goal of topology design.

Team Topology

A consciously designed arrangement of team types and the interaction modes between them.

DevOps Topology

One of the named Dev/Ops patterns from the DevOps Topologies catalog (e.g., "Dev and Ops collaboration," "Dev-Ops silos").

Anti-pattern

A recurring team-design choice that appears helpful but produces bad outcomes.

Flow of Change

The path that a change takes from concept through development to production.

Engineering Maturity

The organization's level of practice in automation, testing, and delivery; a key input when choosing a topology.

Silo

A team isolated by specialty or function whose boundaries impede end-to-end flow.

Knowledge Dependency

Friction caused when one team must consult another to make progress.

Resource Dependency

Friction caused when teams compete for the same scarce people or tools.

Multiple choice

A 200-person engineering org keeps creating new teams reactively whenever a high-priority customer issue appears, then redeploys most members to the next fire while leaving a thin "skeleton crew" behind on the old work. According to Skelton and Pais, what is the core problem with this pattern?

• AIt violates the DevOps Topologies catalog's "Dev and Ops collaboration" pattern
• BTeams are designed reactively rather than intentionally, producing unstable structures with no long-term ownership
• CThe skeleton crews are usually too small to satisfy Dunbar's number of 15
• DIt fails to give each team a dedicated product manager

Multiple choice

Leadership argues that moving developers between projects every quarter keeps skills fresh and prevents stagnation. Why does Team Topologies push back on this practice?

• AIt increases extraneous cognitive load by requiring new tooling each quarter
• BIt biases hiring toward generalists at the expense of specialists
• CTreating people as interchangeable resources destroys the trust and shared context that high-performing teams take months to build
• DQuarterly moves prevent teams from completing the DevOps Topologies maturity assessment

Spot the issue

A company sets up a central QA team that all product teams must hand off to before releases, plus a separate "release engineering" team that owns the deployment pipeline. Stream teams pile up work waiting for these specialists. What's the main topology problem?

• AThe QA and release teams should be merged into a single platform team
• BThe product teams are organized around activities/specialties rather than around the flow of change, creating handoffs that block delivery
• CThe QA team is too small to satisfy the two-pizza rule
• DResource dependencies always outrank knowledge dependencies in severity

Multiple choice

Two stream teams discover they constantly need to ping the database team for schema clarifications before they can make progress on their own backlogs. Using Strode and Huff's categories, this is primarily an example of which dependency type?

• AKnowledge dependency
• BTask dependency
• CResource dependency
• DCognitive dependency

The Four Fundamental Team Topologies

The book's central model: just four team types — stream-aligned, enabling, complicated-subsystem, and platform — are needed to organize for fast flow. The chapter argues that constraining the design space to these four archetypes simplifies organizational design, that stream-aligned teams should dominate, and that the other three exist primarily to reduce the cognitive load on stream-aligned teams.

Stream-Aligned Team

The primary team type, aligned to a single valuable stream of work — a product, service, feature set, user journey, or persona. Empowered to deliver end-to-end without handoffs and to act on customer feedback in near real-time; the dominant team type in any healthy topology.

Enabling Team

A small, specialist team that helps stream-aligned teams overcome obstacles and acquire missing capabilities (test automation, CI/CD, security). Acts as servant-leader coaches, not as a permanent dependency, and moves on once the capability gap is closed.

Complicated-Subsystem Team

A team that owns a part of the system requiring deep specialist knowledge — a video codec, mathematical model, or facial recognition engine. Exists only when embedding that specialism inside a stream-aligned team would overload it; usually rare (often zero or one per organization).

Platform Team

A team that builds and runs an internal platform of self-service APIs, tools, and knowledge that stream-aligned teams consume. The platform reduces cognitive load and accelerates delivery for its internal customers.

Platform as a Product

Platform teams treat their offering as a product, with internal customers, a roadmap, UX, reliability targets, and documentation. Consumers self-serve rather than file tickets; ticket queues are a sign the platform has failed as a product.

Thinnest Viable Platform

The smallest set of APIs, docs, and tools that still measurably helps stream-aligned teams — a TVP can be as minimal as a wiki page if that is what is needed. Platforms should be as thin as possible and grow only with proven demand.

Reducing Cognitive Load via Other Team Types

Enabling, complicated-subsystem, and platform teams all exist to relieve stream-aligned teams of cognitive burdens they cannot reasonably carry. If a specialist team is not measurably reducing stream-aligned cognitive load, its existence is suspect.

Stream

A continuous flow of work aligned to a business domain, capability, product, service, or user persona.

Value Stream

The end-to-end path of activities producing a customer-valued result; stream-aligned teams own a slice of it.

Servant Leadership

The posture enabling teams take — coaching and facilitating rather than dictating or owning the work.

Self-Service Platform

An internal product that stream-aligned teams can use on demand without coordinating with the providing team.

Internal Customer

A stream-aligned team or other consumer of a platform's services inside the same organization.

Two-Pizza Team

Amazon's heuristic for team size (~5–9 people); the upper bound for trust-based collaboration.

TVP (Thinnest Viable Platform)

The minimal platform offering that meaningfully accelerates stream-aligned teams.

Developer Experience (DX)

The usability, documentation, and ergonomics of a platform offering from a consumer's perspective.

Multiple choice

In a healthy Team Topologies design, which of the four fundamental team types should dominate by count in the organization?

• APlatform teams, since they unlock leverage for everyone else
• BEnabling teams, since they spread best practices fastest
• CStream-aligned teams, since they own end-to-end delivery of value
• DComplicated-subsystem teams, since they contain deep expertise

Spot the issue

A "platform team" has been standing up an internal Kubernetes offering for two years. Stream teams must file tickets to provision namespaces, wait days for approval, and ping the platform team in Slack for every config tweak. Leadership wonders why the platform isn't accelerating delivery. What's the most accurate Team Topologies critique?

• AThe platform team is too small — it needs more headcount to handle the ticket queue
• BKubernetes is the wrong platform technology for this organization
• CThe platform isn't being run as a product with self-service; a ticket queue is a sign the platform has failed as a product
• DStream teams should be merged into the platform team to remove the boundary

Multiple choice

A startup is deciding what their first internal platform should look like. Which choice best reflects the Thinnest Viable Platform principle?

• AStart with the smallest set of APIs, docs, or even a wiki page that measurably helps stream teams, and grow only with proven demand
• BBuild a polished portal with templates, dashboards, and a service catalog before any team uses it
• CWait until the company has 200 engineers before introducing any platform at all
• DAdopt a vendor's full reference platform so internal teams don't need to choose anything

True / False

Enabling teams are permanent fixtures intended to own and operate a capability — like security or testing — on behalf of stream-aligned teams forever.

• TrueTrue
• FalseFalse

Choose Team-First Boundaries

Chapter 6 explains how to draw the right boundaries between teams and software so that each team owns a coherent, cognitively manageable slice of the system. It catalogs the kinds of "monoliths" — not just software ones — that block team autonomy and introduces fracture planes, with a single litmus test: a boundary is good only if it produces more autonomous teams with reduced cognitive load.

Team-First Boundaries

Start with what one team can own and understand, then choose software, infrastructure, and process boundaries to match. Never ask a team to shoulder more cognitive load than it can sustain.

Hidden Monoliths

Beyond application monoliths, the book names joined-at-the-database monoliths, monolithic builds, monolithic releases, monolithic models (forced standardization across products), and monolithic workplaces (one-size-fits-all offices). All of them constrain team autonomy in different ways.

Fracture Plane

A natural seam in the software or organization where a clean split is possible. The chapter catalogs candidate seams to evaluate when carving systems and team boundaries.

Business Domain Bounded Context

The book's preferred fracture plane — splits aligned with Domain-Driven Design bounded contexts, because they track how the business actually thinks and changes. First choice before any other seam.

Change Cadence Fracture Plane

Separate parts of the system that need to change at different frequencies so the slowest-moving piece does not set the pace for the rest. A common secondary seam after bounded contexts.

Additional Fracture Planes

Regulatory compliance, team location and time zone, risk appetite, performance isolation, technology stack (especially legacy), and user persona. Each is a candidate seam when the preferred bounded-context split is not enough.

Fracture Plane Litmus Test

"Does the resulting architecture support more autonomous teams with reduced cognitive load?" If not, the proposed boundary is wrong, no matter how clean it looks on a diagram.

Team-First Boundary

A software, process, or organizational boundary chosen primarily to fit one team's ownership and cognitive capacity.

Application Monolith

A single large deployable application that several teams must coordinate to change.

Joined-at-the-Database Monolith

Multiple applications coupled through a shared database schema, blocking independent evolution.

Monolithic Release

A release process that forces unrelated changes to ship together on a single cadence.

Monolithic Model

Forced standardization of tools, languages, or practices across products that would be better served by variety.

Fracture Plane

A boundary line along which software can be cleanly split into team-sized pieces.

Bounded Context

A self-consistent slice of the domain model from DDD; the preferred basis for team-first boundaries.

Cognitive Load Limit

The ceiling on how much domain and technical complexity one team can hold; a hard constraint on boundary choices.

Multiple choice

According to Chapter 6, when teams are evaluating a proposed software boundary, which single litmus test decides whether the boundary is good?

• ADoes the split reduce the number of microservices below a target threshold?
• BDoes the resulting architecture support more autonomous teams with reduced cognitive load?
• CDoes the boundary follow the official org chart's department lines?
• DDoes the split eliminate every form of inter-team dependency?

Multiple choice

When choosing a fracture plane, which seam does the book name as the preferred first choice, before any other?

• AChange cadence — split parts of the system that change at different frequencies
• BRegulatory compliance — split along audit and risk boundaries
• CTechnology stack — separate legacy code from modern code
• DBusiness domain bounded context — split aligned with DDD bounded contexts

Spot the issue

A company has split its application into ten microservices owned by ten teams. However, all ten services share a single relational database and every schema change requires coordinating a release across all teams. Which "hidden monolith" does this most clearly illustrate?

• AApplication monolith — the services are really one big app
• BMonolithic model — forced standardization on one tech stack
• CJoined-at-the-database monolith — multiple applications coupled through a shared schema
• DMonolithic workplace — a one-size-fits-all office design

Multiple choice

A reporting subsystem changes once a quarter for regulatory reasons, while the customer-facing checkout flow ships daily. Wrapping them in one team currently forces every checkout release to drag the reporting code along. Which fracture plane most directly addresses this?

• AUser persona fracture plane
• BChange cadence fracture plane
• CRegulatory compliance fracture plane
• DPerformance isolation fracture plane

Team Interaction Modes

Defining team boundaries alone is insufficient — organizations must also explicitly define how teams interact. Skelton and Pais introduce three well-defined interaction modes (Collaboration, X-as-a-Service, and Facilitating) that replace ad-hoc, everyone-talks-to-everyone communication with intentional, low-friction patterns. Choosing the right mode for each pair of teams reduces cognitive load, clarifies responsibilities, and helps the organization sense and adapt.

Collaboration Mode

Two teams work closely together for a defined period to discover new technology, patterns, or practices. It accelerates learning at the cost of higher cognitive load and blurred responsibilities, and a team should collaborate with at most one other team at a time.

X-as-a-Service Mode

One team consumes something — an API, component, or platform — that another team provides as a service, with minimal ongoing interaction. Gives clear ownership and predictable delivery, but demands excellent Developer Experience and a product mindset from the providing team.

Facilitating Mode

One team — typically an Enabling team — helps another team learn, unblock, or adopt a practice, focusing on improving the quality of interactions rather than building software. Temporary by nature; aimed at growing capability in the team being helped.

Suitability Matrix

A table the book provides showing typical vs. occasional modes per team type: stream-aligned teams typically collaborate and consume X-as-a-Service; enabling teams typically facilitate; complicated-subsystem and platform teams typically operate as X-as-a-Service.

Intermittent Collaboration

Drawing on Bernstein's research, the authors argue that intermittent (not constant) collaboration produces better solutions, so interactions should be punctuated rather than always-on. Persistent collaboration is a signal that team boundaries or skill mix are wrong.

Evolving Interaction Modes

Pairs of teams often start in Collaboration during discovery and graduate to X-as-a-Service once interfaces stabilize; Facilitating is applied tactically when a capability gap appears. Interaction modes are expected to change deliberately over time.

Reshaping Interactions to Reshape Architecture

Because of Conway's Law, deliberately changing interaction modes is a lever to reshape the software architecture itself. Moving a pair from Collaboration to X-as-a-Service crystallizes a service boundary in the code.

Interaction Mode

A named, well-defined pattern describing how two teams relate to each other.

Collaboration

Joint, high-bandwidth work between two teams toward a shared outcome, used for discovery.

X-as-a-Service (XaaS)

A consumer/provider relationship in which one team uses another team's offering with minimal coordination.

Facilitating

Coaching-style help offered by one team — usually Enabling — to improve another team's practices.

Developer Experience (DX)

The usability, documentation, and ergonomics of what an X-as-a-Service team offers; a primary KPI for platform and complicated-subsystem teams.

Team Behaviors

Habits and norms a team adopts to make its current interaction mode effective.

Promiscuous Pairing

Deliberate, time-bounded mixing of people between two teams during a Collaboration phase to spread knowledge.

High-Bandwidth Interaction

Rich, frequent, synchronous communication; appropriate for Collaboration but expensive when used everywhere.

Multiple choice

Which of the three interaction modes is characterized by one team consuming something — an API, component, or platform — that another team provides, with minimal ongoing interaction?

• ACollaboration mode
• BFacilitating mode
• CX-as-a-Service mode
• DPromiscuous pairing mode

Multiple choice

According to the suitability matrix in the chapter, what is the typical interaction mode for an Enabling team?

• ACollaboration with multiple stream-aligned teams at once
• BFacilitating
• CX-as-a-Service
• DPermanent embedding inside a stream-aligned team

True / False

Skelton and Pais argue that constant, always-on collaboration between teams produces better solutions than intermittent collaboration.

• TrueTrue
• FalseFalse

Spot the issue

A stream-aligned team is simultaneously in Collaboration mode with the data platform team, the security team, and the mobile team to "move faster on a new launch." Three months in, the team is overwhelmed, ownership is unclear on three subsystems, and nothing has shipped. What's the main thing they got wrong?

• AThey should have switched all three relationships to Facilitating mode instead
• BA team should collaborate with at most one other team at a time, because Collaboration carries high cognitive load and blurs responsibilities
• CThey forgot to assign a project manager to coordinate the three collaborations
• DThey should have hired more senior engineers before starting collaborations

Evolve Team Structures with Organizational Sensing

Team topology is an evolving rather than fixed design — the **decision rules** used to adapt structure matter more than the current structure itself. The chapter identifies concrete trigger points that signal a topology needs to change and describes Organizational Sensing: the capability of well-defined teams and interactions to act as a distributed sensor network detecting friction, opportunity, and market change.

Organizational Sensing

The emergent capability — created by well-defined team types plus explicit interaction modes — to detect changes in the external environment and internal flow, and adapt structure in response. It is the property the rest of the book is in service of.

Trigger Points for Evolution

Concrete signals that indicate a topology change is needed: software has grown too large for one team, delivery cadence is slowing, or many business services depend on the same underlying components. Each trigger maps to a specific structural move.

Software Too Big for One Team

When a codebase exceeds the cognitive load capacity of one team — symptoms include backlog growth, "go ask Alice" specialization, and rising documentation complaints — the response is to split along a fracture plane, not to add more people to the same team.

Slowing Delivery Cadence

A drop in release frequency or rising lead time signals the team has lost autonomy and is waiting on too many external teams, often pointing to a need for platform extraction or for changing interaction modes.

Multiple Services on Shared Components

Common in finance, insurance, and government: many business services depending on the same underlying systems. The fix is to platformize the shared lower layers and let stream-aligned teams own the higher business services.

Topologies Differ by Maturity

Early-stage products favor more Collaboration to discover the design, while mature products favor X-as-a-Service for predictability. Different parts of one company will use very different topologies at the same time, and that is healthy.

Operations as Sensory Input

Echoing Jeff Sussna — "operations is not the output of design, but an input" — production telemetry and operations feedback are treated as primary inputs to topology evolution, not afterthoughts.

Avoid Big-Bang Reorgs

Continuous, small structural adjustments driven by sensing outperform periodic top-down reorganizations, which destroy team relationships and accumulated context. Reorgs are expensive; evolution is cheap.

Organizational Sensing

The organization's ability, via its team and interaction design, to perceive and respond to internal and external change.

Trigger Point

A specific observable condition that warrants a topology change.

Platformization

Extracting shared lower-level services from many business systems into a platform team's offering exposed as X-as-a-Service.

Re-teaming

The deliberate, periodic restructuring of team membership in response to sensing signals, used in moderation.

Decision Rules

The heuristics — "if X, then change Y" — an organization uses to decide when and how to evolve.

Lifetime Service Viability

The total cost and capability needed to own a service from build through retirement.

Lead Time

The elapsed time from a change being requested to it running in production; a primary flow metric.

Big-Bang Reorg

A periodic top-down restructuring that resets team relationships; the anti-pattern this chapter argues against.

Multiple choice

The chapter argues that the emergent capability of an organization to detect changes in its environment and internal flow — and adapt structure in response — arises from which combination?

• AFrequent big-bang reorgs combined with annual strategy offsites
• BA strong PMO that centralizes all coordination decisions
• CWell-defined team types plus explicit interaction modes
• DAdopting a single, standardized topology across the whole company

Multiple choice

A team's codebase has grown so large that backlogs are exploding, "go ask Alice" specialization is rampant, and onboarding docs keep multiplying. According to the chapter, what is the correct response to this trigger?

• AAdd more engineers to the existing team to spread the load
• BSplit the team and its software along a fracture plane
• CSwitch from X-as-a-Service to Collaboration with downstream consumers
• DFreeze new features until the documentation backlog is cleared

Spot the issue

A bank notices that more than a dozen business services all depend on the same underlying customer, account, and ledger components, and stream-aligned teams keep blocking on each other for low-level changes. Leadership proposes a quarterly big-bang reorg to "shuffle people closer to the components they use most." What's the main thing they got wrong?

• AThe right move is to platformize the shared lower layers as X-as-a-Service rather than shuffle people via a big-bang reorg
• BThey should have first switched every team pair into Collaboration mode
• CThey should have merged all the business services into a single stream-aligned team
• DThey should standardize on one technology stack across all services first

True / False

According to the chapter, the same topology and interaction modes should be applied uniformly across all parts of a company, regardless of product maturity.

• TrueTrue
• FalseFalse

Conclusion: The Next-Generation Digital Operating Model

The conclusion synthesizes the book into a unified digital operating model built on four fundamental team types and three interaction modes, all governed by team-first thinking. Team Topologies is necessary but not sufficient: it must rest on healthy culture, strong engineering practices, sound financial practices, and clear business vision. The chapter closes with a practical starter sequence for adopting the model.

The Unified Model

Any modern digital organization can be designed and adapted using only seven primitives — four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes (collaboration, X-as-a-service, facilitating) — plus team-first principles.

Strategic Use of Conway's Law

Architecture and organization are mirrors. Intentionally designing teams to match the desired architecture (the Inverse Conway Maneuver) is a primary strategic tool, not an afterthought, and is the most reliable way to change a stuck architecture.

Team API as Operating Primitive

The Team API — code endpoints, versioning, docs, working hours, communication preferences, visible work — is what makes X-as-a-Service possible at human scale. Without it, every interaction degenerates into Collaboration.

Four Prerequisites Beyond Topology

Topology alone fails without: healthy culture and psychological safety, engineering excellence (CI/CD, test-first, blameless postmortems), sound financial practices (no CapEx/OpEx split, no project-mode budgeting), and clear business vision. The model is layered on top of these, not a substitute for them.

Five-Step Starter Sequence

A practical adoption path: (1) start with team-first fundamentals, (2) identify value streams, (3) define the Thinnest Viable Platform, (4) identify capability gaps and address them with enabling teams or coaching, (5) practice and normalize the three interaction modes.

Adaptive Sensing Organization

The end state is not a static org chart but a continuously adapting, sensing organization whose decision rules let it reshape itself for fast flow as conditions change. The model is a means to that end, not an end in itself.

Psychological Safety as Foundation

Per Edmondson, members must be able to speak up, dissent, and fail without punishment. Without psychological safety, none of the interaction modes work — Collaboration becomes silent, Facilitating becomes judged, X-as-a-Service becomes blame.

Digital Operating Model

The combined design of teams, interactions, platforms, and decision rules an organization uses to deliver digital products at speed.

Inverse Conway Maneuver

Deliberately structuring teams to produce the software architecture the business wants.

Engineering Excellence

Practices such as test-first development, continuous delivery, pairing, and blameless incident review that the model assumes.

Psychological Safety

The team-level cultural prerequisite in which members can speak up, dissent, and fail without punishment.

Capability Gap

A missing skill or practice on a stream-aligned team that an enabling team is brought in to close.

Value Stream

The end-to-end flow of work required to deliver value to a customer; the unit around which stream-aligned teams are organized.

Project-Mode Budgeting

Funding work as a finite project rather than funding stable teams; an anti-pattern this model rejects.

Lifetime Service Viability

A team-ownership lens asking whether a team can sustainably own a service across its whole lifespan.

Multiple choice

The conclusion claims that any modern digital organization can be designed using only seven primitives. What are they?

• AThree layers (presentation, business, data) plus four delivery roles
• BFive team types plus two communication channels
• CFour team types (stream-aligned, enabling, complicated-subsystem, platform) plus three interaction modes (collaboration, X-as-a-service, facilitating)
• DFour product stages plus three release cadences

Spot the issue

A leadership team adopts the four team types and three interaction modes but keeps project-mode budgets, allows blame in incident reviews, and has no psychological safety. A year later, "X-as-a-Service" relationships have devolved into finger-pointing and Collaboration meetings sit silent. What's the main thing they got wrong?

• AThey chose the wrong fracture planes when splitting their teams
• BTopology alone fails without the four prerequisites — healthy culture, engineering excellence, sound financial practices, and clear business vision
• CThey needed more enabling teams to coach each stream-aligned team individually
• DThey should have skipped the interaction modes and let teams self-organize

Multiple choice

Per the chapter, what is the role of the Team API in making the unified model actually work at human scale?

• AIt is an optional documentation artifact for compliance audits
• BIt is what makes X-as-a-Service possible at human scale; without it, every interaction degenerates into Collaboration
• CIt is a contract enforced by the PMO that prevents teams from talking outside of approved channels
• DIt is a tool used only by platform teams to publish SDKs

Multiple choice

The chapter offers a practical five-step starter sequence for adopting the model. Which step comes first?

• ADefine the Thinnest Viable Platform
• BIdentify value streams
• CStart with team-first fundamentals
• DPractice and normalize the three interaction modes