# Conway's law

> A system's structure ends up mirroring the communication structure of the organization that builds it.

Concept · Laws of software engineering · https://levelcode.org/concepts/conways-law

**Conway's law** says that any organization that designs a system will produce a design whose structure copies the organization's communication structure. Melvin Conway published it in 1968 in "How Do Committees Invent?", and it has held up better than almost any other rule on this list.

## How it works

Two parts of a system can only fit together well if the people building them talk to each other. When they talk often, the boundary between their code stays loose: shared types, quick changes on both sides. When they rarely talk, they agree on an interface once and then stop touching it. That interface becomes a hard seam in the architecture, whether or not the problem needed one.

The result is predictable:

- Three teams building a compiler produce a three-pass compiler.
- A frontend team and a backend team produce a "backend for frontend" API shaped like their weekly sync, not like the data.
- A company that splits into ten product teams ends up with ten services, then spends years on the [shared data](https://levelcode.org/concepts/normalization-vs-denormalization) between them.

The law describes a force, not a choice. You can fight it, but every time the org chart and the architecture disagree, the org chart tends to win.

## Using it on purpose

The **inverse Conway maneuver** turns the law around: decide the architecture you want first, then shape teams to match it. If you want independent services, give each one a team that owns it end to end, including the on-call rotation. If one team must own two modules, expect them to drift together.

It also explains several familiar failures:

- [Microservices](https://levelcode.org/concepts/monolith-vs-microservices) in a company with one team usually become a distributed monolith, because one group of people will keep changing all of them at once.
- A reorg quietly invalidates the architecture. Services whose owners now sit in different departments start to collect workarounds at their boundary.
- Cross-team changes are slow because they need meetings, not because the code is hard.

When you [approach a design](https://levelcode.org/roadmaps/system-design/approach-a-design), ask who will own each box. If the answer doesn't match the boxes, change one of them.