Team Topologies

---

Origins

Team Topologies was developed by Matthew Skelton and Manuel Pais and published in their 2019 book of the same name.¹ The framework drew on years of consulting work helping organizations design team structures for fast flow of value. Within a few years of publication, Team Topologies became one of the most influential ideas in modern software organization design.

Unlike most scaling frameworks, Team Topologies does not prescribe ceremonies or roles. It prescribes team shapes and the interactions between them.

The Four Team Types

Stream-Aligned Team

The default and dominant team type. A stream-aligned team owns a single flow of value end-to-end — a product, a service, a journey. The team is cross-functional, has the skills to deliver alone, and minimizes its need to coordinate with other teams. Most teams in a healthy organization should be stream-aligned.

Enabling Team

A small group with specialized expertise that helps stream-aligned teams adopt new practices. Examples: a security enabling team that helps product teams build secure code; an accessibility enabling team that teaches accessibility patterns. Enabling teams are not permanent partners; they engage, transfer capability, and disengage.

Complicated-Subsystem Team

A team owning a subsystem that requires rare specialist expertise — typically deep mathematical, scientific, or engineering knowledge. Examples: an ML inference team, a video encoding team, a cryptographic library team. The team exists because the subsystem is too complex for a stream-aligned team to handle in addition to its main work.

Platform Team

A team that builds and maintains an internal platform consumed by stream-aligned teams. Examples: an internal developer platform, an observability platform, an authentication platform. The platform is exposed as a service; consuming teams self-serve rather than coordinate.

The Three Interaction Modes

Team Topologies' second contribution is to name the ways teams interact:

Collaboration

Two teams work together closely for a defined period, blending their skills. Used when the work is novel or boundaries are unclear. High bandwidth but high cost — should be temporary.

X-as-a-Service

One team consumes another's output through a stable interface. The consuming team doesn't need to know how the provider works; the provider doesn't need to know how the consumer uses it. The mode most teams should aim for in steady state.

Facilitating

One team helps another team learn or improve a capability. Used by enabling teams supporting stream-aligned teams. Temporary by design.

The Core Argument

The framework's central insight: most organizations have implicit, accidental team structures that produce predictable dysfunctions. Conscious team topology design — picking which teams are stream-aligned, which are platforms, which interactions are X-as-a-service vs. collaboration — produces dramatically better flow of value.

Conway's Law applies again: the architecture mirrors the team structure. By choosing the team structure deliberately, the organization shapes the architecture intentionally rather than accidentally.²

The "Cognitive Load" Concept

Team Topologies introduces or popularizes the idea of team cognitive load: the amount of mental complexity a team must hold to do their work effectively. Teams whose cognitive load exceeds capacity slow down, drop quality, and burn out — regardless of how skilled the individuals are.

The framework's recommended response: limit cognitive load by limiting team scope, abstracting away complexity through platform teams, and applying Cognitive Load Theory to team design.³

Why It Works

• Diagnostic clarity. The four team types give vocabulary for naming what a team is supposed to be.
• Conscious interaction design. Naming the interaction mode prevents accidental collaboration that should be X-as-a-service (or vice versa).
• Cognitive load focus. The framework explicitly addresses the most common cause of slow teams.
• Non-prescriptive at team level. Like Flight Levels and Amplio, Team Topologies stays out of how individual teams operate internally.

Common Failure Modes

• Renaming without restructuring. Calling existing teams "stream-aligned" without changing their boundaries or interactions produces no benefit.
• Permanent enabling teams. Enabling teams are temporary by design. If they become permanent, they're really stream-aligned or platform teams in disguise.
• Default-to-collaboration. Collaboration is high cost. Teams that collaborate on everything produce coordination overhead instead of value flow.
• Platform teams without product mindset. A "platform" built as a project rather than a product fails to serve its consumers. Platforms need PMs, roadmaps, and customer focus too.

Coaching Tips

Audit existing team types.

Many teams are misclassified. Map each to one of the four types — the mismatches reveal restructuring opportunities.

Make collaboration temporary.

Long-running collaboration is a smell. Either merge the teams or move to X-as-a-service.

Treat platforms as products.

Platform teams need PMs, roadmaps, and customer (i.e., consuming team) focus. Without it, the platform becomes shelfware.

Measure cognitive load.

Use the framework's cognitive-load assessment. Teams running hot will not improve through more discipline — reduce their scope.

Apply Conway's Law deliberately.

You want a specific architecture? Design the team structure that would naturally produce it.

Don't just rename.

Calling teams stream-aligned without changing their boundaries is theatre. The labels follow the structure, not the other way around.

Summary

Team Topologies has become the most influential team-design framework of the late 2010s and 2020s. By providing vocabulary for both team types and team interactions, it makes structural choices that were previously implicit explicit. The framework rewards organizations willing to think hard about how their teams should be shaped — and punishes those who use the vocabulary without changing the substance. Combined with explicit cognitive-load management, the approach produces team structures that scale dramatically better than accidental ones.

Back to Scaling Agile