Conway's Law names a real coupling problem

Melvin Conway did not set out to mint a Twitter law. In a 1968 Datamation article he traced how design committees behave and what that does to the artifact they produce.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

That wording is how practitioners quote the idea today. Fred Brooks later gave it the name Conway’s Law in The Mythical Man-Month. The underlying argument lives in Conway’s original piece, How Do Committees Invent?, which Datamation published in April 1968 and which Conway still hosts alongside a scan of the PDF.

Conway models both the product and the design organization as graphs. Subsystems are nodes. Dependencies are branches. He shows that when subsystems are assigned to separate groups, those groups must negotiate interfaces where the product graph has edges. When the org chart lacks a communication path, the corresponding product coupling is hard to sustain. In the tidy case where each subsystem has its own team, the two graphs can line up so closely that the relationship is almost an identity. In messier real orgs the mapping is a homomorphism, but the direction of influence is the same. The organization does not get to be a neutral observer.

The practical upshot is boring and expensive. Draw boundaries on a whiteboard that do not match who talks to whom and you still get boundaries. They just show up as brittle integration layers, duplicated state, slow reviews, and tickets that bounce between teams. Martin Fowler’s note on Conway’s Law stays relevant because it treats the law as a design input, not a punch line. You either accept the coupling between org communication and system structure or you spend the project fighting it.

Make the match intentional. Small groups with rich informal communication tend to ship cohesive surfaces. When you split work across locations, time zones, or competing silos, assume interfaces will be thicker and interactions fewer. That is not a moral failure. It is a prediction about where transaction costs land.

Some teams run an inverse Conway maneuver on purpose. They change team boundaries and ownership to pull the architecture they want within reach. That only works when you treat org moves as seriously as schema changes. Re-slicing teams without changing incentives, backlogs, and measures of success relocates the friction without removing it.

Conway also warns that large design efforts overstaff early, communication structures rot under conventional management pressure, and the product graph mirrors that decay. That rhymes with Brooks’ law on rescue staffing and with Dunbar’s number when informal repair stops scaling. The honest move is to keep both graphs in view. When the system needs to evolve, ask whether the communication paths can support the new shape, and when the org changes, ask what boundary violations you just introduced in the code.

Start from Conway’s paper when you want the argument in full. Use Fowler when you want a compact practitioner’s read on why it still shapes delivery. Then compare your last architecture diagram with your roster and see whether they tell the same story.