Conway's Law

Pradeep P

Sep 2

3 min read

Series: Modern System Design · Layer 7 — Patterns and problems

Layer 7 · Post 2 of 5

← Previous: The End-to-End Argument → Next: Strangler Fig

Layer 7 — Patterns and problems · Post 116 of 119

You ship your org chart. Service boundaries that fight how people talk will keep rotting.

What you'll learn

Conway's actual claim, not the meme
Inverse Conway: when to change the team to get the architecture you want
How this shows up in BFFs, cells, and "shared platform" teams

The idea in one minute

Conway's Law (Melvin Conway, 1968): organizations design systems that copy their communication structure.

If four teams do not talk, you get four services and four awkward integration tickets. If one team owns "the backend," you get a monolith (or a distributed monolith with the same standup). If iOS and API are different VP orgs with a quarterly contract, the mobile app will be chatty until someone funds a BFF (Post 98) — which is Conway: give the iOS team a talk path (their own backend) that matches how they ship.

Org:   [Payments team]    [Risk team]    [App team]
Code:  payments-svc        risk-svc       app  --HTTP--  both
       (the arrows match the meetings)

It is descriptive. It is not an excuse for a bad design. It is a warning: architecture review without org review is fan fiction.

Why it matters

System design interviews pretend a single architect draws boxes. Production boxes are team APIs, on-call, and deploy permissions.

If you draw a "user service" but identity is split across three groups with three roadmaps, you will get three user tables. Dual writes (Post 108) then become a staffing problem.

How it works

Homomorphic mapping. Interfaces between teams are thick (versioned APIs, tickets). Interfaces inside a team are thin (function calls, a monolith module). That is why "microservices for a 6-person startup" often adds communication cost they do not have staff for.

Inverse Conway maneuver. Want a clean checkout boundary? Put a team on checkout with the right people (payments + fraud + a slice of app), not a "shared services" team that owns everyone's YAML. Cells (Post 113) often need a platform team that owns the cell machine, and product teams that own tenants inside — two Conways stacked.

Platform teams. If every product team must file a ticket to get a Kafka topic, you designed a bottleneck org, then a bottleneck architecture. Self-service is Conway too: communication via software, not Slack.

Too-clean architecture. A beautiful domain model that no team is staffed to own will rot. Assign owners or simplify the boxes.

A simple example

Company reorgs into "front-end" vs "back-end." Six months later: BFF vs 40 public APIs arguments, GraphQL layer owned by nobody, mobile blocked on backend sprint 18.

Inverse Conway: experience teams (Search, Checkout, Account) each with web + API + data for that slice, plus a small platform for identity and observability. The architecture starts looking like those slices — on purpose.

A merger of two companies: two billing systems forever, because two finance orgs. The "temporary" dual-write is Conway with a Jira label.

Common mistakes

"Conway says we must have N services for N teams." You can have a modular monolith with one deploy if the modules match teams. Services are optional; boundaries and ownership are not.

Ignoring Conway in a redesign. New boxes, old reporting lines, same mess in a quarter.

Using it to score points in a meeting. The useful move is name the team that will on-call this box.

Platform as a dump. "Core" team of two owning 40 libraries is a communication star topology. It will look like a star in the call graph.

How this shows up in real systems

Amazon two-pizza teams / "APIs between teams." Conway as policy.
Spotify squads/tribes (the blog, not the cargo cult): attempt at inverse Conway.
Kubernetes + platform engineering: fewer tickets, more paved roads.
Every bank integration: org boundaries are the latency.

Recap

Systems mirror how people communicate; design owners with the boxes.
To change the architecture, change the communication paths (teams, BFFs, self-service).
Next: a migration pattern that respects Conway and risk — strangler fig.