Conway's Law

The idea

In a paper written in 1967 and published in Datamation in 1968, Melvin Conway argued that any organisation that designs a system will produce a design whose structure copies the organisation's communication structure. If four groups build a compiler, you get a four-pass compiler.

The reasoning is simple. Every interface between two parts of a system needs the people building those parts to agree on it. People who talk every day can agree on rich, fine-grained interfaces; people in different departments, time zones, or companies can only agree on narrow, formal ones. So the boundaries in the software settle where the boundaries in communication already are.

It is less a recommendation than a force of nature. When the org chart and the intended architecture disagree, the org chart usually wins.

Why it works

Coordination is expensive. Changes that cross team boundaries need meetings, tickets, and negotiation. Teams naturally design to avoid them, so the system ends up split where coordination is hardest.

Ownership shapes code. A component owned by one team tends to be internally coherent. A component owned by several tends to grow internal seams that match each team's share of it.

Interfaces freeze around relationships. Once two teams agree on an API, changing it means re-opening that negotiation. The interface stays as long as the relationship does.

Where it applies

• Design reviews. Reviewing an architecture without looking at who will build and run each part misses the force most likely to reshape it.
• Reorganisations. Moving teams around changes the architecture you will get over the next few years, whether or not anyone intends it.
• Vendor and outsourcing decisions. A contract boundary is a communication boundary, and it will become a system boundary.
• Platform and shared-service design. A central team serving many others produces a system shaped like a hub with many spokes.

How to apply

1. Map communication, not just reporting lines. Find out who actually talks to whom to get work done. Hand-offs, shared backlogs, and approval chains matter more than the official org chart.
2. Lay the map over the architecture. Mark which team owns each component and where changes regularly need several teams. Those hot spots are where the two structures fight.
3. Decide which structure should lead. Either design the architecture to fit the teams you have, or change the teams to fit the architecture you want. The second option is the inverse Conway manoeuvre.
4. Give each team a clear boundary. Aim for teams that own whole components end to end, with well-defined interfaces to other teams, so that most changes stay inside one team.
5. Revisit as both evolve. Teams and systems both drift. Check the fit regularly, especially after reorganisations or large new initiatives.

Example scenario

Three teams shared the checkout service: payments, promotions, and the web front end. Over two years it grew three distinct internal layers, each with its own conventions, joined by awkward hand-offs that only a few people understood. Every change to checkout needed all three teams in the room.

The company gave checkout to a single team and let the other two consume it through a narrow API. Within six months that team had refactored it into one coherent design, and lead time for checkout changes dropped sharply because they no longer needed cross-team coordination.

Questions to ask

When not to use it

• As a reason to reorganise for every new design. Team changes are slow and expensive; a design that fights the current structure for a short while can be the cheaper option.
• For small, single-team systems. When one team builds everything, the law still holds but has little to tell you.

How it misleads you