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.
Principal Engineer 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.
Reel Script
Setup: Ask: why does it seem like every company's microservices architecture ends up looking suspiciously like its org chart, even when nobody planned it that way?
Concept walkthrough: Explain Conway's Law plainly — systems mirror the communication structure of the teams that build them. Then introduce Team Topologies' four team types (stream-aligned, platform, complicated-subsystem, enabling) and the three interaction modes, framing them as a deliberate way to choose the communication structure instead of inheriting it by accident.
Real example tie-in: Walk through a payments-and-fraud example: two services that need to share risk signals in near-real-time, built by two teams that only sync weekly. Show how that mismatch forces a brittle, high-latency integration regardless of what the architecture diagram intended — then show the fix, either merging ownership or formalizing a stable async contract between the teams.
Tradeoffs & alternatives: Name the Inverse Conway Maneuver explicitly — restructuring teams first to get the architecture you want, instead of designing architecture and hoping the org adapts. Contrast with standing up a platform team too early, before enough stream-aligned teams share the same real need.
Principal Engineer takeaway: The strong review answer isn't just proposing a clean service boundary — it's naming which team owns each side of that boundary and whether their actual working relationship can sustain it, because the software will end up looking like the org chart whether or not that was the plan.
Related
Sources: