Team Topologies defines four fundamental team types and three interaction modes. Name them and explain what each is for.
answer
- Four types: stream-aligned, platform, enabling, complicated-subsystem
- Three modes: collaboration, X-as-a-Service, facilitating
- Cognitive load is the sizing constraint
- Collaboration is time-boxed; X-as-a-Service is steady state
- Platform = self-service internal product, pull-based
basics
~20 sTeam types: stream-aligned (owns a slice of business flow end-to-end), platform (provides self-service internal services), enabling (coaches others to gain skills), and complicated-subsystem (owns a part needing deep specialist knowledge). Interaction modes: collaboration, X-as-a-Service, and facilitating.
solid answer
~50 sThe book *Team Topologies* (Skelton & Pais) reduces team design to four types. **Stream-aligned** teams own a continuous flow of work for one business domain or user segment, end to end including run/on-call — they are the default and should be the vast majority. **Platform** teams offer internal, self-service, product-like capabilities (CI/CD, runtime, observability) that reduce stream-aligned teams' cognitive load; adoption should be optional and pull-based. **Enabling** teams are small groups of specialists who temporarily coach stream-aligned teams to close a capability gap (testing, security, performance), then leave. **Complicated-subsystem** teams own parts requiring rare deep expertise (video codec, pricing engine, ML model) so other teams don't have to carry that load. Three interaction modes govern relationships: **collaboration** (two teams work closely, high bandwidth, for discovery, deliberately time-boxed), **X-as-a-Service** (one consumes another's stable interface with minimal talking — the steady state), and **facilitating** (one team helps another learn or unblock). Explicit modes prevent unbounded, permanent cross-team coupling.
go deeper
Name the four types and three modes with a one-line purpose each.
Add why stream-aligned teams dominate, what makes a platform team self-service rather than a ticket queue, and that collaboration is time-boxed.
Tie it to cognitive load and fracture planes; describe the collaboration → X-as-a-Service lifecycle and the anti-patterns for each type.
Discuss designing the whole topology as the communication graph that Conway's Law will render into architecture: evolving topologies over time, sensing when boundaries are wrong, and the governance/funding implications of long-lived teams.
## Context *Team Topologies* (Matthew Skelton and Manuel Pais, 2019) is a socio-technical design framework built directly on Conway's Law. Its core claim: **the team is the fundamental unit of delivery**, and you should design team structures and interactions as deliberately as you design software, because Conway's Law guarantees the two will mirror each other. Its organizing constraint is **team cognitive load** — the amount of domain, technology, and operational knowledge a team must hold. If a team's cognitive load exceeds capacity, flow degrades no matter how good the architecture is. Two supporting concepts: - **Team-first thinking**: teams are long-lived, stable, and sized to sustain trust (roughly 5-9 people; "Dunbar" limits are applied to groupings of teams). Work is assigned to teams, not people shuffled to work. - **Fracture planes**: the natural lines along which to split a system — business domain, regulatory compliance, change cadence, risk, performance isolation, technology, user persona, location/time-zone. Boundaries chosen on fracture planes minimize the cross-boundary coordination that Conway's Law would otherwise convert into pain. ## The four fundamental team types ### 1. Stream-aligned team Aligned to a single valuable stream of work — a product, a service, a user journey, a market segment. It owns build **and** run: design, code, test, deploy, monitor, on-call. It should be able to deliver most changes without waiting on another team. - **Why**: fast flow requires end-to-end ownership; every handoff is a queue. - **Proportion**: the large majority of teams. All other types exist to make these teams effective. - **Anti-pattern**: a "stream-aligned" team that must file tickets with a DBA team, an ops team, and a QA team — that's a component team wearing a new label. ### 2. Platform team Provides internal products that stream-aligned teams consume **self-service**: deployment pipelines, runtime/container platform, observability, identity, data infrastructure. It has its own product manager, roadmap, docs, SLAs, and treats internal teams as customers. - **Why**: reduces cognitive load — a stream team shouldn't need to master Kubernetes internals to ship a feature. - **Key rule**: the platform must be **optional and pull-based**, and "thinnest viable platform" — if teams route around it, that's feedback, not disobedience. - **Anti-pattern**: a rebranded ops/infrastructure gatekeeper that stream teams must ticket to get anything done; that reintroduces the handoff the platform was meant to remove. ### 3. Enabling team A small group of specialists (test automation, security, performance, architecture, continuous delivery) whose job is to **raise other teams' capability**, not to do the work for them. It engages a stream team for weeks to months, transfers skills, and moves on. - **Why**: closes capability gaps without creating a permanent dependency. - **Anti-pattern**: becoming a permanent "center of excellence" that owns work or a permanent approval gate; measured by their own output rather than others' improvement. ### 4. Complicated-subsystem team Owns a component whose correctness requires rare deep expertise — a mathematical solver, video codec, real-time pricing/risk engine, ML training pipeline, device driver. - **Why**: expecting every stream team to hold that knowledge is unrealistic; concentrating it in one team is cheaper than duplicating it. - **Key rule**: created only when specialist knowledge genuinely demands it, **not** merely because a component is large or legacy. - **Anti-pattern**: using it as an excuse to keep classic component teams ("the API team", "the frontend team") that everything must route through. ## The three interaction modes ### Collaboration Two teams work closely together for a defined period, with high communication bandwidth, shared responsibility, and blurred boundaries. - **Use for**: discovery, new/unclear interfaces, rapid learning at a boundary. - **Cost**: high cognitive load, unclear ownership, slower individually. - **Rule**: time-box it. Permanent collaboration means the boundary is wrong — either merge the teams or resolve the interface into X-as-a-Service. ### X-as-a-Service One team consumes something another team provides, over a clear, stable, well-documented interface, with minimal ongoing conversation. - **Use for**: the steady state; predictable delivery; platform and complicated-subsystem consumption. - **Cost**: slower innovation at the boundary; requires real product thinking and good docs/SLAs from the provider. ### Facilitating One team (usually enabling) helps another to learn or to remove an impediment; the helped team keeps ownership. - **Use for**: capability gaps, unfamiliar technology, spreading practices. A typical lifecycle: **collaborate** while the interface is being discovered → the interface stabilizes → switch to **X-as-a-Service**; use **facilitating** whenever the consuming team lacks skills. ## How this connects back to Conway's Law Conway's Law says the communication structure becomes the architecture. Team Topologies makes that structure *explicit and designed*: choosing the type of each team sets what it owns, and choosing the interaction mode sets the *bandwidth* of each edge in the communication graph. High-bandwidth edges (collaboration) predict tight coupling in the resulting code; low-bandwidth edges (X-as-a-Service) predict clean, stable interfaces. So the topology is a deliberate blueprint for the architecture you'll get. ## Common misunderstandings - **"Four types = four boxes for every org".** They're patterns, not a mandatory org chart. Most orgs are mostly stream-aligned teams plus a small platform. - **"Platform team = infrastructure team renamed".** Only if it is self-service and product-managed; otherwise it's a bottleneck. - **"Enabling team owns quality/security".** No — it teaches; ownership stays with stream teams. - **"Interaction modes are cultural preferences".** They're explicit, agreed, and reviewed periodically; ambiguity is what makes cross-team work rot. - **"More collaboration is always better".** Collaboration is expensive and should be deliberately reduced once a boundary is understood.
- How do you decide when two teams should move from collaboration to X-as-a-Service?When the interface between them has stabilized and most changes on either side no longer require the other's involvement. Signals: the API/contract stops changing every sprint, the consuming team can self-serve from docs, and joint work sessions no longer produce new discoveries. Persistent collaboration is a sign the boundary is misplaced.
- What is team cognitive load and how do you use it in team design?It's the total domain, technical, and operational knowledge a team must hold to do its job (intrinsic, extraneous, and germane load). You use it as a budget: if a team owns too many subsystems or too much undifferentiated platform work, reduce scope, remove extraneous load via a platform, or split the domain. It is the primary sizing constraint for a team's responsibilities.
- What are 'fracture planes' and why do they matter?Natural lines along which to split a system: business domain, change cadence, regulatory/compliance boundary, risk, performance isolation, user persona, technology, and geography/time zone. Cutting along a fracture plane minimizes cross-boundary change, so the resulting team and service boundaries stay independent.