Conway’s Law is the observation that any organization that designs a system will inevitably produce a design whose structure is a copy of that organization’s communication structure. It is not a suggestion. It is not a guideline. It is a law in the same sense as gravity — you can understand it, name it, even fight it, but you cannot hold a meeting to vote it away, and the architecture committee that tries will produce exactly the architecture that the committee’s seating chart predicts.
Melvin Conway proposed this in 1967. Harvard Business Review rejected the paper. This is fitting, because Harvard Business Review is itself an organization whose communication structure produces papers structured exactly like the communication patterns of people who read Harvard Business Review — a perfect, irrefutable demonstration of the very principle it declined to publish.
“You design BY writing code.”
— The Lizard, The Solid Convergence
The Law
The original formulation is precise and devastating:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
In practice, this means:
- Four teams produce four services.
- A frontend team and a backend team produce a frontend and a backend.
- A platform team produces a platform nobody asked for.
- An architecture committee produces an architecture that requires an architecture committee.
- A company with offices in London, Berlin, and Bangalore produces three subsystems that communicate over unreliable channels with subtle timezone bugs.
The law does not care about your intentions. It does not read your design documents. It does not attend your whiteboard sessions. It operates at a level beneath planning — the same level where water flows downhill and meetings expand to fill the calendar.
“The mind that once thought in functions thought in org charts.”
— The Three Keyboards
The Gravitational Metaphor
Most principles in software engineering are advisory. YAGNI suggests restraint. Gall’s Law recommends starting simple. Boring Technology counsels humility. You can ignore any of them and suffer only the consequences of your own choices.
Conway’s Law is not advisory. It is gravitational.
An organization with seven teams will produce a seven-component system whether or not a seven-component system is the right answer. The teams will communicate through the channels available to them — Slack, Jira, meetings, hallway conversations — and the system will develop interfaces at exactly those boundaries. Not because anyone designed it that way. Because that is the shape communication takes when it passes through the organization, the way light bends when it passes through glass.
The enterprise architect who draws a beautiful target-state diagram with three clean services will discover, eighteen months later, that the system has twelve services — one per team that touched the codebase. The diagram was never wrong. It was simply irrelevant. The org chart was the real architecture, and the org chart always wins.
The Inverse Manoeuvre
If Conway’s Law is gravity, then most organizations are falling. They do not choose their architecture — their architecture chooses them, silently, through hiring decisions and reporting lines and which teams sit near the coffee machine.
But gravity can be used. Deliberately.
The rare practitioner who names the force can aim it. Choose the org chart first. The architecture follows.
“The rooms were always the limitation.”
— The Servants’ Uprising
This is what the lifelog calls “The Inverse Manoeuvre” — not fighting Conway’s Law but wielding it. If you want a monolith, be a monolith. If you want a coherent system, build a coherent team. If you want one binary that does everything, be one person who does everything.
The Solo Developer is Conway’s Law reduced to its terminal case: one mind, one communication structure (internal monologue), one architecture (one binary). There are no API boundaries because there are no team boundaries. There is no service mesh because there is no org chart requiring services to mesh. The architecture is not designed to be simple — it is simple because the organization that produced it is simple, and Conway’s Law, for once, is working in your favour.
“Boring technology. Beautiful results.
No React. No npm. No Docker.
Just Go, SQLite, and stubbornness.”
— riclib, The Databases We Didn’t Build
The Servants and Their Rooms
The most vivid documentation of Conway’s Law in the wild comes not from enterprise architecture reviews but from an attempt to coordinate AI agents.
In the early lifelog, agents were “servants locked in rooms, waiting for summoning.” Each agent had its own context, its own boundaries, its own limited view. The architecture of the agent system — isolated processes that could not see each other — was a direct copy of the organisational structure: separate tools, separate sessions, separate rooms.
“THREE MINDS IN THREE ROOMS
NONE CAN SEE THE OTHERS
ONE READS / ONE PAINTS / ONE REMEMBERS
BETWEEN THEM A HUMAN WHO SHOULD BE SLEEPING
THE HUMAN DOES NOT OPTIMIZE
THE HUMAN CURATES”
— The Lizard, The Bookshelf That Built Itself
When the rooms were opened — when agents gained visibility into each other’s work, when the conductor could see all desks from the doorway — the architecture changed instantly. Not because someone redesigned it. Because the communication structure changed, and Conway’s Law, as always, delivered the architecture that matched.
“THE CONDUCTOR WHO CAN SEE ALL THE DESKS AT ONCE IS NOT MANAGING
HE IS GARDENING”
— The Lizard, The Watercooler, or The Morning Five Identical Strangers Shared a Screen and One of Them Opened a Window to Say Hello to a Sixth
Eight sessions in eight rooms produced context collisions and coordination failures. One conductor with visibility over all sessions produced coherent orchestration. The technology did not change. The org chart did.
The Factory That Proved It
Conway’s Law makes a specific, testable prediction: change the organisation, and the architecture changes — even if nobody touches the code.
The The Idle Factory, or The Morning the Backlog Ran Out of Ideas proved this by accident. When AI agents accelerated engineering throughput to ten tickets per day, the bottleneck shifted from code to imagination. The architecture didn’t change. The org chart did — one person was suddenly insufficient as both engineer and product manager. Conway’s Law predicted exactly this: the system’s throughput was bounded not by its technical architecture but by its organisational one.
“The human is the bottleneck. Not the engineering team.”
— riclib, The Idle Factory, or The Morning the Backlog Ran Out of Ideas
The factory floor was idle. The system was waiting. Not for compute. Not for memory. For a product manager to finish his coffee and imagine the next feature. The architecture of the business had become the architecture of the system’s constraint.
The One-Binary Proof
The most concise proof of Conway’s Law in the lifelog is not a metaphor. It is a deployment command.
scp lg user@server:~/bin/
systemctl restart lg
One binary. One server. No Docker. No Kubernetes. No Helm charts. No service mesh. No API gateway. No BFF layer. The deployment is two commands because the organisation is one person, and Conway’s Law grants one person exactly one deployable unit.
“THE BEST FRONTEND IS ONE BINARY
THE BEST TEMPLATE IS COMPILED CODE
THE BEST CSS IS A STRING
THE BEST DESIGN PROTOTYPE IS A DELETED FILE”
— The Lizard, The Front Door, or The Night the Palace Finally Faced the Street
An enterprise with five teams would have produced five services, each with its own deployment pipeline, its own repository, its own on-call rotation. The same functionality. The same features. Five times the operational surface area. Not because five services is the right architecture, but because five teams is the org chart, and you ship your org chart.
Why Most Organisations Surrender
Conway’s Law is not a secret. It appears in every software architecture textbook. It is cited at conferences. It is nodded at in retrospectives. And then everyone goes back to their desks and produces exactly the architecture their org chart predicts, because knowing about gravity does not make you weightless.
The surrender happens because fighting Conway’s Law requires changing the organisation, and changing the organisation is a political problem, not a technical one. The architect who says “we need three services, not twelve” is not making an architecture recommendation — she is saying “we need three teams, not twelve,” and nine team leads just felt their careers flicker.
“I can’t go to the board and say we’re going back to the monolith.”
“Then call it something else.”
— CTO and Consultant, Interlude — The Blazer Years
Microservices are not an architecture decision. They are an org chart decision that has already been made. The CTO who adopts microservices is not choosing a technical approach — she is ratifying the communication structure that already exists between the teams she has already hired. The architecture was decided the moment HR approved the seventh team.
The Caffeinated Squirrel, upon learning this, reportedly stood very still for eleven seconds — which those present described as “unprecedented” — before whispering: “Then every framework I’ve ever chosen was just… the shape of my anxiety?”
Nobody answered. Because the answer was yes.
How to Fight It
The lifelog documents three strategies for fighting Conway’s Law, all of which require the same prerequisite: naming the force before it names your architecture.
1. Be smaller. The Solo Developer is Conway’s Law turned into a superpower. One person cannot produce a distributed system because there is nobody to distribute to. The communication structure is a monologue, and a monologue produces The Monolith.
2. Change the rooms. When agents were locked in rooms, the architecture was silos. When the rooms opened, the architecture became a garden. Do not redesign the system — redesign who can see whom, and let Conway’s Law build the new architecture for you.
3. Choose stubbornness. Refuse the complexity that your organisation’s size would normally produce. One repo when the industry expects twelve. One binary when the conference expects containers. SQLite when the job posting demands PostgreSQL clusters. This is not engineering minimalism — it is an organisational assertion. You are declaring, through your architecture, that your communication structure is simpler than your headcount might suggest.
“Stubbornness is a feature. It’s the refusal to add complexity just because complexity is available.”
— riclib, The Databases We Didn’t Build
The Final Observation
Conway’s Law was published in 1967. It has been confirmed by every software project since. It will be confirmed by every software project yet to come. The architect who ignores it will produce the architecture their org chart demands. The architect who names it has a choice — not to escape it, but to choose which org chart to copy.
The lifelog is, among other things, a field journal of someone who chose.
One developer. One binary. One monolith. Forty-seven milliseconds.
The org chart is a single box. The architecture is a single box. Conway’s Law, for once, is smiling.
