Team Topologies and Conway's Law
Concept
Conway's Law, stated by Melvin Conway in 1967: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." In plain terms — the software mirrors the org chart, whether or not anyone intended it to. A payments service and a fraud service built by two teams that rarely talk will end up with a brittle, chatty integration between them, regardless of what the architecture diagram says should happen.
Team Topologies (Matthew Skelton and Manuel Pais) operationalizes Conway's Law into a working model with four team types and three interaction modes:
- Stream-aligned team — owns a single, end-to-end flow of business value (a product, a user journey), with everything it needs to ship independently.
- Platform team — builds internal self-service capabilities (deploy pipelines, data platforms, auth) that reduce the cognitive load stream-aligned teams carry, so they don't each reinvent infrastructure.
- Complicated-subsystem team — owns a component that genuinely requires deep specialist knowledge (a matching engine, a codec, a risk model) that would overload a generalist stream-aligned team.
- Enabling team — temporarily embeds with stream-aligned teams to help them adopt a new capability, then leaves — it exists to close a skills gap, not to own anything long-term.
Interaction modes describe how these teams should work together at any given time: collaboration (tight, exploratory, high-bandwidth — used sparingly and temporarily), X-as-a-Service (one team consumes another's output through a well-defined interface, minimal ongoing coordination), and facilitating (one team helps another improve, without doing the work for them).
The Inverse Conway Maneuver flips the law into a design lever: instead of letting the org chart accidentally dictate the architecture, deliberately restructure teams to match the architecture you actually want first.
Tradeoffs
| Team type | Coordination cost | Best fit | Failure mode if misapplied |
|---|---|---|---|
| Stream-aligned | Low (self-contained) | The default — most teams should be this | Becomes a bottleneck if forced to own shared infrastructure it shouldn't |
| Platform | Low to consuming teams, high to build/maintain | 3+ stream-aligned teams with a genuine shared need | Built too early — becomes overhead nobody adopts, or a second bottleneck if under-resourced |
| Complicated-subsystem | Low (isolated by design) | A component with real specialist depth (crypto, ML ranking, codecs) | Used as a dumping ground for anything merely "hard," diluting its specialist focus |
| Enabling | Deliberately temporary | Closing a specific skills gap (e.g. adopting a new observability stack) | Never disengages — becomes a permanent dependency instead of building the stream-aligned team's own capability |
The underlying tension: every added team boundary reduces coordination cost within each team but adds an interface — and a potential integration failure mode — between them. Team Topologies isn't about minimizing team count; it's about making each boundary intentional rather than incidental.
When to use / when not to
- Applies once an org has enough teams that cross-team coordination is itself a bottleneck — roughly 3+ teams sharing a system or a platform dependency.
- The Inverse Conway Maneuver earns its cost specifically when a target architecture (e.g. splitting a monolith into bounded services) is blocked not by technical difficulty but by the current team structure making the split politically or operationally awkward.
- A platform team only pays off once multiple stream-aligned teams have converged on the same underlying need — standing one up speculatively, before that need is proven, produces a team that builds infrastructure nobody asked for.
- Doesn't apply to a single team building a single system — restructuring team topology is an org-scale intervention, not a fix for one team's internal workflow problems.
Common pitfall
Drawing a target architecture on a whiteboard — clean service boundaries, minimal coupling — while leaving the team structure that will build and own it untouched. Conway's Law doesn't care what the diagram says: if two tightly-coupled services are owned by teams that only sync in a weekly standup, the software will drift toward whatever shape that communication pattern actually supports, usually a chattier, more fragile integration than the diagram promised.
Engineering Lens
The Principal-level move in an architecture review is naming the team-shape implication of a design proposal out loud — "this design assumes the payments team and the fraud team share a data model in near-real-time; are we merging that ownership, or building a stable contract between two teams that don't sync daily?" That's a materially different question from debating API shapes in isolation, and it's the kind of framing that reads as organizational, not just technical, judgment. This maps directly onto Fintech/BigTech-scale orgs, where team boundaries — not technology choices — are usually the actual constraint on how cleanly a system can be decomposed.