Essay · No. 033

Conway's Law in Reverse

For nearly sixty years we redrew org charts to fix rigid software. Now the software bends in days, and the org chart has quietly become the most permanent artifact in the building.

Herman Geldenhuys July 31, 2026 5 min read
Poster for “Conway's Law in Reverse”

In 1968, Melvin Conway published something so obvious that almost nobody had said it: organizations ship their communication structure. His own example is still the best one. Eight people were assigned to build two compilers: five to COBOL, three to ALGOL. The COBOL compiler ran in five phases; the ALGOL compiler ran in three. The software mirrors the org chart, not because anyone intends it, but because a system can only be as coherent as the conversations that produced it.

For nearly sixty years we treated this as a law about software, and we responded accordingly. When the architecture was wrong, we reorganized. We ran the “reverse Conway maneuver”: redraw the teams first, and the codebase will slowly follow. It worked, more or less, because of an assumption so universal we never wrote it down. The software was the rigid thing. Code was expensive to restructure, careers were spent untangling it, so we moved the flexible thing (people) to accommodate the stubborn thing (systems).

That assumption just quietly died. And here is the paradox worth sitting with: Conway’s Law did not break. It got stronger. Only the direction of the pressure reversed.

The slow artifact changed places

AI-assisted development has made software the fluid material. A refactor that once justified a two-year roadmap can now be attempted in a sprint and repeated until it holds. Services can be split, merged, rewritten, and rehearsed at a pace that would have sounded like satire a few years ago. We may argue about the exact speed, but not about the direction: code is becoming the cheapest thing in the building to change.

Which means the org chart is now the slowest, most rigid artifact we own. Reporting lines take quarters to move. Turf takes years. A silo can outlive three technology stacks and every executive who promised to dissolve it.

Conway’s Law never cared which side was rigid. It only says the structure of communication gets compiled into the structure of the system. So when the compilation speed goes up, the law does not relax; it becomes ruthless. Every seam in how we talk to each other, every approval that exists for historical rather than logical reasons, every boundary drawn in an old political settlement, now gets faithfully transcribed into software at machine speed. We used to ship our org chart slowly enough to disguise it. Now we ship it every week, in high fidelity.

The old question was: does our architecture match our organization? The new question is stranger and more useful: is our organization worth compiling?

The lesson under the city

Montreal already ran this experiment, in concrete, beneath our feet.

The underground city was not designed from a blank page. The RESO’s first tunnels were dug where the city already moved: under the corridors between Central Station, the new towers, the Metro. The passages traced existing flows of people the way software traces existing flows of conversation. Structure followed behavior.

Then, as structures do, the tunnels started returning the favor. Once a passage existed, foot traffic bent toward it. Retailers clustered along it, towers negotiated to connect to it, and whole blocks became valuable or sleepy depending on whether they touched the network. On any February morning, thousands of us walk routes that a planner’s pen fixed decades ago. Behavior now follows structure.

That double movement is the whole story of Conway’s Law. First we build the tunnel to match the flow; then the flow reshapes itself to match the tunnel. Nothing sinister in it. But notice the asymmetry: the pedestrians adapt in days, the tunnels in decades. Whichever layer changes slowest ends up governing the other.

In our organizations, the slow layer used to be the code. It is now the chart. We have become the tunnels.

Reading the org chart as source code

This is where the curiosity should kick in, because the inversion hands leaders a genuinely new instrument. If the organization is what gets compiled, then the org chart deserves the same review we would give source code before shipping it.

Read it that way, honestly, and useful questions surface on their own. Where two departments communicate only through a ticketing queue, expect the systems on either side to integrate through something equally grudging; the queue is an interface declaration, and it will be honored. Where a boundary exists because of a merger in another decade, ask whether we would write that module today, or whether we are maintaining legacy structure the way we once maintained legacy code. Where a decision needs five signatures, understand that we have specified a five-stage pipeline, and the machines will build it for us with perfect, uncomplaining literalism.

The practical discipline follows naturally. Before the next system is commissioned, it is worth sketching the communication paths it will inherit and deciding, deliberately, which of them we actually want preserved in silicon. It is worth treating a reorganization the way we treat a schema migration: rarely, carefully, but without superstition, because the downstream systems will now follow the change in weeks rather than years. And it is worth maintaining a small, standing habit of asking of any seam: is this boundary a decision, or a fossil? Fossils compile just as cleanly as decisions do. That is precisely the problem.

None of this requires a transformation program. It requires only that we stop treating the org chart as an administrative document and start treating it as what it has always secretly been: the highest-level programming language in the company. We have simply never had a compiler fast enough to make the fact urgent.

The good news hiding in the inversion

Here is the hopeful turn, and it is not a consolation prize. For nearly sixty years, leaders who wanted better systems had to work through the slow medium of software, nudging architecture over multi-year horizons. Now the leverage has moved to the thing leaders actually control: how we choose to communicate. Redesign a conversation, and the systems will follow at a speed the old world never offered us.

The constraint was never really technical. It was always about who talks to whom, and about what. AI did not change that truth; it merely removed the place we used to hide from it.

So the invitation is simple, and it costs nothing to accept. Pull up the org chart this week and read it the way a reviewer reads a pull request: with respect, with curiosity, and with a pen. Somewhere in that diagram is the next system we are going to ship, whether we meant to or not. We might as well mean to.

Herman Geldenhuys is an engineering leader who writes from Montreal, Quebec, about the un-heroic side of leading teams through the AI moment.

Also on the bill