Conway's Law: The Mirror You Can't Outsmart

If you glance at Wikipedia, you’ll find a definition along these lines: Conway’s Law is an observation, made back in 1967, that organizations design systems which mirror their own communication structure. Melvin Conway, a 1967 paper, and the canonical one-liner: four teams building a compiler will produce a four-pass compiler.

But this isn’t Wikipedia, and I don’t like copying encyclopedic text. So let’s focus on what actually follows from it.

Here’s the framing I’d offer instead. Conway’s Law isn’t a rule you follow or break, like a style guide. It’s a mirror. It doesn’t tell you how to build software — it tells you what your organization already looks like, whether you asked or not. Every module boundary, every awkward integration, every service that talks to exactly one other service is a reflection of who talks to whom, who trusts whom, and who sits in which reporting line. You don’t comply with Conway’s Law any more than you comply with your own reflection. It’s just there, showing you the shape of the thing that built it.

You Can’t Escape This Law

Let’s start by saying one thing plainly: you cannot escape this law. Plenty of teams try, and they all end up in more or less the same place.

A particularly interesting attempt is the so-called Reverse Conway Maneuver, where you deliberately restructure your teams so that they mirror the architecture you want. You want three neatly separated services? Then build three neatly separated teams and let Conway’s Law do the rest.

This can be tempting, and sometimes it genuinely works. But let’s not kid ourselves about what it actually is. Reverse Conway doesn’t defeat Conway’s Law — it leans on it. You didn’t find a loophole; you just decided to pay the bill up front, in reorganization, instead of later, in bad architecture. Sometimes that’s a good deal. But it’s the same bill, just in a different currency. And now you’ve hardened the exact same structure in two places at once: in the org chart and in the code. When one of those two copies goes stale — and it will — you’ve got two problems instead of one.

Alright, but so what?

Software Doesn’t Change as Easily as an Org Chart

Well, the fundamental issue is this: software architecture doesn’t change easily.

If you work in a corporation, you know that a hierarchy can be changed relatively easily. Sure, it’s always a pain in the ass — but a tolerable enough one that companies do it on a regular basis. In practice, all it takes is one senior manager leaving, and there you have it: a reorg, new boxes on the diagram, new arrows, a fresh round of “ownership realignment.”

Software is different. You can’t rearrange an architecture with a single email from a VP. You can decide you’re heading in a new direction, but the cost of rebuilding what already exists is simply impossible to swallow.

History, by the way, knows companies that tried anyway. I often bring up Netscape Navigator (yes, I’m old). Its creators decided that version 4.0 had to be rewritten from scratch. A user-facing version 5.0 never saw the light of day, and what eventually shipped as 6.0 took nearly three years. Three years during which Internet Explorer went from a curiosity to the default. The company didn’t fall over overnight — it limped on for a good decade, getting acquired by AOL along the way — but that rewrite was the nail in the coffin. As a small consolation, the code was opened up, and out of those ashes rose Mozilla, and later Firefox. One of Navigator’s original engineers admits to this day that the decision to rewrite was one of the main reasons he resigned.

Since we’re already knee-deep in ancient history, let me throw in one more curiosity: the Smarty template engine. This was a genuinely long time ago, but there was an era when Smarty 2 was the default templating engine for PHP — long before Latte, Twig, and the rest of the crowd showed up. (And yes, I wrote PHP back then. I’m not ashamed of it — it paid the bills and taught me plenty — but I wouldn’t want to go back today.) Approaching Smarty 3, the authors decided to build everything from scratch to shed the accumulated cruft. They promised flexibility, performance, and a solution to world hunger (delete as applicable). And you know what? The first public beta genuinely was noticeably faster than 2.0. Right up until it hit the real world, where edge cases started surfacing — the ones version 2 quietly handled and the “I’ll do it better” crowd had happily forgotten about. The result? The second beta, the one that actually addressed those cases, ended up slower than the version it was supposed to replace. Oopsies.

The punchline is brutal: you don’t rewrite a working system to fix it. You rewrite it to swap one set of problems you at least understand for another set you haven’t discovered yet.

Software Is Geology

Back to the point. Software is astonishingly close to… geology.

Successive layers pile up on top of one another instead of being removed. And just as geologists read the history of our planet, and archaeologists the history of our civilization, by digging up what lies beneath the ground, a programmer can read the history of an organization by examining the source code of its products.

Found a strange boundary between two modules that makes no technical sense whatsoever? Congratulations, you’ve just unearthed a fossil. That boundary doesn’t reflect what the company looks like today. It reflects what the company looked like at the moment that piece was written — two teams that have since merged, split, one got laid off, and the other got moved under a different VP. The people are gone, but their dividing line stayed behind, set into the code like an imprint in rock.

And this is the missing link that most write-ups of Conway’s Law leave unsaid: your architecture is not a reflection of your current org structure. It’s a reflection of the structure that existed when a given piece was built. You’re reading an outdated map of the company — and every single day you’re paying the coordination cost of boundaries drawn by teams that no longer exist in that form.

One caveat is worth adding here, before you go charging off to refactor. Those strange layers aren’t always junk. Very often they’re congealed knowledge — a workaround for some edge case someone once bled over at three in the morning, a patch for a bug in a library that got fixed three years ago but nobody dared to touch. Before you tear down the fence, make sure you know why it was put up. Usually you don’t. Usually nobody documented it.

I know of companies that have spent a decade and a half trying to get rid of the “quick PoC” once used to validate a product idea. Some of them built a multicorn on top of that product — a company with revenue north of a few billion dollars a year — and still can’t remove that one little piece that was supposed to last two weeks back when they were a fifteen-person startup. That PoC is the lowest geological layer. The entire company stands on it like Amsterdam on eleven million piles. Nobody sees it. Nobody thinks about it. And everybody just hopes the wood doesn’t rot.

The Real Cost of Conway

This brings us to what the real cost of Conway’s Law actually is. Because it isn’t the cost of ugly code. It’s the cost of coordination.

Every API between two teams is, de facto, a political contract rather than a technical decision. The boundary runs where one budget ends and another begins. The data exchange format is what it is because that’s as much as they managed to negotiate in a meeting where both sides were defending their turf. The versioning is rigid because nobody trusts anybody else enough to allow a change without a three-week process.

In the overwhelming majority of cases, when you hear “it’s due to technical constraints,” what someone is actually telling you is: “these two teams don’t like each other,” or “they have separate budgets,” or “they report to different VPs and neither one will back down.” A technical constraint is, more often than not, an organizational constraint that put on a tie and learned to speak in jargon so that nobody has to take it to HR.

And this is the specific flavor of debt almost nobody talks about, because you can’t see it in any linter: organizational debt.

Organizational debt is worse than the technical kind, because technical debt at least can’t hide from your tools. You can measure it, tag a TODO, drop it into the backlog. Organizational debt doesn’t live in the repo. It lives in who signs off on whose budget, and who didn’t invite whom to that one meeting three years ago. That’s why it survives every “let’s just rewrite it from scratch” — because you can throw all the code in the bin and start from a blank page, and still, as long as the organization’s structure stays the same, Conway’s Law will reproduce for you the exact same boundaries in the new, shiny, not-yet-compromised architecture. Wait two years and dig up the fossil again.

Which leads to the one piece of practical advice this whole post is quietly building toward. If your architecture looks chaotic, don’t start by reviewing your diagrams. Start by reviewing your calendar. Before you blame the code, ask whether two of your engineers can even have a normal conversation without opening three Jira tickets and looping in two directors. Because the code isn’t the disease — it’s the symptom. The tangled service graph on your whiteboard is a photograph of the tangled conversation graph in your company, and no refactor touches the second one. You can rename the modules all you like; the org chart is the real source file.

Because Conway isn’t a prophecy you can guard against. It’s a mirror. And you can’t outsmart a mirror — the best you can do is smash it and pretend that seven years of bad luck is a coincidence.