In 1967 a programmer named Melvin Conway noticed something that still governs software today: any organization that designs a system produces a design whose structure copies the organization's communication structure. Put plainly, your software ends up shaped like your org chart. For decades that was folklore. Then a Harvard team tested it with data and found it holds.
Key Takeaways
- Conway's Law: systems mirror the communication structure of the org that builds them (Conway).
- A Harvard study (MacCormack et al.) tested the "mirroring hypothesis" and found strong support: loosely-coupled orgs produced more modular products; tightly-coupled orgs produced tightly-coupled ones (Harvard).
- Your team boundaries quietly become your system boundaries.
- Design the org for the architecture you want, the "inverse Conway maneuver."
What Conway Actually Said
Melvin Conway's 1967 observation has proven durable: the structure of a system reflects the structure of the human organization that produced it, because the design mirrors how those people communicate (Conway's Law). Three teams building a compiler tend to produce a three-pass compiler. Two services owned by two teams that rarely talk will have an awkward interface between them, because the conversation that would have smoothed it never happened.
For years this was treated as a witty aphorism. The evidence changed that. MacCormack, Rusnak, and Baldwin at Harvard studied matched pairs of products, some built by tightly-coupled organizations (a single co-located company) and some by loosely-coupled ones (distributed open-source communities), and measured how modular each product's code was. In every pair, the product from the loosely-coupled org was significantly more modular (Harvard mirroring study). The organization's shape had pressed itself into the code.
Why It Happens
The mechanism is communication. Two engineers on the same team talk constantly, so the code they own grows tightly interwoven; they can coordinate a change across both halves in a hallway conversation. Two engineers on different teams in different time zones coordinate through tickets and scheduled calls, so they build a clean, documented boundary between their parts, because a messy one would be painful to maintain across that distance. The system's seams form wherever the communication is thin.
| Organization | Tends to produce |
|---|---|
| Tightly-coupled, co-located | Tightly-coupled code |
| Loosely-coupled, distributed | Modular code, clean interfaces |
| One team owning everything | A monolith |
| Many independent teams | Many services |
A Concrete Version
A startup wants a clean, modular API, but it has one big team where everyone touches everything and coordinates in a group chat. Predictably, the API comes out tangled, because the team's own everyone-talks-to-everyone structure got stamped into it. Later the company splits into a payments team and a core team with a clear interface between them. Within a quarter, the payments code has a clean, documented boundary. The two teams have to coordinate through an interface now, so they built a good one, and the architecture quietly followed the org.
Using It on Purpose
Once you accept that org shape drives architecture, you can run it forward. Teams that want a modular, service-oriented system organize into small, loosely-coupled teams that own clear slices, and the modular architecture tends to follow. Teams that want a simple monolith keep a single tight team. This is the "inverse Conway maneuver": design the team structure to produce the architecture you're after. It pairs directly with the team-size research and the way Team Topologies organizes teams around clean boundaries.
What This Means for Hiring and Structure
Conway's Law makes team design a first-class engineering decision, with a practical implication for how you add people. Where you place a new engineer, and which boundary they own, shapes the code they'll produce. A senior engineer given clear ownership of a well-bounded domain will build a clean interface around it; the same engineer scattered across everyone's code will produce tangle. That's part of why we push for real domain ownership on the teams we staff. See available engineers.
Frequently Asked Questions
What is Conway's Law?
Melvin Conway's 1967 observation that a system's structure mirrors the communication structure of the organization that builds it. In practice, your software ends up shaped like your org chart.
Is Conway's Law actually true?
A Harvard study by MacCormack and colleagues tested it and found strong support: products built by loosely-coupled organizations were significantly more modular than those built by tightly-coupled ones.
What is the inverse Conway maneuver?
Deliberately designing your team structure to produce the architecture you want. For modular services, organize small loosely-coupled teams around clear domains, and the architecture tends to follow.
How does Conway's Law affect team design?
It makes team boundaries a de facto architecture decision. The seams in your system form where communication between teams is thin, so where you draw team lines is where you draw system lines.
The Bottom Line
Software takes the shape of the organization that builds it, and a Harvard study confirmed the folklore with data. That makes your org chart an architecture diagram whether you meant it to be or not. Draw your team boundaries deliberately, put clear ownership around clean domains, and let the architecture you want follow the structure you built.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
