Conway's Law
Introduction#
In 1968, computer programmer Melvin Conway submitted a paper to the Harvard Business Review titled “How Do Committees Invent?” The paper was initially rejected but later published elsewhere, introducing what would become known as Conway’s Law. This principle has proven remarkably prescient in explaining why software systems often mirror the organizational structure of the companies that build them.
The Law Defined#
Conway’s Law states:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
In simpler terms: Your software architecture will reflect your team structure. If you have four teams working on a compiler, you will end up with a four-pass compiler. If you have separate frontend and backend teams, you’ll likely end up with a system that clearly separates frontend and backend concerns.
Conway later refined this observation in his original 1968 paper, explaining that this isn’t just correlation—it’s a natural consequence of how communication flows within organizations.
Why Conway’s Law Occurs#
The mechanism behind Conway’s Law is rooted in communication patterns and coordination costs. As documented in Fred Brooks’ “The Mythical Man-Month”, the complexity of communication grows exponentially with team size, following the formula for communication channels:
n(n-1)/2
Where n is the number of people on the team. This growth pattern becomes dramatic quickly:
Team Size | Communication Channels 2 people | 1 channel 3 people | 3 channels 5 people | 10 channels 8 people | 28 channels 10 people | 45 channels 15 people | 105 channels
Three key factors drive this phenomenon:
1. Communication Boundaries#
Teams communicate most frequently within their boundaries and less frequently across boundaries. System interfaces naturally form where communication is weakest, creating architectural boundaries that mirror organizational ones.
2. Knowledge Distribution#
Each team develops deep expertise in their domain. This specialized knowledge becomes encoded in the systems they build, reinforcing the organizational divisions through technical implementations.
3. Coordination Costs#
Cross-team coordination requires more time and effort than intra-team coordination. Systems naturally evolve to minimize these coordination costs, resulting in architectures that reduce cross-team dependencies.
Real-World Evidence#
Research consistently validates Conway’s Law across different contexts:
Microsoft Windows Study#
A 2008 study by Nagappan, Murphy, and Basili at Microsoft Research found a strong correlation between organizational structure and software failures. Components built by more distributed teams had higher failure rates, while components built by tightly integrated teams had better quality metrics.
Open Source Analysis#
Research by MacCormack, Rusnak, and Baldwin (2006) comparing Linux and Mozilla architectures found that their modular structures directly reflected the distributed nature of their development communities, providing clear evidence of Conway’s Law in action.
Note: For software teams, organizational structure means how teams are divided, how they communicate, and where reporting boundaries exist. These patterns inevitably appear in the software architecture.
Practical Implications#
Understanding Conway’s Law enables strategic organizational design:
1. Microservices and Team Structure#
The rise of microservices architecture aligns perfectly with Conway’s Law. As documented in Martin Fowler’s influential microservices article, successful microservices implementations typically feature small, autonomous teams owning individual services. The service boundaries mirror team boundaries.
2. API Design Patterns#
Teams that communicate frequently create tightly coupled APIs. Teams that communicate rarely create loosely coupled interfaces. This explains why internal APIs often become messy while external APIs remain clean—internal teams over-communicate, external teams under-communicate.
3. System Integration Challenges#
Integration problems often reflect organizational problems. When systems don’t integrate well, look for communication breakdowns between the teams that built them. Technical solutions alone rarely fix organizational communication issues.
The Inverse Conway Maneuver#
Conway’s Law works in reverse: you can influence system architecture by deliberately designing organizational structure. This approach, termed the “Inverse Conway Maneuver” by ThoughtWorks, involves organizing teams to match your desired architecture.
Examples of successful application:
- Amazon’s Two-Pizza Teams: Small, autonomous teams that own entire services, resulting in a service-oriented architecture
- Spotify’s Squad Model: Cross-functional teams aligned with product features, creating feature-based architectural boundaries
- Netflix’s Full-Stack Teams: Teams responsible for entire customer journeys, leading to end-to-end service ownership
Common Antipatterns#
The Component Team Trap#
Organizing teams around technical components (frontend team, backend team, database team) creates systems with rigid technical boundaries that don’t align with business value streams. This violates Conway’s Law by forcing business features to span multiple teams.
The Handoff Antipattern#
When teams work in sequence (design → development → testing → deployment), the resulting system reflects these handoffs through rigid phase gates and poor integration points. The architecture becomes a series of disconnected stages rather than a cohesive system.
The Matrix Organization Problem#
Matrix organizations with unclear reporting structures produce systems with unclear architectural boundaries. When team ownership is ambiguous, system ownership becomes ambiguous, leading to technical debt and maintenance problems.
Implications for Engineering Leaders#
Conway’s Law provides a framework for making organizational decisions with architectural consequences:
1. Team Topology Design#
Before designing systems, design teams. Consider what communication patterns you want, then structure teams to encourage those patterns. The book “Team Topologies” by Skelton and Pais provides a comprehensive framework for this approach.
2. Architectural Decision Making#
When evaluating architectural options, consider the organizational implications. Can your current team structure support the proposed architecture? Will the architecture require communication patterns that don’t exist in your organization?
3. System Evolution Planning#
As organizations grow and change, systems will naturally evolve to match. Plan for this evolution by designing flexible organizational structures that can adapt while maintaining desired architectural properties.
Conclusion#
Conway’s Law reveals a fundamental truth about software development: organizational design is system design. The structure of your teams, their communication patterns, and their boundaries will inevitably appear in your software architecture.
This isn’t a constraint to fight—it’s a principle to leverage. Instead of hoping that good architecture will emerge from any organizational structure, deliberately design your organization to produce the architecture you want. As Conway’s original paper demonstrated, the relationship between organization and system design is not accidental but inevitable.
The next time you’re designing a system, ask yourself: What organizational structure would naturally produce this architecture? Then work backward from that answer to design both your teams and your technology for success.