Skip to main content

Conway's Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." In simpler terms: your software architecture will mirror your organizational structure. This observation by Melvin Conway in 1967 has profound implications for how teams are structured and how systems are designed.

Key Concepts​

  • Communication shapes architecture: The way teams communicate directly influences how software components interact and are structured
  • Team boundaries create system boundaries: Organizational silos and team divisions will manifest as technical boundaries in the system
  • Reverse Conway Maneuver: Intentionally structure teams to match the desired architecture, rather than letting org structure dictate architecture
  • Coordination cost: Systems requiring cross-team communication become coupling points; minimize these to reduce coordination overhead
  • Microservices alignment: Conway's Law explains why microservices work best when each service is owned by a single, autonomous team

Diagram​

Conway's Law in Action:

Traditional Organization:              Resulting Architecture:
┌──────────────────────────┐          ┌──────────────────────────┐
│   Frontend Team          │          │   Frontend Layer         │
│   (5 developers)         │────────► │   (Monolithic UI)        │
└──────────────────────────┘          └──────────────────────────┘
                                                  │
                                                  ▼
┌──────────────────────────┐          ┌──────────────────────────┐
│   Backend Team           │          │   Backend Layer          │
│   (8 developers)         │────────► │   (Monolithic API)       │
└──────────────────────────┘          └──────────────────────────┘
                                                  │
                                                  ▼
┌──────────────────────────┐          ┌──────────────────────────┐
│   Database Team          │          │   Database Layer         │
│   (3 developers)         │────────► │   (Centralized DB)       │
└──────────────────────────┘          └──────────────────────────┘


Microservices Organization:           Resulting Architecture:
┌──────────────────────────┐          ┌──────────────────────────┐
│  User Service Team       │          │    User Service          │
│  (Full-stack)            │────────► │    (API + DB + UI)       │
└──────────────────────────┘          └──────────────────────────┘

┌──────────────────────────┐          ┌──────────────────────────┐
│  Payment Service Team    │          │    Payment Service       │
│  (Full-stack)            │────────► │    (API + DB + UI)       │
└──────────────────────────┘          └──────────────────────────┘

┌──────────────────────────┐          ┌──────────────────────────┐
│  Order Service Team      │          │    Order Service         │
│  (Full-stack)            │────────► │    (API + DB + UI)       │
└──────────────────────────┘          └──────────────────────────┘


Inverse Conway Maneuver:
                Design Target Architecture First
                             │
                             ▼
                ┌────────────────────────┐
                │  Desired Architecture  │
                │   (Microservices)      │
                └────────────────────────┘
                             │
                             ▼
                Structure Teams to Match
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
        ┌─────────┐    ┌─────────┐    ┌─────────┐
        │ Team A  │    │ Team B  │    │ Team C  │
        │Service A│    │Service B│    │Service C│
        └─────────┘    └─────────┘    └─────────┘

Key Takeaways​

  • When to apply: Consider Conway's Law when designing architecture or restructuring teams; align both intentionally
  • Reverse Conway Maneuver: Design your ideal architecture first, then structure teams to match it
  • Team autonomy: Reduce dependencies between teams to reduce coupling in the system; enable independent deployment
  • Communication overhead: More teams communicating = more integration points = more complexity
  • Microservices fit: Conway's Law explains why microservices succeed with cross-functional teams owning entire services
  • Common pitfall: Ignoring Conway's Law leads to architectures that fight organizational structure, causing friction
  • Warning sign: If teams constantly wait for other teams, your architecture doesn't match your organization
  • Pro tip: Use Conway's Law proactively—restructure teams to achieve architectural goals
  • Remember: You can't fight Conway's Law; embrace it by aligning org structure with desired architecture
  • Domain-Driven Design: Bounded contexts naturally align with team boundaries and Conway's Law
  • Microservices Architecture: Success depends on team autonomy, which Conway's Law directly addresses
  • Team Topologies: Modern framework for organizing teams based on Conway's Law principles
  • API Design: Team boundaries become API boundaries; design APIs with organizational structure in mind