Conway's Law
Organizations design systems that mirror their communication structure.
Tiny Summary
Conway's Law: "Organizations design systems that mirror their communication structure." Your architecture will reflect your org chart, whether you like it or not.
The Law
"Organizations produce designs whose structure is a copy of the organization's communication structure." — Melvin Conway, 1967
Examples
Microservices: Many small, autonomous teams → Microservices architecture (one service per team)
Monoliths: One centralized engineering team → Monolithic architecture
Frontend/Backend split: Separate teams → API-based architecture with clear separation
Silos: Teams don't talk → Duplicate code, incompatible systems
Why It Happens
Teams design what they can control. Can't coordinate across teams → Build separate systems. Interfaces reflect org boundaries: Team A + Team B → API between them. Same team → Direct function calls. Incentives measured by team output → System boundaries follow team boundaries.
Inverse Conway Maneuver
Want microservices? Create small, independent teams first. Want unified system? Merge teams before building. Architecture follows org structure, so fix org structure first.
Real Impact
Amazon: Two-pizza teams → Service-oriented architecture (became AWS)
Spotify: Squad/tribe/chapter model → Loosely coupled, autonomous services
Traditional enterprise: Large siloed departments → Monolithic, tightly coupled systems
Key Insights
You can't fight Conway's Law. Want different architecture? Change the org chart. Communication patterns dictate system design. Microservices require organizational changes, not just technical ones.