Team Topologies: The Four Team Types Every Org Past 300 Engineers Needs to Name

60-Second Summary

Team Topologies (Skelton & Pais, 2019) names four team types and three interaction modes. Every modern engineering org bigger than ~300 people uses this vocabulary.
Stream-aligned teams do the customer-facing work. Everything else exists to make them faster.
Platform teams treat internal services as products with internal customers — not a 'shared services pool'.
Enabling teams are time-bound coaching squads. They are not 'centres of excellence' in disguise.
Complicated-subsystem teams own work that requires deep specialisation (ML, compilers, payments rails) — keep them small.
Cognitive load is the unit of analysis. A team that owns more than it can hold in working memory will degrade no matter who you hire.

Once an engineering organisation passes roughly 300 people, the question 'how should our teams be organised?' stops having a single right answer and starts producing increasingly heated arguments. Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais, gave the industry a shared vocabulary to have those arguments productively. It is now the default reference at Spotify, the UK's GDS, ING, Adidas, Atlassian, and most large engineering orgs. This article is the gentle introduction for HR business partners, recruiters, and engineering leaders who keep hearing the terms in calibration meetings.

Why this model dominates

Previous org-design vocabularies — 'feature teams', 'component teams', 'centres of excellence', 'tribes and squads', 'matrixed delivery' — each captured part of the picture and contradicted each other in the rest. Team Topologies' contribution is twofold: it names team purpose orthogonally to team technology, and it makes cognitive load the central design constraint. The result is a model that survives contact with both software and the humans building it.

Conway's Law and cognitive load

“Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.”
— Melvin Conway, 1968

Conway's Law is the foundational empirical observation: the shape of your software ends up mirroring the shape of your org. Skelton and Pais's 'reverse Conway manoeuvre' makes the implication explicit — if you want a particular software architecture, design the org first.

What 'cognitive load' means here

From cognitive science (John Sweller, 1988), cognitive load is the total mental effort a person — or team — can hold at once. A team that owns 12 services, 4 customer journeys, 3 incident rotations, and 2 partner integrations exceeds team-level cognitive load. No amount of hiring fixes this — only descoping does.

The four team types

The four Team Topologies team types

Type	Purpose	Outputs	Typical size	Example
Stream-aligned	Owns a continuous flow of work for a customer-facing or business stream end-to-end	Shipped features, customer outcomes	5–9 (one 'two-pizza team')	Checkout team, Onboarding team, Recommendations team
Platform	Provides internal products that accelerate stream-aligned teams	Self-service capabilities (CI/CD, observability, auth)	5–15 grouped into a platform 'grouping'	Developer platform, Data platform, Identity platform
Enabling	Helps stream-aligned teams adopt new capabilities; time-bound	Coaching, documentation, internal training	3–6	SRE enablement squad, Accessibility enablement squad
Complicated-subsystem	Owns a subsystem that requires deep specialist knowledge	A reliable, well-documented component	3–8 specialists	Real-time pricing engine, ML ranking model, cryptography library

The numbers above are not arbitrary. They come from Robin Dunbar's research on group size and trust (Dunbar, 1992) and the substantial body of work on the relationship between team size and software defect rate. Past ~9 engineers, communication overhead grows faster than throughput; past ~15, the team is functionally two teams pretending to be one.

The three interaction modes

How teams should talk to each other

1
Collaboration
High-bandwidth, short-duration joint work. Usually 1–3 months. Used when both teams have something to learn from each other (e.g. a stream-aligned team and a complicated-subsystem team co-designing an integration).
2
X-as-a-Service (XaaS)
One team consumes another's product like an API. Low-bandwidth, durable. The platform team's default mode. The promise: the consuming team needs to read docs, not book a meeting.
3
Facilitating
An enabling team coaches a stream-aligned team to adopt a new practice. Time-bound. The point is to leave the stream-aligned team self-sufficient, not dependent.

The wrong mode is a tax on everyone

A platform team stuck in Collaboration mode with every customer is overwhelmed. An enabling team that drifts into permanent Collaboration becomes a 'centre of excellence' that produces nothing and blocks decisions. Naming the mode explicitly is half the value of the model.

Applying it: a worked example

Imagine a 250-engineer SaaS company with a single product. The org chart says 'engineering' has 6 teams: Checkout, Onboarding, API, Data, Platform, SRE. After a Team Topologies pass:

Checkout, Onboarding — stream-aligned. Own end-to-end customer journeys.
API — split. The customer-facing public API moves to a new stream-aligned 'Developer Experience' team. The internal RPC framework becomes part of the platform.
Data — split. Customer-facing data products (dashboards) become stream-aligned. The data warehouse, pipelines, and tooling become a Data Platform team.
Platform — kept, with a sharpened mandate as platform-as-product. A product manager is added.
SRE — re-cast as an enabling team. It no longer carries the pager for product teams; it coaches them to. The pager moves to stream-aligned teams.
A new complicated-subsystem team is named around the ML personalisation models, which had been a side-of-desk project for three different teams.

The total headcount doesn't change. The cognitive load per team drops. The arguments about 'who owns this' drop with it.

Platform-as-product done well

Named PM and design partner for the platform.
Internal customers can opt out. If they can't, you have a tax, not a platform.
Adoption metric (e.g. % of services using the auth platform) tracked weekly.
Quarterly roadmap published and reviewed with stream-aligned teams.
A 'paved road' framing: the platform isn't the only option, but it's the easiest by a wide margin.

Anti-patterns

'Shared services' team that owns everything no one else wants. Always over-loaded, always under-staffed.
Two stream-aligned teams owning the same code path. Conway's Law guarantees an integration mess.
Enabling team that never leaves. Becomes a permanent dependency.
Platform team without a PM. Builds the wrong things efficiently.
Complicated-subsystem team that grows to 12 people. It is now two teams hiding the seam.
Renaming existing teams with new labels without changing scope, interactions, or pager rota. Lipstick on the chart.

Implications for HR

Career paths differ by team type. A senior engineer in a complicated-subsystem team is rarely interchangeable with one in stream-aligned. Calibrate accordingly.
Hiring profiles differ. Platform teams need engineers with product instincts; stream-aligned teams need engineers comfortable with ambiguity; complicated-subsystem teams need depth.
Manager span of control differs (see the dedicated span-of-control article). Platform team EMs typically support fewer reports because of higher cross-team coordination load.
Burnout patterns differ. Stream-aligned: deadline pressure. Platform: support-load creep. SRE/enabling: pager fatigue. Diagnose accordingly.

Monday-morning checklist

Label every team in your org with one of the four types. Disagreements are the data.
For each team, name its interaction mode with its top 3 partners.
Identify any team with >9 engineers or >15 service ownerships. Plan the split.
Confirm every platform team has a PM and a roadmap.
Identify enabling teams older than 12 months that have not graduated their customers. Audit them.

FAQ

Frequently asked questions

We're 40 engineers. Is this too early for us?

Use the vocabulary, skip the full restructuring. At 40 you probably have 4 stream-aligned teams and a nascent platform forming organically. Name them so the next 80 hires fit a frame.

Is Team Topologies just Spotify squads/tribes/chapters?

No. Spotify's model is one specific instantiation. Team Topologies is a more general framework and explicitly critiques several aspects of the Spotify model that didn't scale (see the dedicated Spotify article).

How does this relate to DDD bounded contexts?

Closely. Stream-aligned teams typically own one or more bounded contexts. The reverse Conway manoeuvre is often used to align team boundaries with domain boundaries.

Where do managers fit?

Managers are not a team type. Each team has a leader (EM, TL, or both). Manager hierarchies follow the team graph; they do not define it.

References

Skelton & Pais — Team Topologies (IT Revolution, 2019) — Team Topologies
Conway, M. — How Do Committees Invent? (1968) — Datamation
Sweller, J. — Cognitive Load During Problem Solving (1988) — Cognitive Science
Dunbar, R. — Neocortex size and group size in primates (1992) — Journal of Human Evolution

Written by Pawan Joshi.Sources cited inline.

First published 15 Jun 2026See site changelog →