Matthew Skelton and Manuel Pais's 2019 book Team Topologies has become the lingua franca for organising modern software organisations. Platform engineering picked it up because it gives a precise vocabulary for what platform teams do and — equally important — what they don't do.
Conway's Law, Restated
Conway (1968): Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure. Modern teams use this in reverse — design the team boundaries you want, and the architecture follows. Team Topologies is a toolkit for that deliberate design.
The Four Team Types
1. Stream-Aligned Teams
The default. A team owning a single value stream — a product, a customer journey, a domain. End-to-end responsibility: discovery, development, deployment, operation, support. Should be at least 70% of all engineering teams in a healthy organisation.
- Examples: "Checkout team", "Search team", "Mobile app team"
- Optimised for fast flow of change
- Cognitive load is the headline constraint
2. Platform Teams
Build and operate an internal product (the IDP) that stream-aligned teams consume. Their customers are other engineers inside the same company. They have product managers, a roadmap, a backlog, and adoption KPIs.
- Goal: reduce cognitive load on stream-aligned teams by abstracting infrastructure concerns
- Examples: "Kubernetes platform team", "CI/CD platform team", "Observability team"
- Use X-as-a-service interaction mode (see below) with their consumers
3. Enabling Teams
Time-limited engagement: help stream-aligned teams acquire new capabilities. Pair, teach, document, then withdraw. Often confused with platform teams — the distinction is that enabling teams do not own a long-running product.
- Examples: "Performance engineering team", "Security champions", "Cloud migration tiger team"
- Think internal consultants with a sunset clause
- Critical for capability uplift but not a permanent operating function
4. Complicated-Subsystem Teams
Own a component requiring specialist deep knowledge — e.g., a video codec, a recommendation algorithm, a payment-routing engine. Exists because the alternative (making every stream-aligned team a codec expert) would be absurd.
- Examples: "Search ranking team", "Cryptography team", "Real-time bidding team"
- Boundary defined by the bounded specialist knowledge
- Rare; should be the exception, not the rule
The Three Interaction Modes
| Mode | What it looks like | When |
|---|---|---|
| Collaboration | High-bandwidth, shared work, ad-hoc | Discovery, early build, uncertain requirements |
| X-as-a-Service | One team consumes the other's product with clear interface | Mature platform, stable contract |
| Facilitating | One team helps the other learn or unblock | Capability gap, mentoring, enabling work |
The healthy default for a platform team is X-as-a-Service: their work is consumed via documented APIs / portals, not via Slack pings. Drift towards collaboration is a smell — it means the interface is too painful and consumers are routing around it.
What This Means for Platform Teams
- Have an internal product manager. The platform is a product; treat the roadmap, discovery, and feedback like one.
- Be explicit about who your customer is. Usually stream-aligned teams; sometimes other platform teams.
- Have clear consumption interfaces. Templates, APIs, portals — not "ask in #platform-help."
- Don't try to own everything. Most teams don't need a platform for everything; ruthlessly scope.
- Make adoption voluntary if possible. Mandated platforms get worked around; chosen platforms get loved.
The Cognitive Load Question
Team Topologies defines three types of cognitive load:
- Intrinsic: the inherent difficulty of the problem domain. Can't be reduced — choose the right people.
- Extraneous: incidental complexity — yak-shaving, tooling friction, environment setup. The platform team's job to eliminate.
- Germane: the learning required to do the work well. The good kind — invest here.
A platform that genuinely reduces extraneous load lets product engineers focus on intrinsic and germane work. A platform that adds its own learning curve without removing more elsewhere has failed.
Anti-Patterns to Avoid
- Component teams — teams aligned to architectural layers (frontend / backend / database) rather than value streams. Slow flow because every change touches multiple teams.
- "Platform" team that is really ticket-handling ops — same humans, new badge.
- Platform team that builds without consulting consumers — beautiful product, zero adoption.
- Permanent enabling teams — if the team is not winding down, it's now a platform or complicated-subsystem team. Reclassify honestly.
Sizing
Team Topologies recommends teams sized to fit a "team API" mental model — Dunbar's limits apply. A useful starting point:
- 5-9 engineers per team (the "two-pizza" rule generalised)
- A platform serving 100+ developers needs at least 4-6 platform engineers, often split across capability areas (CI/CD, runtime, observability)
- 1 platform engineer per ~15-25 developers is a rough industry benchmark, varying with platform scope
Where to Read Further
Skelton & Pais's book remains the canonical reference. The teamtopologies.com site has free templates for team-interaction maps. The CNCF CNPA exam tests these concepts directly.