Conway's Law: The Invisible Force Shaping Your Architecture
In 1967, computer scientist Melvin Conway made an observation that holds true to this day:
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Simply put: Your software looks like your org chart.
What Conway's Law Means
The Core Principle
ORGANIZATION:
Team A ←→ Team B ←→ Team C
↓ ↓ ↓
SYSTEM:
Module A ←→ Module B ←→ Module C
Teams communicate → Modules communicate
Teams are isolated → Modules are isolated
Why It Works
COMMUNICATION HAS COST:
Within a team:
- Short paths
- Shared context
- Quick alignment
→ Tight coupling is easy
Between teams:
- Long paths
- Different context
- Expensive alignment
→ Loose coupling is easier
→ PEOPLE TAKE THE PATH OF
LEAST RESISTANCE
→ ARCHITECTURE FOLLOWS COMMUNICATION
Conway's Law in Practice
Example 1: The Monolith
ORGANIZATION:
One large team, everyone works together.
┌─────────────────────┐
│ Development Team │
│ (15 developers) │
└─────────────────────┘
RESULT:
One large monolith, everything connected.
┌─────────────────────┐
│ MONOLITH │
│ Everything in │
│ one codebase │
└─────────────────────┘
WHY:
- Everyone can access everything
- No boundaries = no boundaries in code
- Quick alignment = no APIs needed
Example 2: Microservices
ORGANIZATION:
Small, autonomous teams.
┌───────┐ ┌───────┐ ┌───────┐
│Team A │ │Team B │ │Team C │
└───────┘ └───────┘ └───────┘
RESULT:
Microservices with clear boundaries.
┌───────┐ ┌───────┐ ┌───────┐
│Svc A │←→│Svc B │←→│Svc C │
└───────┘ └───────┘ └───────┘
WHY:
- Each team owns their service
- Communication via APIs (like teams via meetings)
- Clear boundaries = clear interfaces
Example 3: Frontend/Backend Split
ORGANIZATION:
Frontend team and backend team.
┌──────────┐ ┌──────────┐
│ Frontend │ │ Backend │
│ Team │───────│ Team │
└──────────┘ └──────────┘
RESULT:
Clear frontend/backend separation.
┌──────────┐ API ┌──────────┐
│ Frontend │───────│ Backend │
└──────────┘ └──────────┘
PROBLEM:
- Features need both teams
- Coordination expensive
- Every feature = cross-team project
The Problems
Unintended Architecture
TYPICAL PROGRESSION:
1. Company grows → Teams get split
2. Split often by: Skills, location, history
3. Not by: Optimal architecture
4. Architecture follows the (suboptimal) structure
5. Years later: "Why is our system like this?"
Silos Become APIs
WHEN TEAMS DON'T COMMUNICATE:
→ Their services don't communicate well either
→ Bad or no APIs
→ Duplication instead of reuse
→ Inconsistent data models
Reorgs Don't Change Anything
TYPICAL MISTAKE:
"We're doing microservices now!"
(But teams stay the same)
RESULT:
- "Microservices" that are like a distributed monolith
- Or: Endless coordination between teams
- Architecture doesn't fit the organization
CHANGING ARCHITECTURE WITHOUT CHANGING
ORGANIZATION DOESN'T WORK.
The Inverse Conway Maneuver
If Conway's Law is true, we can reverse it:
Design your organization so the desired architecture emerges.
The Approach
TRADITIONAL:
Organization → (Conway's Law) → Architecture (random)
INVERSE CONWAY:
Desired Architecture → Design Organization → Architecture (intentional)
Example
TARGET ARCHITECTURE:
Three independent domains (Checkout, Inventory, User).
DESIGN TEAMS:
┌──────────────┐
│ Checkout Team│ → Owns Checkout Service
└──────────────┘
┌──────────────┐
│Inventory Team│ → Owns Inventory Service
└──────────────┘
┌──────────────┐
│ User Team │ → Owns User Service
└──────────────┘
RESULT:
The team structure enforces the desired architecture.
Team Topologies
The book "Team Topologies" (Matthew Skelton & Manuel Pais) builds on Conway's Law and defines four team types:
1. Stream-Aligned Team
FOCUS:
A piece of end-to-end value delivery.
E.g. a feature, a product, a customer journey.
EXAMPLE:
"Checkout Team" – everything related to checkout.
CHARACTERISTICS:
- Cross-functional (FE, BE, Ops)
- Long-lived
- Aligned with business stream
2. Enabling Team
FOCUS:
Enable other teams.
Share expertise, don't build yourself.
EXAMPLE:
"DevOps Enablement Team" – helps teams deploy themselves.
CHARACTERISTICS:
- Temporary deployment to teams
- Knowledge transfer, not ownership
- Works itself out of a job
3. Complicated Subsystem Team
FOCUS:
Complex specialized component.
Too hard for stream-aligned teams.
EXAMPLE:
"ML Team" – complex models that others use.
CHARACTERISTICS:
- Deep expertise
- Provides APIs/services
- Reduces cognitive load of other teams
4. Platform Team
FOCUS:
Internal platform for other teams.
Self-service infrastructure.
EXAMPLE:
"Internal Developer Platform Team" –
Deployment, monitoring, infrastructure.
CHARACTERISTICS:
- Treats internal teams as customers
- APIs and self-service
- Reduces cognitive load
The Interaction Modes
1. COLLABORATION
- Teams work closely together
- For: Discovery, new solutions
- Temporary, not permanent
2. X-AS-A-SERVICE
- Team provides service
- Others consume via API
- Clear boundaries
3. FACILITATING
- Enabling team helps another team
- Coaching, not taking over
- Goal: Independence
Using Conway's Law for Architecture Decisions
Questions Before an Architecture Decision
QUESTIONS:
1. What team structure do we have?
2. What architecture does this structure favor?
3. Is that the architecture we want?
4. If no: Can we change the teams?
5. If no: Do we have to live with the emergent
architecture?
When Microservices (Don't) Work
MICROSERVICES WORK WHEN:
- Teams are small and autonomous
- Clear domain boundaries exist
- Teams can deliver end-to-end
- Few cross-team dependencies
MICROSERVICES DON'T WORK WHEN:
- One large team does everything
- Constant cross-team coordination needed
- Domain boundaries unclear
- Shared ownership everywhere
When a Monolith Makes Sense
MONOLITH FITS WHEN:
- One small team (< 10)
- Close collaboration
- Fast iteration more important than isolation
- Domain still unclear
NOT: Monolith is "legacy"
BUT: Monolith fits some organizations
Practical Application
Architecture Review with Conway's Law
EXERCISE:
1. Draw your current system
(Components and their connections)
2. Draw your org chart
(Teams and their communication)
3. Compare:
- Where do structures mirror each other?
- Where are mismatches?
- What does this explain about problems?
4. Ask:
- Is this the architecture we want?
- What team change would help?
During Reorgs
BEFORE A REORG:
1. What architecture do we want?
2. What team structure supports that?
3. Design reorg accordingly
NOT:
Reorg based on other criteria
→ And hope architecture fits
With New Teams
WHEN A NEW TEAM IS CREATED:
1. What will this team own?
2. What system boundaries follow from this?
3. How does it communicate with other teams?
4. What will the APIs look like?
TEAM DESIGN = ARCHITECTURE DESIGN
Limitations
Conway's Law Is Not an Excuse
NOT:
"Our architecture is just like that because Conway's Law."
BUT:
"Our architecture mirrors our organization.
Do we want to change that?"
CONWAY'S LAW DESCRIBES – IT DOESN'T EXCUSE.
Technology Can Also Influence Organization
REVERSE EFFECT:
Sometimes technology forces different structures.
- New tools enable new ways of working
- Platforms reduce team dependencies
- APIs can bridge team boundaries
→ It's not a one-way street
Conclusion: Architecture Is Teamwork
Conway's Law is neither good nor bad – it's an observation. The question is: Do you use it consciously?
Core Principles:
- Awareness: Your organization shapes your architecture
- Inverse Conway: Design teams for desired architecture
- Team Topologies: Structured thinking about team types
- Check Alignment: Regularly compare org vs. architecture
- Act Intentionally: Architecture decisions = team decisions
Your Challenge:
Draw your system and your org chart. Where do you see Conway's Law in action? What does this explain about your architecture problems?
Want to understand how to optimally structure teams? Our guide to Stakeholder Management shows how to handle different team interests.
