Conway's Law
Also known as: Conway's law, inverse Conway manoeuvre
Conway's Law observes that a system's structure mirrors the communication structure of the organisation that builds it. Three teams will produce three components with the interfaces their meetings support, whatever the architecture diagram says — which makes team design an architectural act.
Last reviewed · Part of the Architecture Glossary
In practice
The observation is descriptive; the useful part is the inverse Conway manoeuvre — deliberately shaping teams to produce the architecture you want, rather than fighting the org chart with a diagram.
Symptoms that Conway is winning:
- A service boundary follows a reporting line, not a bounded context.
- Every feature needs three teams, so every feature needs a programme manager.
- A shared component is owned by whoever created it and blocks everyone else — the platform team as bottleneck rather than enabler.
- Two teams in different time zones produce a chatty synchronous interface and then complain about latency.
Corollaries worth stating in an architecture review: components maintained by one team have cleaner interfaces than components maintained by two; a boundary that requires constant cross-team coordination is in the wrong place; and an architecture that needs a reorg to work will not survive contact with the current one unless the reorg actually happens.
When it matters
Any decomposition, any platform-team formation, any acquisition where two engineering organisations must produce one product.
Common mistake
Designing microservices for a team of eight. Eight people cannot maintain twelve services, so they maintain a distributed monolith with twelve deployment units — the architecture is real, the organisation to support it is not.
See also
- Bounded ContextA bounded context is an explicit boundary within which a domain model and its terms have one consistent meaning.
- CouplingCoupling is the degree to which one component depends on the internals of another, measured by how much of it must change when the other changes.
- ADR (Architecture Decision Record)An ADR is a short, immutable document capturing one architecturally significant decision: its context, the options considered, the choice, and the consequences.