Team Topologies
Team structure is the foundation of software architecture. Get the team structure wrong and no amount of technical investment will produce the software system you want — because Conway's Law will shape the architecture whether you design it or not.
Team Topologies is a prescriptive organizational design framework from Matthew Skelton and Manuel Pais that gives engineering leaders a structured vocabulary and a repeatable process for structuring software teams. Built on four fundamental team types and three interaction modes, it replaces ad-hoc org design with deliberate, flow-optimized structures. By applying Conway's Law as a design tool rather than an obstacle, teams can eliminate hidden dependencies, reduce cognitive overload, and accelerate software delivery.
“We have about 120 engineers. There's a Platform team of 15 that handles infrastructure and CI/CD, a Data team of 20 that owns the data warehouse and…”
Stop fighting Conway's Law — design team structures that produce the architecture you want
Team Topologies rests on two foundational pillars: four fundamental team types and three core interaction modes. The four types are: Stream-aligned teams (the primary delivery unit, owning an end-to-end flow of business value from a domain segment), Platform teams (providing self-service internal products to reduce cognitive load on stream-aligned teams), Enabling teams (specialists who help stream-aligned teams overcome obstacles without creating permanent dependency), and Complicated-subsystem teams (handling deep-specialist domains such as ML pipelines or video codecs). Teams interact via exactly three modes: Collaboration (close joint work with shared ownership for a bounded discovery period), X-as-a-Service (clean API contract with minimal touch, for stable interfaces), and Facilitating (active coaching where one team helps another adopt new capabilities and then steps away). The framework explicitly measures cognitive load across three dimensions — intrinsic (domain complexity), extraneous (tooling and environment friction), and germane (learning investment) — and uses it to calibrate team size and scope. The 'Reverse Conway Maneuver' is the central design move: deliberately shape team boundaries to produce the desired software architecture, rather than letting accidental communication structures produce accidental systems. Topology patterns are dynamic: explicit sensing triggers signal when to shift interaction modes as products and teams mature. Each team publishes a Team API defining how it interfaces with others — code ownership, documentation, versioning, communication channels, and working agreements.
Most engineering organizations are designed by accident — teams form around people who happened to work together, inherit legacy ownership, and accumulate responsibilities until they are cognitively overloaded. The result is teams blocked by platform bottlenecks, stream-aligned work interrupted by shared-service queues, and Conway's Law silently encoding organizational dysfunction into the software architecture. Leaders sense something is wrong but lack a precise vocabulary to diagnose the topology or a framework to redesign it.
Stop diagnosing team problems with vague terms like 'communication breakdown' or 'ownership gaps' — apply the four team types and three interaction modes to produce a precise topology diagnosis, a concrete target design, and a sequenced migration path your organization can execute.
- A description of your current team structure — team names, sizes, and what each team owns
- Observable pain signals: delivery bottlenecks, teams that feel overloaded, unclear ownership boundaries, or excessive cross-team coordination
- Your target software architecture or system decomposition goals
- Organizational constraints: headcount limits, existing reporting lines, and technology stack context
- A current-state topology map classifying each team into one of the four types with anti-patterns flagged
- A cognitive load assessment per team, identifying which are overloaded and why
- A target topology design with specific team type assignments and interaction mode specifications for every significant team pair
- Team API templates for any team, defining its interface contract with the rest of the organization
- A phased topology evolution roadmap with sensing triggers for when to shift interaction modes
Watch the methodology work.
Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.
“Six product squads wait an average of 9 days for every infrastructure change because the Platform team runs a single request queue. The Data team lead is context-switching across four squad projects simultaneously and has missed two warehouse stability milestones. An engineering director suspects the solution is 'more platform engineers,' but can't explain why the current structure produces these outcomes — or what a better structure would look like.”
“The Platform team has published a self-service developer portal: squads provision environments, configure CI/CD pipelines, and manage deployments without filing tickets — the interaction mode is X-as-a-Service with a documented Team API. The Data team has separated its work: warehouse and ML infrastructure are protected as Complicated-subsystem work; a rotating Enabling cohort runs time-bounded analytics capability engagements with squads, then exits cleanly. The engineering director has a topology diagram and interaction mode matrix that grounds every resourcing and restructuring conversation in a shared framework.”
The same skill, where the work happens.
No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.
What it does, specifically.
Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.
Topology Assessment & Anti-Pattern Detection
Analyzes your current team structure against known Team Topologies anti-patterns: stream-aligned teams carrying platform responsibilities they shouldn't own, enabling teams that have become permanent bottlenecks, or platform teams operating as gating dependencies rather than self-service products. Surfaces the mismatch between your actual topology and the topology your software architecture requires.
Cognitive Load Audit
Assesses each team's aggregate cognitive load across three dimensions: intrinsic load (inherent domain complexity), extraneous load (tooling friction, process overhead, context-switching), and germane load (learning investment for capability growth). Identifies teams where total load exceeds sustainable capacity and recommends scope adjustments, enabling team interventions, or platform investments to reduce extraneous load.
Team Type Classification
Classifies each team in your organization into exactly one of the four Team Topologies types: Stream-aligned, Platform, Enabling, or Complicated-subsystem. For each classification, explains the appropriate behavioral expectations, size range, ownership model, and success metrics — and flags teams currently behaving outside their intended type.
Interaction Mode Design
Specifies the correct interaction mode for every significant team pair: Collaboration (joint work with shared ownership, time-bounded), X-as-a-Service (clean API contract, minimal interaction), or Facilitating (active coaching to transfer capability). Identifies pairs currently using the wrong mode and defines sensing triggers for when the current mode should transition.
Reverse Conway Mapping
Works backward from your desired software architecture to derive the team structure that will naturally produce it. Given a target system decomposition — desired service boundaries, domain ownership, API contracts — generates the team type assignments and interaction modes that cause Conway's Law to work in your favor rather than against you.
Team API Definition
Generates a Team API template for a specific team covering: owned code and services, documentation standards, versioning practices, supported communication channels, meeting availability, and working agreements — making the team's interface to the rest of the organization explicit and manageable.
Topology Evolution Roadmapping
Creates a phased migration plan from the current topology to the target state, specifying which changes to make first (low-risk wins versus structural shifts), what sensing mechanisms to install, and what observable triggers indicate readiness to shift interaction modes (e.g., move from Collaboration to X-as-a-Service once an interface has stabilized for two sprints).
Graded before it shipped.
Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.
Topology Diagnosis Map
A structured representation of your current team structure with each team classified by type, cognitive load level assessed (low/medium/high), and interaction mode labeled for every significant team pair. Anti-patterns are called out explicitly using Team Topologies terminology — not generic labels.
Target Topology Design
The recommended future-state team structure: team type assignments, scope adjustments, new team formations or splits required, and specified interaction modes for every team pair — with rationale grounded in cognitive load analysis and Conway's Law alignment.
Team API Document
A Team API template for any specific team covering code ownership boundaries, documentation location and standards, versioning practices, available communication channels, office hours, and working agreements — the interface contract that enables other teams to consume this team's output predictably.
Topology Evolution Roadmap
A phased migration plan from current to target topology: which structural changes happen in which order, what sensing mechanisms to put in place, and what triggers indicate when to shift interaction modes — for example, when a Collaboration engagement is complete and the teams should transition to X-as-a-Service.
Interaction Mode Matrix
A grid showing every significant team pair and their recommended interaction mode (Collaboration / X-as-a-Service / Facilitating), with rationale for each assignment, expected duration for time-bounded Collaboration engagements, and the transition trigger for when the mode should change.
Grounded in the original work.
Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.
Matthew Skelton & Manuel Pais
Matthew Skelton and Manuel Pais are the co-creators of the Team Topologies framework and co-founders of TeamTopologies.com, a consultancy and training organization. Their 2019 book 'Team Topologies: Organizing Business and Technology Teams for Fast Flow,' published by IT Revolution Press, has become a standard reference for engineering organization design and is applied by teams at enterprises and high-growth technology companies worldwide. Pais is also the DevOps Lead Editor at InfoQ.
Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press, 2019)
Co-founders of TeamTopologies.com; authors of the 2019 IT Revolution Press book adopted by engineering leaders across global enterprises; Pais is DevOps Lead Editor at InfoQ.
Be first to run it.
Team Topologies is being built right now. Leave your email and we’ll tell you the moment it goes live.