Library→Foundations→Team Topologies
Team Topologies
Matthew Skelton and Manuel Pais's framework for organizing software teams. Four team types, three interaction modes, and why Conway's Law means team structure is architecture.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
Conway's Law
In 1967, Melvin Conway observed: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." This is Conway's Law, and it is one of the most reliably observed phenomena in software engineering.
If you have three backend teams, you will have three backend services. If you have a DBA team separate from development, you will have slow database changes. Team structure shapes architecture, whether you intend it or not.
Team Topologies inverts the argument: if your team structure determines your architecture, design your team structure to produce the architecture you want. This is the Inverse Conway Maneuver.
The four team types
Stream-aligned team
Aligned to a flow of work
The primary team type. A stream-aligned team owns a slice of the product end-to-end — from user-facing feature to production deployment. They have all the skills they need to deliver without depending on other teams. Conway's Law: this team owns its part of the architecture.
Goal
Deliver value continuously to users and the business
Example
The Nexus Corp payments team owns the checkout flow, the payment service, and its database.
Enabling team
Accelerates stream-aligned teams
An enabling team helps stream-aligned teams acquire capabilities they need but don't yet have. They are not a bottleneck or gatekeeper — they work to make themselves unnecessary. A DevOps enabling team helps product teams build their own CI/CD pipelines, then moves on.
Goal
Increase stream-aligned team capability; minimize dependencies
Example
A DevOps practice team that runs workshops, builds platform templates, and mentors teams on observability.
Complicated-subsystem team
Owns a complex component
When a subsystem is so technically complex that it requires specialist expertise — graphics rendering, actuarial calculations, ML model serving — a dedicated team reduces the cognitive load on stream-aligned teams. This is a deliberate carve-out, not a default way to organize.
Goal
Reduce cognitive load on stream-aligned teams for complex subsystems
Example
A team that owns the real-time pricing engine — too complex for a product team to maintain alongside feature work.
Platform team
Provides self-service infrastructure
A platform team builds and operates the internal platform that stream-aligned teams use to deploy, monitor, and operate their services. The platform must be good enough that teams choose to use it — if it requires constant coordination, it is a bottleneck, not a platform.
Goal
Reduce cognitive load on stream-aligned teams through self-service
Example
An internal developer platform: one-click deployment, standardized observability, automated compliance checks.
The three interaction modes
Teams do not interact in a single way. Team Topologies defines three modes of interaction — and specifies when each is appropriate. The goal is to minimize unnecessary coordination overhead while enabling the right kind of collaboration when needed.
Collaboration
Two teams work closely together, often on the same codebase or problem. High bandwidth. Use for exploration and discovery. Avoid as a permanent mode — it creates coupling.
Use when: When discovering new capabilities or solving complex integration problems.
X-as-a-Service
One team provides a service with a clear API and SLA. The consuming team uses it without needing to understand the implementation. Low coordination overhead. The target for most platform interactions.
Use when: Once a capability is well-understood and stable — APIs, platforms, internal tools.
Facilitating
An enabling team coaches another team. The goal is to transfer knowledge and capability, not to do the work for them. The enabling team works to make itself unnecessary.
Use when: When a team needs to build a new capability it doesn't yet have.
Cognitive load as a design constraint
Skelton and Pais argue that team design should be constrained by cognitive load — the total amount of mental work a team can handle. Teams that own too much surface area become unable to focus, move slowly, and produce low-quality work.
Three types of cognitive load:
Intrinsic
The complexity inherent to the problem — the business domain, the technical requirements. Cannot be eliminated; must be managed.
Extraneous
Cognitive load from incidental complexity — build systems, deployment scripts, environment setup, process compliance. Should be minimized aggressively.
Germane
Cognitive load that builds long-term capability — learning the domain, mastering the tools. Should be encouraged.
A team's job is to minimize extraneous cognitive load (via platform teams, tooling, automation) so that engineers can spend their mental energy on intrinsic complexity — the actual hard problems they are hired to solve.
Platform teams and DevOps
Team Topologies provides the organizational blueprint for what DevOps practitioners call "platform engineering." A platform team builds internal developer tooling that stream-aligned teams use self-service — CI/CD, observability, cloud abstractions, security guardrails.
The critical distinction: a platform is not a gate or a bottleneck. If stream-aligned teams must file tickets to use the platform, it is a traditional ops team in new clothes. A genuine platform team operates like an internal product team — with a roadmap, user research, and an API.
Anti-pattern: Ops team as gate
Pattern: Platform as product
Further reading
Team Topologies — Skelton & Pais
The source. The full treatment of team types, interaction modes, cognitive load, and the Inverse Conway Maneuver.
Conway's Law — Melvin Conway (1968)
The original paper: 'How do committees invent?' Four pages. The foundational observation that team structure shapes system structure.
The DevOps Handbook — Part V
Organizational patterns for DevOps. How to structure teams for fast flow across large organizations.
Accelerate — Forsgren, Humble, Kim
Chapter 7: Management Practices for Software. The research link between team autonomy, organizational structure, and delivery performance.