Team Topologies

Definition

Team Topologies is an organisational model, popularised by Matthew Skelton and Manuel Pais, that classifies software delivery teams into four fundamental types and three interaction modes. It treats team structure as a first-class design decision — as consequential as system architecture — with the explicit goal of enabling fast, sustainable flow of change.

The Four Team Types

• Stream-aligned team: the default. Aligned to a business capability, product or user journey. Owns delivery end-to-end.
• Platform team: builds internal services that stream-aligned teams consume — CI/CD platforms, observability, service mesh, developer environments.
• Enabling team: a temporary specialist team that helps stream-aligned teams acquire a missing capability — security, performance, mobile, ML — then withdraws.
• Complicated-subsystem team: owns a component so specialised that embedding the expertise in every stream team is impractical — real-time video codecs, tax engines, cryptographic modules.

The Three Interaction Modes

• Collaboration: two teams work closely for a bounded period to discover something new. High bandwidth, high cost, temporary.
• X-as-a-Service: one team consumes a well-defined capability provided by another. Low bandwidth, low friction, long-lived.
• Facilitating: an enabling team coaches a stream team through a change and steps back.

Why It Matters

Most delivery slowdowns are not code problems — they are organisational structure problems. Teams stepping on each other, hand-offs multiplying, no clear ownership of shared services. Conway's Law guarantees that the architecture mirrors the org chart, so an org chart designed by accident produces an architecture designed by accident. Team Topologies replaces accident with intent.

Real-World Example

A UK online lender ran 14 delivery squads with unclear boundaries. Every change to the credit-decision engine required coordination across five squads because ownership was shared. Cycle time from idea to production averaged 47 days. After a Team Topologies redesign: one complicated-subsystem team owned the credit engine, three stream-aligned teams owned onboarding, servicing and collections, one platform team owned observability and CI, and one enabling team rotated security patterns into all squads. Ownership boundaries were published. Cycle time dropped to 11 days within four months. Incident count in the credit engine fell by 60 % because a single team could hold the whole picture in their heads.

Cognitive Load as the Guiding Metric

The model's core insight is that a team has a finite cognitive capacity. If the domain a team owns exceeds that capacity, the team slows, quality drops and turnover rises. Sizing team scope by cognitive load — not by lines of code, story points or backlog size — leads to more stable teams. The consequence is often uncomfortable: some codebases need to be split, some need to be handed to a platform team, some need an enabling engagement to teach the receiving team.

How to Adopt It Well

1. Map current teams honestly — not as designed, as actually behaving. Most orgs discover accidental complicated-subsystem teams and missing platform teams.
2. Identify cognitive-load hot spots — teams owning too many unrelated things.
3. Draw target topologies — the smallest change that clarifies ownership and reduces load.
4. Publish interaction modes for every pair of teams that must work together.
5. Review quarterly — topologies evolve as products and platforms mature.

Practical Lessons Learned

• Platform teams fail when they behave like ivory towers. Their success is measured by how easily stream teams can self-serve.
• Enabling teams must have an exit date. Permanent enabling teams turn into gatekeepers.
• Complicated-subsystem is a warning label, not a promotion. If everything is a complicated subsystem, the architecture is over-fragmented.
• Collaboration mode is expensive. Use it deliberately and time-box it, or it becomes the default and cycle time collapses.
• The org chart is the roadmap. Any target architecture inconsistent with the team topology will not survive.

Expert Tips

• Publish a "team API" per team — purpose, mission, boundaries, dependencies, current interaction modes. It is the highest-leverage document you will write this quarter.
• Use Definition of Done refinements to make platform hand-offs concrete.
• Cross-reference the topology with the SLO catalogue — every SLO should have exactly one owning team.
• Coach product managers to think in terms of stream-aligned outcomes, not shared components.
• Guard against reorg fatigue — small topology tweaks quarterly beat annual reorgs.

Common Mistakes

• Renaming existing teams into the four types without changing ownership or interactions — theatre, not change.
• Creating a platform team that ships a product no one wants to use — no adoption strategy.
• Turning every specialised area into a complicated-subsystem team and losing end-to-end ownership.
• Ignoring cognitive load and stacking capabilities onto one popular team until it burns out.
• Making interaction modes implicit — leaves teams unclear whether a request is collaboration or self-service.

Key Takeaways

• Team structure is a design decision, not an accident.
• Four team types and three interaction modes cover almost every real organisation.
• Cognitive load is the sizing rule that matters.
• Platform teams succeed only when their consumers self-serve happily.
• Small, evidence-based topology adjustments beat annual reorgs.

Related Concepts

Sits alongside Cross-Functional Team, Feature Team, DevOps and Service Level Objectives.