Conway's Law: Why Your Architecture Mirrors Your Org Chart

A codebase crosses my desk with four services. Not because anyone sat down and decided the domain split four ways, but because the company had four teams, and each team shipped the piece it owned. The seams between the services fall exactly where the seams between the teams fall. Where two teams talk often, the services have a clean, well-documented interface. Where two teams barely talk, there is a brittle nightly job nobody wants to touch. Nobody designed it this way. It grew this way, and it grew this way because of a rule that was written down in 1968.

That rule is Conway's law, and once you have seen it you cannot unsee it. It is not a productivity tip or a management fad. It is a structural observation about how software actually gets built, and it holds whether you know about it or not. The useful part is not the observation itself, which most engineers half-know already. The useful part is what you do with it: you can let the law shape your system by accident, or you can point it at the architecture you actually want. Here is what the law says, what it looks like in real systems, and how to run it forward on purpose instead of discovering it in a post-mortem.

What is Conway's law?

Conway's law states that any organization that designs a system will produce a design whose structure copies the organization's communication structure. Melvin Conway published it in 1968 in a paper called "How Do Committees Invent?", and the one-line version has outlived almost everything else from that era of computing: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

The mechanism is not mystical. For two pieces of software to talk to each other cleanly, the people building them have to agree on the interface between them. That agreement is a conversation, and it can go wrong in a quiet way: if each team assumes the other has already signed off, the interface ossifies around a decision everyone nodded along to and no one actually wanted. If two teams talk constantly, they negotiate a good interface and keep it in sync. If two teams sit in different buildings, different time zones, or different reporting chains, the interface between their components ossifies into whatever they agreed on once and never revisited. The software boundary becomes a fossil of the org boundary. Once that boundary exists, the consuming team stops reading the interface as documented and starts depending on whatever it actually does, which is Hyrum's law arriving through the org chart: a cross-team interface is exactly the setting where an accidental behavior becomes a contract fastest, because the other team is watching what your service does, not what your spec says it does. One practical defense against that fossilization is to build the receiving side of a cross-team interface to be forgiving of what the other team sends rather than brittle about it, which is the durable half of Postel's law.

The law is symmetrical, which is the part people miss. As Martin Fowler puts it, the law is not a lament but a leverage point: it does not only say "your teams shape your system," it also says that if you want a particular system shape, you may have to change your teams to get it. That symmetry is where the law stops being trivia and starts being a tool. It is also why the reasoning behind your boundaries is worth keeping somewhere it will stay current, which is a thread we pick up at the end, and the problem Scribelet exists to fix.

Why your architecture ends up shaped like your org chart

The pressure Conway described is not something a good architect can simply overrule. It comes from three forces that operate on every team, every day, whether or not anyone is paying attention.

The first is communication cost. Coordinating a design decision across a team boundary is expensive: it needs meetings, documents, sign-off, and follow-up. Coordinating inside a team is cheap: someone turns their chair around. So teams naturally push complexity toward the interfaces they control and away from the interfaces they share, which means the cheap-to-change boundaries end up inside teams and the expensive-to-change boundaries end up between them.

The second is ownership. Code that one team owns gets refactored, documented, and kept current, because someone is accountable for it. Code that spans two teams belongs to nobody, so it drifts. Over a year, the well-owned parts become clean modules and the shared parts become the integration layer everyone is afraid of.

The third is Conway's own point about copies. When a team splits into two, the code they were jointly maintaining tends to split with them, along the line where the people separated. When two teams merge, their services start to fuse. The system is not tracking the domain. It is tracking the people.

Put the three together and the outcome is not a tendency, it is close to a law:

None of these are failures of engineering skill. They are the predictable shadow of the reporting lines, cast onto the code.

Conway's law examples

The cleanest historical example is the one Conway's contemporaries loved to quote: a project staffed with four teams to build a compiler shipped a four-pass compiler. The number of passes matched the number of teams, not the requirements of the language. Whether or not that specific story is apocryphal, every engineer who has worked at scale has their own version of it.

Here are the ones that recur, and the shape each leaves behind.

The pattern in every row is the same: the architecture is legible only once you overlay the org chart. Read the code alone and the boundaries look arbitrary. Read the code with the reporting lines drawn on top and every seam has a reason.

The inverse Conway maneuver: design teams to get the architecture you want

Because the law is symmetrical, you can run it in reverse. Instead of accepting whatever architecture your current org produces, you decide on the architecture you want first, then reshape the teams so their communication structure matches it. Skelton and Pais named this the "inverse Conway maneuver" in Team Topologies, and it is the single most practical thing to take from all of this.

The move looks like this. You want three loosely coupled services with clean interfaces. Conway's law says you will only get and keep that shape if you have three loosely coupled teams with clean interfaces of their own. So you organize the teams first: give each one clear ownership of one service, minimize the standing coordination they need with the others, and make the interfaces between teams explicit and stable. The architecture then grows into the shape you set up, because the cheap-communication boundaries now sit where you want the module boundaries.

A few rules make the maneuver work in practice rather than on a slide.

• Draw the target architecture before you draw the org. If you cannot describe the system boundaries you want, you cannot align teams to them, and you will get whatever the current chart produces by default. This is the same discipline as writing the design down before you build; a short design document that names the intended boundaries gives the reorg something to aim at.
• Give each team a boundary it can own end to end. A team that owns a service but depends on another team for its database or its deploy has not been given a real boundary; it has been given a coordination tax.
• Make the between-team interfaces explicit and few. Every standing cross-team dependency is a place the architecture will fuse. Fewer, sharper interfaces between teams produce fewer, sharper interfaces in the code.
• Write the architectural intent down where it will be found. The reasoning behind a boundary is exactly the kind of decision that evaporates once the person who made it moves on. Capturing it in an architecture decision record is what lets the next reorg preserve the boundary on purpose instead of erasing it by accident.

How to spot Conway's law in your own system

You do not need a consultant to find Conway's law in your codebase. You need to lay two diagrams side by side and look for where they line up. Run through this checklist.

• Overlay the org chart on the architecture diagram. If the boundaries match, Conway's law is already running your design. That is not automatically bad, but it should be a choice, not a surprise.
• Find the components nobody owns. The service that sits between two teams, that both blame and neither refactors, is a Conway boundary that fell on a communication gap. It will keep rotting until one team clearly owns it. These seams are also where a system surprises its users most, because an interface built by two teams that never synced astonishes anyone who assumed one mind was behind it, which is where a surprise becomes a defect worth fixing.
• Watch what happens after a reorg. If a team split last quarter and a once-clean module has started growing a seam down the middle, that is the law acting in real time. Name it before the seam hardens.
• Look for interfaces that are more rigid than the domain requires. An over-negotiated, change-averse API between two components usually marks a place where two orgs, not two domains, had to agree.
• Ask why each boundary exists. For every major seam in the system, someone should be able to say whether it is there because the domain wanted it or because the org chart put it there. If the answer for most seams is "the org chart," your architecture is a byproduct, not a design.

The goal of the audit is not to eliminate Conway's law, which is impossible, but to make it deliberate. Every boundary should be one you would choose again.

The part nobody documents: org charts change, architectures don't

Here is the failure mode that outlives every reorg. Conway's law is usually taught as a snapshot: your current org produces your current architecture. But orgs are not snapshots. Teams split, merge, get renamed, and get re-staffed every few quarters. The architecture they produced does not move with them. It freezes the communication structure that existed on the day it was built, and then that structure changes underneath it.

So a year after a reorg you have a system whose boundaries encode an org chart that no longer exists. The service split that made sense when two teams owned two halves now cuts straight through the one team that inherited both. And the documentation that explained who owns what, why the boundary is there, and which team to call when it breaks, is describing a company that has been reorganized twice since. The org chart in the wiki is wrong. The ownership table in the README points at a team that was dissolved. The architecture diagram still shows the old seams, so the new engineer trusts it, and gets lost.

This is the same rot that hits every kind of engineering knowledge, and it hits Conway's-law boundaries hardest because they were never written down as decisions in the first place; they just happened. The fix is to treat the reasoning behind each boundary as something that has to be maintained, not captured once and abandoned. Scribelet is built for exactly this problem. Its background agents re-check your notes and docs against reality on a schedule and show you a diff when something no longer holds, so the ownership map and the architectural why stay current instead of quietly describing a team that no longer exists. A boundary you can no longer explain is a boundary you can no longer safely change, which is Chesterton's fence showing up at the architecture level instead of the code level, and internal documentation that has gone stale is worse than none, because people still trust it. When knowledge concentrates in the few people who remember the original org, you also have a bus factor problem sitting on top of your Conway's-law one.

Getting started

Conway's law is not a problem to solve; it is a force to aim. Start with one diagram: overlay your current org chart on your current architecture and mark every boundary that exists because of the reporting lines rather than the domain. That single audit tells you which of your seams are chosen and which are accidents. From there, either accept each boundary on purpose or, where it matters enough, use the inverse maneuver to move the teams so the architecture follows. And let the shape grow rather than legislating it whole from day one, because a working complex system is almost always one that evolved from a simple system that worked, not one drawn complete on a whiteboard before any code ran.

The part that lasts is keeping the reasoning alive. Write down why each boundary is there, and keep those notes true as the org changes around them. Try Scribelet free and let it watch your architecture notes for the day the org chart moves and the docs do not. Your system will always mirror your org. The only question is whether you can still read the mirror a year from now.