Conway's Law

A system's seams don't come from a design meeting. They come from wherever two people who don't talk much had to agree on an interface anyway.

September 11, 2026 7 min read

Three engineers each own one service in a pipeline, and the API connecting them ends up with three different ways to represent the same customer record, one field per service, none of them reconciled. Nobody sat down and decided the system should represent a customer three inconsistent ways. Each engineer built the version that made sense from inside their own service, and the seam between services is exactly where three people who didn't talk much every day had to agree on something anyway. The inconsistency isn't a bug in the code. It's a shadow cast by the org chart.

A system's seams trace back to who had to negotiate with whom

A system built by more than one person always has internal boundaries, places where one part hands off to another. Those boundaries don't get drawn by the requirements alone. They get drawn wherever two people, or two teams, actually had to coordinate to make the handoff work, and coordination has a cost that's paid in meetings, messages, and shared context that has to exist before an interface can. Two engineers who sit next to each other and talk all day will converge on an interface almost without noticing. Two teams that only sync in a weekly meeting will produce an interface with exactly the amount of agreement that weekly meeting could produce, and not a bit more.

That's why the same technical requirement, given to different organizations, tends to come out looking different. It isn't that one team is more skilled. It's that the actual constraint shaping the design was never only the requirement. It was also which people could talk to which other people, cheaply and often enough, to actually resolve a disagreement instead of just working around it.

Where this gets its name

Software engineering has documented this pattern with more than an anecdote, going back further than most people assume. In April 1968, Melvin Conway published "How Do Committees Invent?" in Datamation, stating the thesis directly: organizations which design systems are constrained to produce designs that are copies of the communication structures of those organizations. His evidence wasn't hypothetical. A contract research organization had eight people assigned to build a COBOL compiler and an ALGOL compiler, five people put on the COBOL job and three on the ALGOL job. The finished COBOL compiler had five processing phases. The finished ALGOL compiler had three. Nobody set out to make the phase count match the headcount. The team split happened first, and the software's own internal structure ended up mirroring it anyway.

Conway's own paper never uses the phrase "Conway's Law." Where the name itself came from isn't fully settled, even between Conway's own account and the record other people kept. Conway's own retrospective note credits Fred Brooks directly: Brooks cited the paper's idea in The Mythical Man-Month (1975) and called it "Conway's Law," and by Conway's own telling, that name simply stuck. Other accounts trace the name earlier, to attendees at the 1968 National Symposium on Modular Programming, the same year Conway's paper came out, who are said to have found the pattern serious and common enough to start calling it "Conway's Law" on the spot, years before Brooks's book existed. Neither account has a contemporaneous record settling it, and the two don't agree with each other. What isn't in dispute either way: the observation and the evidence belong to Conway, and whichever account of the name is right, Brooks's 1975 citation is what carried it far beyond a 1968 trade-magazine article and into general use.

The honest limit: this describes a tendency, not an iron rule

This isn't a claim that org structure is destiny, or that a system can never be shaped differently than the chart that produced it. Conway's own conclusion is careful on this point: he frames it as a constraint design organizations tend to be subject to, driven by communication cost, not a law of physics nobody can work around. Deliberately restructuring who talks to whom, or building in extra coordination specifically at a seam that matters, can produce an interface cleaner than the org chart alone would predict. The pattern isn't inevitable. It's what happens by default when nobody's paying attention to the coordination cost that's quietly doing the actual design work.

It's also not a claim that every design flaw traces to an org chart. Some ugly interfaces are just bad engineering, unrelated to who talked to whom. What the pattern actually predicts is narrower and more specific: where a system boundary sits, and how much friction shows up at that boundary, tends to track the communication boundary between whoever built the two sides, whether or not either team meant for that to happen.

Where this fits at Brief

This is the shape of the problem sitting underneath why a product context layer matters for teams building with more autonomous parts, whether that's engineering teams or increasingly independent AI agents doing pieces of the work. This post can't speak to Brief's own internal engineering org or agent architecture specifically. What Conway's finding says in general is that wherever coordination is expensive or thin, whoever is on either side of that gap, the resulting interface tends to carry the marks of that gap whether anyone intended it or not.

Look at the messiest seam in a system your team owns. Is it messy because the problem itself was hard there, or because that's exactly the boundary where two people who don't talk much every day had to agree on something anyway?

Frequently asked questions

What is Conway's Law? The observation that a system built by an organization tends to end up structured like the communication pattern of that organization, not necessarily like the cleanest possible design for the problem. Interfaces and seams in the system tend to appear at the same places where teams or people had to coordinate, because that coordination is costly and imperfect.

Where does the name come from? Melvin Conway published the original finding and evidence in his 1968 paper "How Do Committees Invent?" Who actually gave it the name "Conway's Law," and when, isn't fully settled. Conway's own account credits Fred Brooks, who used the name in his 1975 book The Mythical Man-Month. Other accounts trace the name earlier, to attendees at the 1968 National Symposium on Modular Programming, the same year Conway's paper was published. The two accounts disagree, and no contemporaneous record settles it either way. What's certain is that Brooks's 1975 citation is what carried the name into wide use, whether or not it's also where the name started.

What was Conway's actual evidence? A concrete case from his paper: a contract research organization split eight people into a five-person team building a COBOL compiler and a three-person team building an ALGOL compiler. The finished COBOL compiler had five processing phases and the ALGOL compiler had three, matching the team sizes without anyone designing it that way.

Does this mean bad org design always produces bad software? No. Conway frames it as a tendency driven by communication cost, not an unavoidable law. Deliberately changing who coordinates with whom, or adding extra coordination specifically where a seam matters, can produce a cleaner result than the org chart alone would predict. It also doesn't mean every flawed interface traces back to team structure. Some are just engineering mistakes with nothing to do with who talked to whom.