Team Topologies Diagram: Visualizing Stream-Aligned, Platform & Enabling Teams (2026)
How to create Team Topologies diagrams showing the four team types and three interaction modes. Covers current-state mapping, future-state design, Conway's Law, and Team Topologies + DDD — with AI prompt templates.
R
Ryan·Senior AI Engineer
Team Topologies is an organizational design framework by Matthew Skelton and Manuel Pais that defines four fundamental team types and three interaction modes for structuring software engineering organizations to achieve fast flow. A Team Topologies diagram visualizes how teams are structured, what they are responsible for, and how they interact — making Conway's Law (the system architecture mirrors the communication structure of the organization) a deliberate design choice rather than an accidental outcome. These diagrams are used by CTOs, VPs of Engineering, and platform teams for organizational design reviews, headcount planning, and DevEx (developer experience) strategy.
This guide covers the four team types, three interaction modes, how to diagram current and future team states, and prompt templates for generating accurate Team Topologies diagrams with AI.
The four team types
- Stream-aligned team: The primary team type — a cross-functional team aligned to a specific value stream (a product area, user journey, or business capability). Stream-aligned teams own their services end-to-end and deliver value directly to customers. They are the teams that all other team types exist to support. Examples: Checkout Team, Search Team, Payments Team, Mobile App Team.
- Platform team: Provides internal developer platforms (IDPs) and shared services that reduce cognitive load for stream-aligned teams. A platform team treats its services as internal products with APIs, documentation, and SLAs. Examples: Infrastructure Platform Team, Developer Experience Team, Data Platform Team, Security Platform Team.
- Enabling team: A temporary or semi-permanent team of specialists that helps stream-aligned teams overcome obstacles and build capabilities they cannot develop alone. Enabling teams actively transfer knowledge so they can step back. Examples: Site Reliability Engineering (SRE) Enablement, ML Platform Enablement, API Standards Enablement.
- Complicated-subsystem team: A team that owns a specific subsystem requiring deep specialist knowledge (e.g., a real-time recommendation engine, a pricing algorithm, a custom cryptography module). Stream-aligned teams interact with this team's subsystem via a well-defined API rather than owning it themselves.
The three interaction modes
- Collaboration: Two teams work closely together for a defined period to achieve a joint goal (e.g., stream-aligned team + enabling team building a new observability capability together). This is high-bandwidth but expensive — use it temporarily, not permanently.
- X-as-a-Service: One team consumes another team's service via a well-defined API, documentation, and SLA — with minimal interaction needed. This is the target end state for platform team interactions. High autonomy, low communication overhead.
- Facilitation: An enabling team helps a stream-aligned team to overcome obstacles and improve capabilities. The enabling team is not a dependency — it coaches and then steps back.
Prompt examples for Team Topologies diagrams
Current-state organization map (before platform reorganization)
"Current-state Team Topologies diagram for a 150-person engineering org before platform team formation: four stream-aligned teams (Checkout, Search & Discovery, User Accounts, Seller Tools) each independently managing their own CI/CD pipelines, Kubernetes clusters, and monitoring setups. No platform team exists — each team is doing infrastructure work in addition to product work. Heavy collaboration mode between all four teams on shared infrastructure concerns (high communication overhead). An SRE enabling team (3 people) exists but is overwhelmed with requests. Show the cognitive load burden on stream-aligned teams with annotation."
Future-state design (after platform investment)
"Future-state Team Topologies diagram for the same org: a new Developer Platform Team (10 engineers) provides a golden-path Internal Developer Platform (IDP) — Kubernetes as a Service, CI/CD templates, observability dashboards, and secret management — consumed by all stream-aligned teams via X-as-a-Service interaction mode. The SRE Enabling Team (6 people now) shifts from firefighting to facilitation — running reliability workshops and defining SLO templates with each stream-aligned team. A new Payments complicated-subsystem team (4 engineers) owns the PCI-compliant payment processing engine used by the Checkout team via API. Stream-aligned teams (now 5 including a new Internationalization team) interact with the platform via self-service tickets, not Slack messages. Show reduced cognitive load on stream-aligned teams and clear service boundaries."
Team Topologies + Domain-Driven Design (DDD) alignment
"A Team Topologies diagram aligned with DDD bounded contexts: the e-commerce domain has five bounded contexts (Catalog, Ordering, Payments, Identity, Fulfillment). Map each bounded context to a team: Catalog Team (stream-aligned, owns product and pricing services), Ordering Team (stream-aligned, owns cart and order management), Payments Team (complicated-subsystem, owns PCI-compliant payment engine — Catalog and Ordering teams consume via API), Identity Team (platform team — provides auth platform to all stream-aligned teams via OAuth2/OIDC), Fulfillment Team (stream-aligned, owns warehouse and shipping integrations). Show bounded context boundaries matching team ownership boundaries — Conway's Law aligned."
Interaction mode timeline during a platform migration
"A timeline Team Topologies diagram showing interaction mode evolution during a Kubernetes platform migration over 6 months: Month 1–2: Platform Team and Checkout Team in Collaboration mode (jointly building Kubernetes golden path templates). Month 3: SRE Enabling Team facilitates Kubernetes training for Checkout, Search, and Accounts Teams. Month 4: Platform Team shifts Checkout Team to X-as-a-Service (golden path pipeline working, self-service). Month 5–6: Platform Team uses Facilitation mode with remaining teams (Search, Accounts). Target state (Month 6): all three stream-aligned teams on X-as-a-Service with Platform Team. Show the progression clearly with time axis."
Team type comparison
| Team type | Primary goal | Key metric | Common interactions |
|---|---|---|---|
| Stream-aligned | Deliver value to end users | Lead time, DORA metrics | X-as-a-Service with platform; Facilitation with enabling |
| Platform | Reduce stream-aligned cognitive load | IDP adoption rate, time-to-first-deploy | X-as-a-Service to stream-aligned teams |
| Enabling | Build capability, then step back | Team capability maturity, NPS | Facilitation with stream-aligned |
| Complicated-subsystem | Own deep-expertise component | API reliability, consumer satisfaction | X-as-a-Service to stream-aligned |
Conway's Law and Team Topologies
Conway's Law states that organizations design systems that mirror their communication structures. Team Topologies uses this as a design lever — the "inverse Conway maneuver" means deliberately designing your team topology to produce the desired software architecture, not the other way around. A Team Topologies diagram makes this alignment (or misalignment) visible: when team boundaries don't match system boundaries, you can expect integration friction, unclear ownership, and architectural coupling.
What to annotate on a Team Topologies diagram
- Team type shape/color: Use the standard Team Topologies visual language — stream-aligned teams as rounded rectangles (blue), platform teams as diamonds (green), enabling teams as pentagons (yellow), complicated-subsystem teams as triangles (orange). Consistent visual encoding makes diagrams portable across the organization.
- Interaction mode on arrows: Label every team-to-team interaction arrow with the mode (Collaboration, X-as-a-Service, Facilitation) — and annotate whether it is the current mode or the target mode.
- Team size: Annotate headcount on each team shape (e.g., "8 engineers"). Team Topologies recommends keeping teams within the Dunbar number range (5–9 people) for cognitive load reasons.
- Ownership boundaries: Draw ownership boundaries around the systems/services each team owns — this is the link between the Team Topologies diagram and the software architecture diagram.
- Cognitive load indicators: Optionally annotate each stream-aligned team with a qualitative cognitive load indicator (low / medium / high / overloaded) to show where platform investment is most needed.
Related guides: platform engineering diagrams, microservice architecture patterns, AI org charts, and enterprise architecture.
Ready to try it yourself?
Start Creating - Free