Conway's Law:
Why Your Org Chart Is Also Your System Diagram

The Law in One Sentence

Conway's original formulation was blunt: any organization that designs a system will produce a design whose structure mirrors the organization's structure of communication. Not its intended structure. Not the one in the slide deck from the last reorg. The one that's actually in use, day to day, measured by who's in whose Slack channel and whose calendar overlaps with whose.

This is not a metaphor. It is closer to a physical law, in the sense that it doesn't care whether you believe in it. A designer can draw four clean microservices on a whiteboard, but if the four teams building them share one Slack channel, sit in the same standup, and constantly informally sync, what actually ships is closer to one system wearing four folders. And a designer can draw one clean monolith, but if it gets built by five teams that never talk except through a quarterly planning doc, what ships is five badly-stitched modules wearing one folder.

Communication Structure Is the Real Spec

Every architecture review asks the same implicit question, "where does this module end and that one begin," and treats it as a technical decision. It usually isn't. The boundary that survives contact with real deadlines is almost never the one on the diagram. It's the one that matches how the two teams actually reach each other. A clean interface requires two groups willing to have an ongoing, slightly annoying conversation about the messy edge cases between them. If that conversation isn't happening, no diagram forces it into existence. The interface just gets uglier until it matches the silence.

This is why "just write better documentation" so rarely fixes a bad interface. Documentation is one-directional and asynchronous. It describes a decision; it doesn't negotiate one. The parts of a system that stay clean over time are almost always the parts where the humans on either side of the boundary are still talking, not just where someone once wrote the interface down correctly.

The Interface Is Wherever the Silence Is

Flip the law around and it becomes a diagnostic instead of just an observation. Instead of asking "where should the module boundary go," ask "where in this organization does communication actually drop off." That's where the real interface already is, whether anyone designed it or not, and it's usually the worst-behaved part of the system: the part with the most surprising bugs, the most defensive error handling, the most "please don't change this without asking" comments.

This is also why reorgs are so much more disruptive to software than they look on the announcement slide. Moving a box on an org chart changes who sits in whose standup, and that change eventually reaches into the codebase itself, redrawing module boundaries whether or not anyone meant to. The org chart isn't a description of the system. It is, with a lag, a forecast of it.

You Can Reverse It

If communication structure predicts system structure, the useful move is to stop treating that as fate and start treating it as a lever. This is usually called the inverse Conway maneuver: instead of designing the system you want and hoping the org catches up, design the org you'd need in order for that system to fall out naturally. Want two services with a genuinely clean, minimal interface between them? Put the two teams building them in separate rooms, on separate schedules, talking only through a defined channel. The distance will do more to enforce the boundary than any code review ever will. Want one deeply integrated feature? Put everyone building it in one room, on one channel, and stop pretending the org chart's separate boxes mean anything.

The maneuver also works as a warning. If a reorg is about to put two previously separate teams into constant daily contact, expect the clean boundary between their systems to start dissolving within a quarter, whether that was the intent or not. That's not a failure of discipline. It's the same law running in the direction nobody was watching for.