Post

Team Topologies for Platform Teams

Team Topologies is not an org chart pattern — it is a cognitive load management strategy with architecture as a side effect. Design teams to produce the architecture you want, not the other way around.

Posted
By
23 min read
Team Topologies for Platform Teams

Team Topologies is not an org chart pattern — it is a cognitive load management strategy with architecture as a side effect. Design your teams to produce the architecture you want, not the other way around, and the target for any platform team is ruthlessly clear: reduce extraneous load on stream-aligned teams until X-as-a-Service becomes the default interaction.

Key Properties

Property Value
Authors Matthew Skelton & Manuel Pais
Original edition 2019 (IT Revolution); 2nd ed. 2025
Core optimisation target Fast flow of value
Central concept Cognitive load
Theoretical foundation Inverse Conway Manoeuvre
Team types 4 (stream-aligned, platform, enabling, complicated-subsystem)
Interaction modes 3 (X-as-a-Service, Collaboration, Facilitating)
Ideal team size 5–9 (Dunbar’s number, first band)
Anti-types catalogue devopstopologies.com

When to Use / Avoid

Use When

  • You have 5+ stream-aligned teams working in parallel and delivery friction is rising — Team Topologies gives you a vocabulary and a design principle, not just a chart.
  • You’re sizing a platform team and need to decide what interactions to standardise vs. what to leave as collaboration — the framework is prescriptive about trajectory.
  • You suspect your platform is still too ticket-driven and you want a principled argument for moving to self-service — X-as-a-Service is the goal state, and the model tells you exactly why.
  • You’re designing an enabling team and need to define their scope and exit criteria — the framework is explicit that enabling teams have a temporary mandate.
  • You’re breaking up a monolithic “DevOps team” that has become a silo — the anti-types catalogue names exactly that failure mode.

Avoid When

  • Your engineering org is under ~30 people — at that scale, Conway’s Law doesn’t apply with enough force to justify the overhead of named team types. Just ship.
  • You’re in a post-acquisition integration where org design is being driven by headcount negotiation, not architecture. Topologies require stable team boundaries; M&A contexts don’t have them yet.
  • Heavily regulated environments (finance, pharma, defence) where compliance mandates specific separation of duties that Team Topologies would disallow — the framework assumes autonomy that compliance architecture may structurally prevent.
  • You want to use “Team Topologies” as the justification for creating a new silo. It’s frequently misread this way. The goal is fast flow, not clean org boxes.

The Framework in Brief: Conway’s Law Inverted

Conway’s Law (Melvin Conway, 1967) states that organisations design systems that mirror their own communication structure. Most orgs treat this as a constraint they work around. Team Topologies turns it into a design tool: deliberately structure your teams to produce the architecture you want, rather than letting the architecture emerge from whatever org you happened to build.

This is the Inverse Conway Manoeuvre — reorg first, then the architecture follows. The goal is always fast flow: reducing the time from idea to working software in production without accumulating technical debt or burning out the people doing it.

graph LR
    A[Team Structure] -->|produces| B[System Architecture]
    C[Conway's Law] -->|observed| A
    D[Inverse Conway Manoeuvre] -->|deliberately designs| A
    D -->|to achieve| E[Fast Flow]
    E -->|means| F[Reduced Cognitive Load]

The mechanism through which Conway’s Law operates is cognitive load. Teams that own too much, or whose boundaries don’t match the architecture, carry too much mental overhead. That overhead is the enemy of flow.

Source: Martin Fowler bliki — Team Topologies — Fowler’s summary frames Team Topologies as “a book-length treatment of the Inverse Conway Maneuver”

Cognitive Load: The Central Design Variable

John Sweller’s cognitive load theory divides mental effort into three types. Team Topologies maps them directly onto the platform problem:

Type Definition Platform engineering relevance
Intrinsic Inherent complexity of the domain problem The checkout flow has intrinsic complexity — the team must carry this
Extraneous Incidental complexity from tools, processes, environment Kubernetes cluster management, CI pipeline debugging, secret rotation — none of this is the team’s core job
Germane Productive cognitive effort — learning, pattern formation, improvement This is where value is created; it needs mental space

The platform team’s job is to reduce extraneous cognitive load on stream-aligned teams. Every capability the platform abstracts — CI/CD pipelines, observability setup, secret management, environment provisioning — is cognitive load that stream-aligned teams no longer carry. That freed capacity shifts toward germane load: actually solving the business problem.

graph TD
    T[Total Cognitive Capacity]
    T --> I[Intrinsic — domain complexity]
    T --> E[Extraneous — tooling, infra, process]
    T --> G[Germane — learning, improvement]
    P[Platform] -->|absorbs| E
    E -->|shrinks| E
    G -->|grows| G
    style E fill:#f9a,stroke:#c33
    style G fill:#afa,stroke:#363
    style P fill:#adf,stroke:#36c

This framing produces a different design criterion than “standardisation” or “cost reduction.” A platform optimised for cognitive load reduction looks different from one optimised for compliance. It has golden paths that are genuinely faster than the alternative, not just mandatory. It surfaces errors at the right level. It doesn’t require stream-aligned teams to learn its internals to use it.

Crucially: team cognitive load is also bounded by team size. Dunbar’s first band (~5 close relationships, practical working ceiling ~9) is the cognitive limit for a stable high-trust team. Beyond 9, coordination overhead rises faster than throughput. Team Topologies advocates strongly for 5–9 person teams, with scope reduced rather than team size increased when load is too high.

Source: IT Revolution — Team Cognitive Load — establishes the three-type decomposition and its application to platform design

The Four Team Types

The four types are not roles or job titles — they are organisational patterns, each optimised for a specific kind of work and a specific cognitive load profile.

graph TD
    SA[Stream-Aligned Team]
    P[Platform Team]
    E[Enabling Team]
    CS[Complicated-Subsystem Team]

    SA -->|consumes capabilities| P
    E -->|coaches, then exits| SA
    CS -->|provides specialist component| SA
    CS -->|may feed into| P

Stream-Aligned (the default)

A stream-aligned team owns a single, valuable flow of work end-to-end — from discovery through design, build, test, deploy, and operate. “Stream” means a continuous flow aligned to a business domain, a product, a user journey, or a persona. Most teams in an organisation should be stream-aligned.

Key properties:

  • Full ownership from commit to production. No handoffs over the wall.
  • Bounded to a cognitive-load-appropriate scope — if the scope is too large, split along a fracture plane.
  • Runs the service in production (“you build it, you run it”).
  • Interacts with the platform primarily via X-as-a-Service.

Stream-aligned is the default mode. Platform, enabling, and complicated-subsystem teams exist to serve stream-aligned teams — not the other way around.

Platform (internal product team)

A platform team builds and operates the internal product that reduces extraneous cognitive load on stream-aligned teams. The platform is consumed primarily via X-as-a-Service: self-service, with clear APIs, documentation, and golden paths.

In the context of modern platform engineering, a platform team IS the Team Topologies “platform” type — but with one critical addition: Product Manager discipline. Without a PM mindset, a platform team drifts toward being an internal tooling team that ships whatever is easiest to build, not what stream-aligned teams actually need. See Platform as a Product for the full treatment.

Key properties:

  • Self-service is the default interaction mode.
  • Measured by adoption and developer experience, not tickets closed.
  • Has a product roadmap, user research, and SLOs for its own capabilities.
  • Does not make deployment decisions for stream-aligned teams — it builds the rails, not the trains.

In larger organisations, there will be multiple platform teams — one for CI/CD, one for cloud infrastructure, one for security tooling, one for observability. The risk here is a platform-of-platforms problem: stream-aligned teams now have to navigate between N platforms with different APIs, different support models, different golden paths. This is a real coordination failure. The mitigation is a single unified developer portal (Internal Developer Platforms) that presents a coherent interface, and explicit ownership of the integration points between platform teams.

Enabling (time-boxed coaches)

An enabling team is composed of specialists who help stream-aligned teams acquire new capabilities and then leave. They do not write standards that other teams must follow. They do not own components. They pair, teach, review, and move on.

An enabling team is the answer to “we need stream-aligned teams to adopt Kubernetes, but they don’t have the skills yet.” The enabling team builds the knowledge transfer programme, works alongside the stream-aligned teams during the ramp-up, then hands over and moves to the next capability gap.

Key properties:

  • Mandate is explicitly time-bounded — typically 1–3 quarters per capability.
  • Success criterion: the stream-aligned team can operate independently afterward.
  • Roughly maps to what enterprises call a CCoE (Cloud Centre of Excellence) — but a CCoE that persists indefinitely and creates mandates has become an enabling team anti-type.
  • In platform contexts, enabling teams help stream-aligned teams adopt the platform. They are the human layer on top of the golden path.

Complicated-Subsystem (deep specialists)

A complicated-subsystem team exists when a component requires deep specialist knowledge that would overwhelm a stream-aligned team. ML inference engines, video codecs, payment fraud models, high-frequency trading engines, advanced cryptographic protocols — the kind of work where most engineers can use the output but few can build and maintain the internals.

Key properties:

  • Justified only when the subsystem is genuinely hard — not just complex legacy code.
  • Reduces cognitive load on stream-aligned teams by providing the component as a consumed capability.
  • Often feeds into the platform: a security team that builds zero-trust PKI infrastructure, or an ML platform team that provides model serving capabilities. When the complicated subsystem is platform-facing, it becomes a specialist feeder into the broader IDP.
  • Small team — often 3–6 people. If it’s larger, the subsystem boundaries are probably too wide.

The Three Interaction Modes

How teams interact is as important as what type they are. Team Topologies defines exactly three legitimate interaction modes. Every team pairing should be in exactly one mode at any given time.

sequenceDiagram
    participant SA as Stream-Aligned Team
    participant P as Platform Team
    participant E as Enabling Team

    Note over SA,P: Collaboration mode (time-boxed)
    SA->>P: Joint discovery — what should the API look like?
    P->>SA: Deep exploration, shared codebase

    Note over SA,E: Facilitating mode
    E->>SA: Pairing, training, knowledge transfer
    SA-->>E: Team now self-sufficient

    Note over SA,P: X-as-a-Service (steady state)
    SA->>P: Self-serve: provision DB, get secret, deploy service
    P-->>SA: Automated, documented, no ticket required

X-as-a-Service: the target

X-as-a-Service is the interaction mode where one team provides and another team consumes a capability with minimal ongoing coupling. The consumer does not need to understand the internals. Documentation and golden paths are sufficient. No ticket required, no synchronous coordination.

This is the mature steady state. A platform team that has shipped a CI/CD golden path should be in X-as-a-Service with stream-aligned teams using it. The stream-aligned team runs platform-cli deploy and their service is deployed. They do not need to know how ArgoCD is configured.

Collaboration: time-boxed joint discovery

Collaboration is the mode for discovering what should be built — when neither team knows enough yet to define the API or the golden path. Two teams work together intensively, sharing code, sharing context, building toward an interface that will eventually become X-as-a-Service.

Collaboration is expensive: it requires high bandwidth, dedicated time from both teams, and generates coupling. It is correct for a defined period — typically 1–2 quarters — and should end with a clear handoff.

A platform team perpetually stuck in Collaboration is doing consulting. This is one of the clearest anti-patterns the framework identifies. It means either the platform’s APIs are not mature enough for self-service, or the stream-aligned teams don’t have enough knowledge to use them, or both. The platform team should recognise this as a signal, not a feature.

Facilitating: temporary pairing during capability transfer

Facilitating is the mode for knowledge transfer — when a team has expertise that another team needs. An enabling team operates primarily in Facilitating mode. A platform team can temporarily enter Facilitating mode when onboarding a stream-aligned team to a new capability.

Facilitating should not be confused with Collaboration. In Facilitating, one team is teaching and coaching; in Collaboration, both teams are building jointly. Facilitating ends when the knowledge has transferred. Collaboration ends when the interface is clear.

The Trajectory Rule

The most operationally important thing in the framework is the directional arrow:

graph LR
    C[Collaboration] -->|shared discovery| F[Facilitating]
    F[Facilitating] -->|knowledge transfer| X[X-as-a-Service]
    X -->|steady state| X

    style C fill:#ffd,stroke:#996
    style F fill:#dfd,stroke:#696
    style X fill:#ddf,stroke:#669

Collaboration → Facilitating → X-as-a-Service is the expected lifecycle for any capability. A new capability starts in Collaboration (neither team has enough context). Once the API is clearer, it moves to Facilitating (platform helps stream-aligned teams adopt it). Once adoption is established, it becomes X-as-a-Service (fully self-serve).

Teams should consciously review which mode they’re in and push toward X-as-a-Service. Staying in Collaboration because “it feels productive” is a path to mutual dependency. Staying in Facilitating because “teams still have questions” is a path to the platform team becoming an unofficial support desk.

Regressions happen: a new service type requires temporary Collaboration; a major platform migration requires a Facilitating wave. These are expected. What is not acceptable is a platform team with no capabilities in X-as-a-Service mode after two years of operation.

How This Maps to Platform Engineering Specifically

Team Topologies was written before “platform engineering” became an industry category, but the mapping is almost 1:1. The framework provides the org design theory; platform engineering provides the technical implementation.

Team Topologies concept Platform engineering equivalent
Platform team The IDP engineering team with PM discipline
Stream-aligned team Product teams consuming the IDP
Enabling team CCoE, internal platform advocacy, onboarding squad
Complicated-subsystem team Security platform, ML serving, data platform embedded within broader IDP
X-as-a-Service Golden paths, self-service portal, platform CLI
Collaboration Joint design of new platform capabilities with pilot teams
Facilitating Platform office hours, onboarding programmes, embedded platform engineers
Cognitive load reduction The primary metric: have we reduced developer friction?
Inverse Conway Manoeuvre Designing platform boundaries to match the architecture you want teams to produce

The critical addition that platform engineering makes to the Team Topologies model is Platform-as-a-Product: the operational discipline that turns a platform team from an infrastructure team with opinions into an internal product organisation with customers, a PM, a roadmap, and adoption metrics. Without this, a platform team following Team Topologies still drifts toward being a ticket-driven shared service. See Platform as a Product.

Multiple Platform Teams at Scale

Organisations with 100+ engineers typically have more than one platform team — a cloud infra team, a security platform team, an observability platform team, a developer experience team. This is expected and correct. The risk is platform fragmentation: stream-aligned teams now face multiple platforms with different APIs, different support channels, different golden paths.

The mitigation requires three things:

  1. A unified developer portal (Backstage or equivalent) presenting a single front door — even if behind it are five platform teams. See Internal Developer Platforms.
  2. Explicit platform team charters so their scopes don’t overlap and their APIs compose cleanly.
  3. A platform product council or equivalent coordination mechanism to sequence capabilities across teams and prevent duplicate golden paths.

Conway’s Law applies here too: if your platform teams don’t coordinate, your platform will have seams that stream-aligned teams will feel.

Anti-Types: What Goes Wrong

The DevOps Topologies catalogue — Skelton & Pais’s pre-book work — catalogues the anti-patterns. The most common ones in platform engineering contexts:

Anti-type What it looks like Why it fails
Dev-and-Ops Silos (Type A) Separate Dev and Ops departments; “throw it over the wall” deployments Story points claimed as DONE at feature-complete; operability ignored because Devs have no prod context
DevOps Team Silo (Type B) Manager creates a “DevOps team” that quickly becomes a new silo defending its tools Creates a third silo between Dev and Ops; neither Dev nor Ops improves
Embedded Ops Done Wrong (Type F) Ops engineers embedded into delivery teams without time, skills, or support to do platform work Ops people burn out; platform concerns ignored; no self-service emerges
Platform as Shared Service Platform team treated as internal IT: receives tickets, prioritises internally, reports on throughput No developer experience focus; backlogs grow; stream-aligned teams work around the platform
Perpetual Collaboration Platform team always in joint delivery with stream-aligned teams Platform team becomes consulting firm; no leverage; doesn’t scale
Enabling Team that Never Exits CCoE or enabling team writes mandates and standards, stays permanently Becomes a standards police; reduces stream-aligned team autonomy; teaches nothing

The DevOps Team Silo is particularly common: leadership observes that “DevOps is working elsewhere” and creates a DevOps team. That team immediately attracts all infrastructure and deployment work, grows into a bottleneck, and makes Dev and Ops farther apart than before. The correct interpretation of “adopt DevOps” is never “create a DevOps team.”

Source: DevOps Topologies — Anti-Types — the original catalogue by Skelton & Pais

Practical Adoption: Where to Start

Teams reaching for Team Topologies typically have a specific problem: stream-aligned teams are slow, or the platform team is a bottleneck, or org design is becoming architecture. Here is the practical sequence:

1. Identify stream boundaries first. Before touching the platform team, map your streams. A stream is a continuous flow of value aligned to a business domain. Use bounded contexts (DDD) as the primary fracture plane, refined by: user persona, regulatory boundary, deployment cadence, tech stack, or geographic region. Don’t design the platform until you know who will be consuming it.

2. Write Team API documents. A Team API is a lightweight contract describing how to interact with a team: what capabilities it provides, how to request changes, its SLAs, its decision authority, its communication channels. This makes implicit coupling explicit and is the foundation for managing interaction modes consciously.

3. Assess current cognitive load. Before moving to X-as-a-Service, measure what teams are actually spending time on. The Team Cognitive Load Assessment is a simple survey template. If stream-aligned teams report high extraneous load on infrastructure and tooling, that is the platform team’s first backlog.

4. Map current interaction modes. For each team-to-team pairing, identify which mode you’re actually in vs. which mode you should be in. Most organisations discover they have too many Collaboration pairings that should have graduated to X-as-a-Service years ago.

5. Define enabling team scope and exit criteria. If you have a CCoE or internal consulting group, write down what they’re transferring, to whom, and when they’ll be done. Enabling teams without exit criteria become permanent fixtures.

6. Move one capability to X-as-a-Service as a proof of concept. Don’t reorganise the whole org. Pick the most-requested platform capability, productise it fully (documentation, golden path, SLO, monitoring), and move to X-as-a-Service with one pilot stream-aligned team. Measure cognitive load before and after.

How Real Systems Use This

ING Netherlands — agile transformation with Team Topologies

ING’s digital transformation is one of the best-documented Team Topologies implementations at scale. Starting with a traditional Dutch bank org structure, they reorganised around stream-aligned “squads” owning specific customer journeys (mortgages, payments, app onboarding), a platform tribe providing shared banking infrastructure (authentication, notification services, core banking APIs), and enabling teams operating at two levels — one for engineering practices (CI/CD, testing, observability) and one for product management practices.

The results were concrete: delivery cadence went from 5–6 major releases per year to new features every 2–3 weeks. 60,000+ employees aligned to strategic outcomes rather than departmental outputs. Employee engagement scores increased measurably. The platform tribe explicitly applied the Platform-as-a-Product model — the platform had a PM, user research cycles, and adoption metrics as first-class concerns rather than SLA tickets. The enabling teams had explicit 3-quarter engagement windows with each squad, then rotated.

What made it work: ING didn’t just rename teams. They rewired the decision authority — stream-aligned squads had genuine product ownership, including production. The platform tribe had to earn adoption through quality, not mandate it through policy.

Source: Team Topologies — ING 2nd Edition Case Study

Spotify — squads as stream-aligned teams

Spotify’s squad/tribe/chapter/guild model (Kniberg & Ivarsson, 2012) predates Team Topologies vocabulary but maps cleanly onto it. Squads are stream-aligned teams: autonomous, cross-functional, owning a specific product area end-to-end. Tribes are groupings of squads in adjacent domains (~100 people — Dunbar’s third band). Chapters are the skills communities that span squads within a tribe (the horizontal functional layer).

Spotify’s platform teams — the infrastructure teams providing the internal service mesh, the A/B testing platform, the media delivery platform — operate in X-as-a-Service mode. Squads don’t file tickets to get an experiment running; they use the self-service experimentation platform. The enabling function exists in chapters and guilds: senior engineers share practices horizontally without creating a mandating authority.

The Spotify model is frequently misread as “just copy the names.” The reason it worked at Spotify was the cognitive load management underneath it — squads were sized to ~8 people with scope bounded by what they could own without infrastructure overhead, specifically because Spotify invested heavily in platforms that absorbed that overhead.

Netflix — full-cycle developers on a paved road

Netflix’s “full-cycle developer” model is the most aggressive form of stream-aligned team ownership. Engineers on a full-cycle team design, build, deploy, operate, and on-call for their services — everything. This is theoretically overwhelming cognitive load. The reason it works is Paved Road: Netflix’s platform provides CI/CD (Spinnaker), container orchestration (Titus), metrics (Atlas), tracing, feature flags, and dozens of paved-road services that teams consume without understanding their internals.

The team topology here: full-cycle stream-aligned teams at the top; a large platform organisation (hundreds of engineers) in X-as-a-Service mode providing the paved road; enabling work done through internal training (Netflix University), architecture review, and embedded senior engineers who rotate into product teams during major capability adoptions.

The lesson: maximum stream-aligned team autonomy requires maximum platform investment. You cannot do “full-cycle developers” without first doing “serious platform engineering.”

Source: Netflix Tech Blog — Full Cycle Developers at Netflix

CCoE as Enabling Team — the cloud migration pattern

Every large enterprise going through a cloud migration encounters the same pattern: a Cloud Centre of Excellence is created to set standards and help teams adopt cloud-native patterns. In Team Topologies terms, a CCoE should be an enabling team — specialist, time-bounded, coaching-focused, with no mandate authority.

The pattern breaks down when the CCoE:

  • Writes policies that teams must follow (becomes a compliance team, not an enabling team)
  • Reviews every team’s cloud architecture (becomes a bottleneck, not a coach)
  • Persists indefinitely without rotating its focus (becomes an institution, not a transfer mechanism)

A CCoE that follows enabling team principles: defines the IaC patterns, pairs with 2–3 stream-aligned teams during their first 3 months on cloud, hands off the Terraform modules and runbooks, and then moves to the next capability gap (FinOps, security hardening, DR patterns). Within 18 months, every team has the patterns. The CCoE then either dissolves into the platform team or pivots to the next domain (AI/ML tooling, observability uplift).

The $1.1B Digital Retailer — fracture plane analysis in practice

This anonymised case study from the Team Topologies community is the most instructive example of applying fracture plane analysis. A large digital retailer had five “feature squads” that each owned a slice of the tech stack (frontend squad, backend squad, data squad, infra squad, QA squad) rather than a slice of the business domain. Every feature required coordination across all five squads. Lead time was weeks.

The restructuring: identify the natural domain boundaries in the business (checkout, product catalogue, search, customer identity, recommendations). Reorganise into five stream-aligned teams aligned to those domains, each cross-functional (their own frontend, backend, data, QA). Create a platform team responsible for CI/CD, shared observability, and auth infrastructure. Create a complicated-subsystem team for the ML recommendation engine. Create a 6-month enabling team to transfer platform adoption.

Result: lead time dropped from weeks to days within two quarters. Team cognitive load assessments showed extraneous load decreasing as the platform matured. The recommendation engine team — now a proper complicated-subsystem team — could iterate on the model without coordinating with product teams on deployment mechanics.

References

Software Architecture, Platform Engineering
team-building
This post is licensed under CC BY 4.0 by the author.