Conway’s law
Conway’s law states that any organisation that designs a system will produce a design whose structure mirrors the organisation’s own communication structure. The shape of what you build copies the shape of how your teams talk.
How does Conway’s law work?
Interfaces in a product form at the seams between teams, because the people who must negotiate a boundary are the people who don’t share a room or a manager. Change the communication structure and the system’s structure follows.
The shape of what you build copies the shape of how your teams talk.
How do you use Conway’s law?
- Predicting architecture: a product built by four siloed teams will tend to have four loosely-joined modules with awkward seams between them.
- The “inverse Conway manoeuvre”: deliberately shape teams to match the architecture you WANT, so the org produces it.
- Diagnosing integration pain: clumsy interfaces between components often trace to poor communication between the teams that own them.
What does Conway’s law look like in practice?
If a company splits its app into separate “front-end” and “back-end” departments that rarely talk, the product tends to ossify into a rigid front-end/back-end split with a brittle API in between — the software’s seam sits exactly where the org chart’s seam sits.
Where does Conway’s law fail?
It describes a tendency, not an iron law — disciplined design can resist it. Treated fatalistically, it becomes an excuse (“our architecture is bad because our org is bad”) instead of a lever to redesign teams.
- The causal arrow runs both ways: architecture also reshapes how teams communicate, so the mirror is a loop, not a one-way copy.
- It says nothing about whether the mirrored structure is good, only that it will resemble the organisation.
- In small teams or greenfield projects the effect is weak, so it applies unevenly across situations.
The counter-model: Incentives — Team incentives, not just communication lines, drive design choices, so shaping incentives can override the structure Conway's law predicts.
How do you apply Conway’s law, step by step?
- Map how your teams are divided and how they actually communicate.
- Predict the system boundaries that structure will tend to produce.
- Compare that predicted shape to the architecture you actually want.
- Where they diverge, reshape team boundaries or incentives before writing code.
- Recheck the built system against the org chart to confirm the alignment held.
Frequently asked
- What is Conway’s law?
- The principle that the structure of a system you design ends up mirroring the communication structure of the organisation that designed it.
- Who is Conway’s law named after?
- Computer programmer Melvin Conway, who stated it in a 1967 paper (“How Do Committees Invent?”).
- What is the inverse Conway manoeuvre?
- Deliberately structuring teams to match the desired software architecture, so the organisation naturally produces that architecture.
Related
Keep reading
The sunk cost fallacy
The ticket money is gone either way — the only real question is how you spend the evening.
See this alongside the other thinking tools of software engineers.
Go deeper
The book behind this idea: The Mythical Man-Month by Frederick P. Brooks Jr.. Hear the whole thing free — start an Audible trial and your first audiobook is on the house.
Read the full summary of The Mythical Man-Month →
More canonical picks:
- Thinking, Fast and Slow — Daniel Kahneman
- The Art of Thinking Clearly — Rolf Dobelli
- The Great Mental Models, Volume 1 — Shane Parrish
- Poor Charlie’s Almanack — Charlie Munger
- Super Thinking — Gabriel Weinberg & Lauren McCann
- Seeking Wisdom — Peter Bevelin
As an Amazon Associate, ReadGlobe earns from qualifying purchases and Audible trials — at no extra cost to you.
Cite this page
ReadGlobe. (2026). Conway’s law. https://readglobe.com/model/conways-law/
"Conway’s law." ReadGlobe, 30 June 2026, readglobe.com/model/conways-law/.
Primary source: Wikipedia
Editorial synthesis © ReadGlobe 2026, drawing on the mental-models tradition (Charlie Munger, Farnam Street) and the primary sources for each model. · Last reviewed 2026-06-30.