Team Topologies

Skelton & Pais (2019) framework for organizing teams to maximize fast flow. Four team types + three interaction modes.

Overview

What Team Topologies is

Team Topologies (Matthew Skelton and Manuel Pais, 2019; 2nd ed. updates ongoing) is the canonical organizational design framework for DevOps-aligned teams. It builds on Conway's Law and on cognitive-load theory, and it is the most-cited org-design text in modern DevOps.

The thesis: organize teams to MINIMIZE COGNITIVE LOAD and MAXIMIZE FAST FLOW. Four team types, each with a specific purpose, interact through three defined modes.

The four team types

Stream-aligned (the default; ~80% of teams) — Aligned to one valuable stream of work: a product, customer journey or business capability. End-to-end ownership: design, build, test, deploy, operate, retire. Delivers without waiting on other teams. Typical size 5-9 people (two-pizza rule) — "Checkout team," "Payments team," "Search team"
Enabling (specialists who teach) — Helps stream-aligned teams overcome obstacles or build missing capabilities. Time-boxed: come in, transfer knowledge, leave. NOT permanent operators of the capability — "Performance Enabling team" optimizing a slow service; "Security Enabling team" helping adopt threat modeling
Complicated subsystem (specialists who own) — Builds and maintains a subsystem requiring specialist knowledge, reducing cognitive load on stream-aligned teams. Fewer in number; only created when complexity warrants — ML model engineering, video transcoding, real-time bidding, payment-processor integration
Platform (self-service products) — Internal services stream-aligned teams consume as self-service. Run as a PRODUCT TEAM with internal customers, a roadmap and SLAs to internal users — Internal Kubernetes, observability, CI/CD and data platforms

> [!TIP] The "Thinnest Viable Platform" principle: only build platform capabilities when they are a clear net win for the org.

The three interaction modes

Collaboration — Two teams work closely for a defined period (typically weeks to months) on a hard problem — High; expensive; time-boxed
X-as-a-Service — One team provides a self-service capability the other consumes; the standard Platform pattern — Low
Facilitating — One team, usually Enabling, helps another build a capability — Time-boxed; bridges Collaboration to X-as-a-Service

Conway's Law

Melvin Conway, 1968: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Your software architecture WILL mirror your organizational structure. Want microservices but have monolithic teams, and you get a distributed monolith. The practical move is the "Inverse Conway Maneuver": deliberately restructure teams to enable the desired architecture.

Cognitive load

Cognitive-load theory comes from John Sweller's educational-psychology research (1988), which Team Topologies applies to teams.

Intrinsic — Complexity of the problem itself
Extraneous — Complexity from poor tooling, processes, environments
Germane — Building expertise

> [!IMPORTANT] Teams must operate within their cognitive bandwidth. A stream-aligned team that owns 12 microservices, the database, the CI/CD pipeline AND the K8s cluster has too much extraneous load. Platform teams ABSORB extraneous load.

Why this matters in interviews

Diagnose org problems using the Team Topologies vocabulary
Recognize when a Platform team should be created, or shouldn't
Apply the Inverse Conway Maneuver
Spot anti-patterns: "shadow IT" (covert platform teams), "pet platform" (platform team building toys nobody uses), "DevOps team" (re-creates the dev/ops silo)

The book is short and dense. Read it.

Key concepts

Stream-aligned team: The default team type. Aligned to one valuable stream of work (a product, journey, or capability). End-to-end ownership: design, build, test, deploy, operate. Two-pizza size. ~80% of teams in a healthy org.
Enabling team: Specialists who teach, then withdraw. Time-boxed engagements. Help a stream-aligned team adopt a new capability (security, performance, accessibility). NOT permanent operators.
Complicated Subsystem team: Specialists who own. A subsystem requiring deep specialist knowledge (ML, video, payments). Reduces cognitive load on stream-aligned teams who consume the subsystem.
Platform team: Provides internal services consumed as a self-service platform. Internal Kubernetes platform, observability, CI/CD. Treated as a PRODUCT TEAM with internal customers, roadmap, SLAs.
Conway's Law: Verbatim Melvin Conway 1968: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Software architecture mirrors org chart.
Inverse Conway Maneuver: Deliberately restructure teams to enable the desired architecture. If you want microservices, organize into stream-aligned product teams. The reverse (re-architect first) doesn't work without org change.
Thinnest Viable Platform: Only build platform capabilities when the centralized version is a clear net win. Resist building "everything ourselves." Platforms should make the easy path the right path.
Cognitive load (intrinsic / extraneous / germane): Intrinsic = problem complexity. Extraneous = poor tooling/processes. Germane = expertise-building. Platforms absorb extraneous load. Don't overload teams beyond their cognitive bandwidth.

When to use it

Diagnosing slow value flow — usually traceable to mis-aligned team boundaries
Designing a Platform team — clarifying the team's mission and customer model
Justifying or resisting "we should have a DevOps team" (usually the wrong answer per Team Topologies)
Aligning teams to a microservices architecture — Inverse Conway Maneuver

Interview questions

Walk me through the four team types and three interaction modes.
When should an org create a Platform team?
What's the Inverse Conway Maneuver and when do you apply it?