Team Topologies

What it is

Team Topologies (Matthew Skelton and Manuel Pais, 2019) is an organisational design model for software delivery organisations built around a single primary constraint: cognitive load. A team can only effectively own and operate software within its cognitive capacity; when it exceeds that capacity, quality degrades, throughput falls, and engineers burn out. The model defines four fundamental team types: stream-aligned teams (aligned to a flow of business work — the most common type, responsible for end-to-end delivery of a product, feature, or customer journey); platform teams (provide internal services that reduce cognitive load on stream-aligned teams by abstracting infrastructure, tooling, and common capabilities); enabling teams (help stream-aligned teams acquire new skills and overcome temporary capability gaps — coaching, not doing); and complicated-subsystem teams (own domains requiring deep specialist knowledge, such as real-time video encoding, financial risk models, or cryptographic key management).

The three interaction modes define how teams work together: collaboration (two teams work closely together for a period, typically to discover new approaches or solve a joint problem — high bandwidth, temporary); X-as-a-Service (one team consumes another's capability via a well-defined API with minimal interaction — the platform team's primary interaction mode with stream-aligned teams); and facilitating (an enabling team helps a stream-aligned team build capability, then steps back). Choosing the wrong interaction mode is a major source of organisational friction: a platform team operating in collaboration mode (answering every infrastructure question, pairing on Terraform) is acting as an enabling team and creating dependency rather than self-service autonomy.

Why it exists

Conway's Law (Mel Conway, 1967) states that organisations design systems that mirror their communication structures. A company with three silos (frontend, backend, ops) produces a three-tier architecture; a company with product squads produces modular services. Conway's Law is often cited as a constraint, but Team Topologies reframes it as a design lever: structure your teams the way you want your architecture to look. The inverse Conway manoeuvre (coined by Thoughtworks) is the deliberate practice of restructuring teams to drive a desired architecture — if you want loosely coupled microservices, create loosely coupled teams with clear APIs between them.

Traditional IT team structures (separate development, QA, and operations teams) create coordination overhead, handoff delays, and misaligned incentives. A development team that throws code "over the wall" to operations for deployment has no incentive to make it operable. The stream-aligned team model eliminates these handoffs by making one team responsible for the entire lifecycle (build, deploy, operate) of its product area, with platform teams providing the capabilities that make this feasible without requiring every team to be infrastructure experts.

When to use

• Apply Team Topologies thinking when re-designing team structures after significant organisational growth (crossing 50, 150, or 500 engineers are typical inflection points).
• Use the cognitive load framework to evaluate whether teams are correctly sized — teams that consistently miss commitments or have high defect rates may be overloaded by too broad a software ownership scope.
• Use the interaction mode framework to resolve chronic coordination problems — teams that are "always in meetings with each other" are likely using collaboration mode when X-as-a-Service would be more appropriate.
• Apply the inverse Conway manoeuvre when embarking on a modularisation or microservices migration — restructure teams before or alongside the technical architecture change to avoid the architecture reverting to monolith due to team coupling.
• Use enabling teams (temporarily structured, time-bounded) for organisation-wide capability uplift — Kubernetes adoption, cloud migration, security practices — rather than creating permanent specialist teams that product teams become dependent on.

When not to use

• Rigid application in small organisations: Below 30 engineers, Team Topologies team types add bureaucratic overhead without meaningful benefit — a single cross-functional team with product and platform responsibilities is appropriate; introduce explicit team type boundaries as the organisation grows.
• Re-org for its own sake: Team Topologies is a framework for thinking, not a mandate to reorganise; restructuring teams every 6 months creates instability and destroys team performance; use the framework to diagnose problems and make targeted interventions, not to redesign the org chart wholesale.
• Ignoring cognitive load measurement: Applying team types without measuring or understanding cognitive load is cargo-culting the framework; the framework's value is in making cognitive load the primary design criterion.

Typical architecture

Team Topology Example: 150-person Engineering Organisation
──────────────────────────────────────────────────────────
  Stream-Aligned Teams (product ownership)
  ├── Checkout Squad    (end-to-end checkout product)
  ├── Search Squad      (search + discovery experience)
  ├── Notifications Squad (email/push/SMS notifications)
  └── Payments Squad    (payment processing + reconciliation)
  
  Each squad: 4–8 engineers, owns: code + deploy + operate
  Cognitive load: product domain only (not infra/platform)

  Platform Team (X-as-a-Service interaction mode)
  ├── Provides: CI/CD templates, K8s self-service,
  │            Backstage portal, database CRDs, observability
  └── Interaction: async (portal, docs, Slack #platform)
                   NOT: pairing, ticket handling per-request

  Enabling Teams (temporary, facilitating mode)
  ├── Cloud Migration Team (6 months)
  │   └── Helps squads migrate from bare VMs to Kubernetes
  │   └── Exits when squads are self-sufficient
  └── SRE Enablement Team (ongoing, quarterly rotations)
      └── Embeds with a squad for 6 weeks to build SRE culture

  Complicated Subsystem Team (specialist X-as-a-Service)
  └── Payments Core Team
      └── Owns: PCI-DSS compliant payment processing engine
      └── Exposes: REST API to Payments Squad
      └── Interaction: X-as-a-Service (not collaboration)

Conway's Law alignment:
  Each squad → independently deployable service(s)
  Platform team → shared infrastructure (low coupling to squads)
  Subsystem team → isolated, contracted API boundary

Pros and cons

Implementation notes

Start a Team Topologies implementation with a cognitive load assessment: ask each team to map all the domains they own (services, codebases, on-call rotations, user-facing features) and score each domain's cognitive complexity on a 1–5 scale. Teams with total scores above ~20 are likely overloaded. Use this data to identify where to split teams (high-complexity domain areas that could form their own stream-aligned team) or where to add platform capability (repeated infrastructure work that could be absorbed by a platform team, reducing cognitive load on product teams). The assessment takes 2–3 hours per team and produces an immediate, actionable picture of organisational load distribution.

For the ops-to-platform team transition: traditional ops teams are structured as gatekeepers — they review and execute infrastructure changes on behalf of dev teams. Transitioning to a platform team requires a shift in both mindset (from gatekeeper to product manager) and capability (from manual infrastructure management to building self-service tooling). This transition takes 12–18 months for most organisations and should be planned explicitly. A practical path: start by identifying the 3 most common ops ticket types and building self-service solutions for them (reducing ticket volume by ~40%); this frees ops engineer time to invest in platform tooling; repeat until the platform team is self-service-first and ticket-handling is the exception, not the norm. Maintain a "sensing mechanism" throughout — regular check-ins with stream-aligned teams to detect when the platform team's X-as-a-Service interaction mode is insufficient and collaboration or facilitating is needed.

Common failure modes

• Platform team as ticketing service: Stream-aligned teams open tickets for every infrastructure request; platform team processes tickets reactively; no self-service; this is platform team operating in collaboration mode permanently; the platform team must build self-service tooling and document an explicit "we don't accept tickets for X" policy.
• Enabling team that never graduates: A Kubernetes enabling team embeds with squads for 6 weeks each; 18 months in, they are still embedding; squads have not gained self-sufficiency; the platform team's tooling is too complex for squads to use independently; the real fix is improving the platform, not extending the enabling team's engagement.
• Conway's Law ignored during microservices migration: Organisation migrates from monolith to microservices but keeps the same team structure (one backend team, one frontend team); new service boundaries map to technical layers, not business capabilities; teams must still coordinate for every feature; the architectural benefits of microservices are not realised.
• Complicated-subsystem team in collaboration mode: The payments core team is asked to collaborate with the payments squad on every feature; complex domain knowledge is not encapsulated behind an API; the subsystem team is a shared bottleneck rather than a self-contained service provider.
• Cognitive load not reassessed: Teams are correctly sized at 50 engineers; organisation grows to 150 engineers with the same team structure; teams are 3x their original scope; cognitive load is now critical but nobody has re-run the assessment; run cognitive load assessments annually or after major growth events.

Decision checklist

• Has a cognitive load assessment been run for each team in the last 12 months, with results used to inform team sizing and boundary decisions?
• Are stream-aligned teams structured around a flow of business work (product, customer journey) rather than a technical layer (frontend, backend, database)?
• Is the platform team interacting with stream-aligned teams primarily via X-as-a-Service (portal, docs, self-service tools) rather than ad-hoc collaboration?
• Are enabling teams explicitly time-bounded with clear graduation criteria (the stream-aligned team can perform the capability independently) rather than open-ended engagements?
• Does the team structure reflect the desired software architecture (inverse Conway manoeuvre), or does the org chart cut across service boundaries?
• Does the platform team have a sensing mechanism (regular office hours, survey, structured check-ins) to detect when X-as-a-Service is insufficient and collaboration or facilitating is needed?

Example use cases

• E-commerce scale-up restructure: 80-engineer startup with a feature team, a platform team, and a QA team; feature team is overloaded (checkout, search, promotions, account all in one team); cognitive load assessment shows critical overload; team is split into 3 stream-aligned squads (checkout, discovery, account); deployment frequency doubles within a quarter as squads own their own deployments end-to-end.
• Legacy ops-to-platform transition: Bank with 200 developers and 30 operations engineers; ops team processes 400 infrastructure tickets per month; platform engineering initiative over 18 months builds self-service Kubernetes deployment, database provisioning, and secret management; ops ticket volume drops 85%; ops team renamed to Platform Engineering; remaining 15% of tickets are for genuinely novel infrastructure work.
• Microservices via inverse Conway manoeuvre: Organisation decides to modularise a payment monolith; instead of starting with the technical split, they first create a Payments Core team (complicated-subsystem) and a Payments Product team (stream-aligned); team API boundary drives the service API boundary; monolith split completes 30% faster than previous similar initiatives that did not restructure teams first.

Related patterns

• Internal Developer Platform — the IDP is the product the platform team (in X-as-a-Service mode) delivers to stream-aligned teams.
• Paved Roads and Golden Paths — golden paths are the primary mechanism by which the platform team reduces cognitive load on stream-aligned teams.
• Platform Observability — DORA metrics measure the effectiveness of the stream-aligned team model at the organisational level.

Further reading

• Team Topologies Key Concepts — teamtopologies.com
• Conway's Law — Martin Fowler
• Demystifying Conway's Law — Thoughtworks