Conway's Law

Some problems keep recurring in the same place with no explanation anyone can point to. Bugs appear only where payments and notifications meet, a new owner takes over, and something similar breaks again the following quarter. Explanations built on code quality or individual skill run out fast, because three different people have now passed through that spot and the symptom hasn't moved.

Pagedeck carried a failed-payment notification delay for more than a year. One team owned payments, another owned notifications. Both kept their own code in good shape, and the part that joined them belonged to neither. While writing up the causes, Theo noticed that the place where the system came apart sat exactly on the line where the teams came apart.

Melvin Conway published the same observation in 1967: organizations that design systems produce designs that copy their own communication structure. The sentence is useful because it moves the cause from people to structure, which is the one place a team can actually change. Instead of asking who made the mistake, it makes you ask where the boundaries were drawn.

Two parts can only interlock if the people who own them work out the details together, and wherever working out details is hard, a design boundary forms. The pattern hardens in three steps.

1. Communication costs differ by distance. Agreeing with the person at the next desk takes thirty seconds. Agreeing with another team means booking a meeting and lining up calendars, so the same conversation costs days once it crosses a team line. Nobody decides to avoid that cost; it just gets avoided.
2. Designs only emerge inside what people can coordinate on. People who talk daily can weave their code together and still ship. With a team you rarely talk to, you choose something that removes the need for constant coordination — a fixed contract such as an API, the agreed window through which two programs exchange information, with nobody looking past it.
3. What's left resembles the org chart. Four teams produce roughly four blocks, and the further apart two teams sit, the thinner and more fragile the connection between their parts. The seams land where the conversations were hardest to have.

One practical conclusion falls out of that. If you know the system structure you want, shape the organization that way first. Wanting services that deploy independently while a single team owns all of them blurs the boundaries; splitting the teams first makes the boundaries sharpen on their own. That approach is called the inverse Conway maneuver.

Read backwards, it becomes a diagnostic. An unexplained seam in the system usually marks where an old org chart used to be. The boundary between two teams that merged two years ago often survives untouched in the code, and when a new hire asks why those two things are separate and nobody can give a technical reason, the answer is in the old reporting lines.

It gets cited most often in debates about restructuring. Any proposal to move to microservices draws it out. That structure — splitting by capability and deploying each piece separately — holds together only when teams are split the same way and each owns its piece. Slice the code into ten parts while leaving the organization intact and you get ten deployments feeding decisions that still happen in one meeting. The operational cost arrives immediately and the independence never does.

Changes to organizational structure carry the same weight. Reorganizing from functional groups into product-aligned cross-functional teams gradually pulls the system in that direction too. A reorg is a technical decision, and the meeting that sets reporting lines is also setting which seams the system will have in six months. Few reorg memos are read that way at the time.

It works for diagnosis as well. When schedules slip at the same point every time, the cause may sit in the line drawn through the organization rather than in anyone's ability. If two teams repeatedly wait on each other and produce the same blocker, the fix isn't replacing a person — it's merging the two capabilities into one team or putting an agreed contract between them, with one person named as its owner.

"Move to microservices with this org and all we get is a distributed monolith."

Warning that code split across services still behaves as one system when the teams stay merged, which costs more to run than what it replaced.

"That's Conway's law. That seam is where the old team boundary was."

Explaining that a design that looks technically strange is a trace of the organization.

"This reorg is an architecture decision too."

The lines drawn between teams become the boundaries in the system later.

Pagedeck solved its notification problem from this angle. Rather than swapping owners, Theo and Mia chose between two options: merge payments and notifications into one team, or define a contract between them and write down which side owns what.

They took the second. The two domains were too different to sit in one team. Instead they fixed the format and timing of everything payments hands to notifications, and named a single owner for that contract. Six months later, failures of that kind had stopped appearing. The code that changed was small; what actually changed was who had to talk to whom before shipping.

Many people read the law as a promise that changing the organization changes the code. It links structure to structure, so turning the org handle looks like it should move the other end. What the observation actually says is that designs produced from here on will resemble today's communication structure — not that code already written rearranges itself. Split the teams without scheduling the work of moving the code, and three new teams go on editing the same block while conflicts multiply. The reorg then gets blamed for a slowdown it only half caused.

The word "law" also invites reading it as a rule without exceptions. What Conway offered is a long-observed tendency, not a proven formula. Teams do push against it deliberately. Pushing back means paying real costs for communication across team lines — two teams sitting down weekly to align on design, for instance — and the structure drifts back toward the org chart as soon as that effort stops. Much as Brooks's law blocks the instinct to add people to a late project, this one marks a lever that isn't worth pulling.