Conway's Law
"Organizations design systems that mirror their own communication structure."
Your architecture will always reflect how your teams are organized. To change the system, first change the org.
The Original Insight
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Melvin Conway, 1967
Conway observed that system interfaces will match team interfaces. If three groups build a compiler, you get a three-pass compiler. If frontend and backend teams don't talk, their systems won't integrate well.
The Mirror Effect
Org Structure
- Teams that communicate well → Clean interfaces
- Siloed teams → Tightly coupled, awkward integrations
- Political conflict → Technical conflict surfaces
- Remote/distributed → Distributed architecture needed
System Architecture
- Module boundaries = team boundaries
- API contracts reflect team relationships
- Code complexity mirrors org complexity
- Deployment pain = coordination overhead
The Inverse Conway Maneuver
ADVANCEDInstead of letting org structure dictate architecture, design your org to produce the architecture you want. Want microservices? Create small, autonomous teams first.
How to Apply
- • Define desired architecture first
- • Structure teams to match that architecture
- • Team boundaries = service boundaries
- • Communication paths = integration points
Examples
- • Spotify's Squads/Tribes model
- • Amazon's two-pizza teams
- • Netflix's "Freedom & Responsibility"
- • Google's small project teams
The Reorg Fallacy
You cannot reorg your way to a new architecture overnight. Conway's Law describes an emergent force, not a switch you flip. Architecture changes require sustained org change + technical investment.