Skip to content

Conway's Law

"Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations."

Conway's Law states that organizations design systems that mirror their communication structure. Named after computer programmer Melvin Conway, this principle reveals how company organization directly influences the architecture of products and services they create.

The Original Statement

Conway observed in 1967 that:

  • A compiler team with 4 groups will produce a 4-pass compiler

  • A team with poor internal communication will build poorly integrated systems

  • System interfaces reflect the boundaries between teams that built them

How It Works

Communication Constraints

  • Teams can only coordinate as well as they communicate

  • Information flows more easily within teams than between teams

  • System boundaries naturally form where communication boundaries exist

Design Reflection

  • Product architecture mirrors organizational chart

  • Integration points reflect collaboration patterns

  • System complexity matches organizational complexity

Feedback Loop

  • Existing systems influence future organizational decisions

  • Teams form around system components they maintain

  • Architecture decisions affect team structure going forward

Business Examples

Software Architecture

Microservices vs Monoliths:

  • Small, autonomous teams → Microservices architecture

  • Large, integrated teams → Monolithic architecture

  • Siloed departments → Poorly integrated systems

Enterprise Software:

  • Sales, Marketing, Support teams → CRM with separate modules

  • Cross-functional teams → Integrated platforms

  • Geographic divisions → Regionally-customized systems

Product Development

Automotive Industry:

  • Engine team, Body team, Electronics team → Cars with clear subsystem boundaries

  • Integrated design teams → More seamless vehicle integration

  • Supplier relationships → Component interfaces that reflect vendor boundaries

Consumer Electronics:

  • Hardware team, Software team → Products where hardware/software integration suffers

  • Cross-functional pods → More cohesive user experiences

  • Platform teams → Shared components across product lines

Service Delivery

Customer Support:

  • Separate phone, email, chat teams → Customers repeat information across channels

  • Omnichannel teams → Seamless customer experience

  • Product-specific support → Customers transferred between specialists

Consulting Services:

  • Practice-based organization → Solutions that reflect consulting firm's expertise areas

  • Client-focused teams → More integrated, customized solutions

  • Geographic offices → Regional variations in service delivery

Strategic Implications

Organizational Design

Designing for desired outcomes:

  • Want integrated products? Create cross-functional teams

  • Want platform reuse? Create shared service teams

  • Want rapid innovation? Create autonomous product teams

Merger and Acquisition

Post-merger integration challenges:

  • Two companies with different structures create incompatible systems

  • Integration success depends on organizational integration

  • Cultural alignment affects technical integration

Digital Transformation

Technology change requires organizational change:

  • New architectures need new team structures

  • Legacy organizations struggle with modern architectures

  • DevOps requires breaking down traditional IT/Development silos

Practical Applications

Team Structure Design

Traditional Functional Structure:

  • Marketing, Sales, Engineering, Support teams

  • Resulting systems: Hand-offs between functional silos

  • Customer experience: Disjointed, departmental

Cross-Functional Product Teams:

  • Teams containing all skills needed for product success

  • Resulting systems: Integrated, end-to-end solutions

  • Customer experience: Seamless, product-focused

Communication Architecture

Hierarchical Communication:

  • Information flows up and down management chain

  • Resulting systems: Centralized architectures with bottlenecks

  • Characteristics: Slow decision-making, consistency

Network Communication:

  • Direct communication between any teams that need to collaborate

  • Resulting systems: Distributed architectures with peer-to-peer interfaces

  • Characteristics: Fast adaptation, potential inconsistency

Technology Platform Strategy

Centralized Platform Team:

  • Single team builds shared infrastructure

  • Result: Consistent, reusable platforms

  • Risk: May not meet specific product needs

Embedded Platform Engineers:

  • Platform specialists within each product team

  • Result: Customized solutions for each product

  • Risk: Duplication and inconsistency

Reverse Conway Maneuver

Designing Organization for Desired Architecture

Instead of letting current structure dictate architecture, deliberately restructure teams to create desired systems.

Steps:

  1. Define target architecture: What system design do you want?

  2. Map required communication: What teams need to collaborate closely?

  3. Restructure organization: Align team boundaries with desired system boundaries

  4. Implement new communication patterns: Create channels that support target architecture

Example: Moving to microservices

  • Create small, autonomous product teams

  • Give each team ownership of specific business capabilities

  • Reduce dependencies between teams

  • Result: System naturally evolves toward microservices

Common Patterns

The Database Team Anti-Pattern

Structure: Separate team owns all database access

Result: Applications with poor data integration, bottlenecks

Solution: Distribute database ownership to product teams

The UI/Backend Split

Structure: Frontend team separate from backend team

Result: Poor user experience, API designed for backend convenience

Solution: Full-stack product teams

The Platform Team Pattern

Structure: Platform team serves multiple product teams

Result: Reusable infrastructure, consistent user experience

Key: Platform team must treat product teams as customers

Measurement and Indicators

Communication Patterns

  • Frequency of cross-team meetings

  • Number of integration points between systems

  • Time to resolve cross-team issues

  • Knowledge sharing patterns

System Characteristics

  • Number of system interfaces

  • Integration complexity

  • Code coupling between team boundaries

  • Deployment dependencies

Business Outcomes

  • Time to market for new features

  • Customer experience consistency

  • Development velocity

  • System reliability

Challenges and Solutions

Large Organization Complexity

Challenge: Complex org charts lead to complex systems

Solutions:

  • Simplify organizational structure

  • Create clear team interfaces

  • Invest in communication tooling

  • Regular organizational refactoring

Legacy Systems and Teams

Challenge: Existing systems constrain organizational change

Solutions:

  • Gradual migration strategies

  • Temporary bridge teams

  • Explicit interface management

  • Plan for technical debt retirement

Scaling Challenges

Challenge: Team structures that work at small scale break at large scale

Solutions:

  • Dunbar number awareness (teams of ~150 people max)

  • Hierarchical team structures

  • Clear escalation paths

  • Consistent tooling and practices

Dunbar's Number

Cognitive limit of stable social relationships affects team size and communication patterns.

Brooks's Law

Adding people to late projects makes them later - relates to communication overhead.

The Inverse Conway Maneuver

Deliberately designing team structure to achieve desired system architecture.

Bounded Context (Domain-Driven Design)

Aligning team boundaries with business domain boundaries to improve system design.

Questions for Application

When designing or reorganizing:

  1. What system architecture do we want? Start with desired end state

  2. What communication patterns does this require? Map necessary collaboration

  3. How should teams be structured? Align team boundaries with system boundaries

  4. What are the communication costs? Consider overhead of coordination

  5. How will we measure success? Define metrics for both organizational and system health

Key Insight

Conway's Law isn't just an observation - it's a design tool. Understanding that organizational structure determines system architecture means we can deliberately design organizations to create the systems we want. The most successful companies actively use this principle, structuring teams to deliver their desired customer experience rather than optimizing for internal convenience. The law reminds us that technology problems are often organizational problems in disguise.