Your architecture is your org chart

In 1968, Melvin Conway published a short paper with a claim that sounded like a throwaway and turned out to be a law of gravity for software: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. Put four teams on a compiler and you’ll get a four-pass compiler. The joke version — “if you have three groups working on a compiler, you’ll get a three-pass compiler” — is funny precisely because every engineer has watched it happen.

The mechanism is almost boringly simple once you see it. Two pieces of software have to talk to each other through an interface — an API, a message format, a contract. Designing a clean interface between two components requires the people building them to communicate closely, negotiate, agree. Where two teams talk constantly, sit together, share a manager, that negotiation is cheap, so the seam between their components is well-designed and can move. Where two teams barely talk — different floors, different orgs, different time zones, a ticket queue between them — the seam calcifies into whatever contract was easiest to agree on once, and then nobody can change it without a cross-org meeting. The software’s structure ends up tracing, line for line, the lines of who-talks-to-whom on the org chart. The system is a map of the organization.

This reframes a whole category of problem. When your services are tangled in ways that don’t match the domain, when a “simple” change requires coordinating five teams, when the module boundaries feel arbitrary and wrong — the instinct is to treat it as a technical mess to be refactored. Conway’s Law says: look at the org first. That arbitrary boundary probably falls exactly where two teams stopped talking. You can rearrange the code all you like, but if the communication structure that produced the boundary is still in place, the boundary grows back. You are, in a real sense, unable to draw an architecture your organization can’t communicate.

The genuinely useful move that falls out of this is the one most teams never consider, because it sounds like it’s the wrong department’s job: change the team structure to get the architecture you want. This is the “inverse Conway maneuver” — if you want a clean, decoupled set of services around business capabilities, first organize your people into clean, decoupled teams around those same capabilities, give them clear ownership and thin, well-defined ways of talking to each other, and let the architecture grow into the shape of the org. It’s why the modern move toward small, autonomous, service-owning teams and the move toward microservices are the same move seen from two sides. The architecture and the org chart are not two problems. They’re one problem with two views.

I’ll keep this honest about what it is. Conway’s Law is an observation and a heuristic, not a theorem — plenty of teams violate it with deliberate effort, strong interface discipline, and a lot of cross-boundary communication that costs real energy to maintain. And there’s a failure mode in over-applying it: reorganizing people is enormously disruptive and slow, and “we need to restructure the whole org” is a heavy hammer to reach for when a focused refactor would do. The point isn’t that you must always reshape teams. It’s that team boundaries are an architectural decision whether or not you treat them as one — so you should design them on purpose, aware that the system will end up shaped like them. There’s real empirical weight behind this, too: studies of large codebases have found that organizational metrics — how many teams touched a component, how far apart they sat — predicted where the bugs clustered better than the code metrics did.

So before you whiteboard the boxes and arrows, look at the seating chart and the reporting lines and the list of who’s actually allowed to change what. That’s the first draft of your architecture, whether you meant to draw it or not. The question is only whether you drew it on purpose.