Conway's Law — Deep Dive

Level: Beginner → Intermediate
Pre-reading: 01 · Architectural Foundations

The Law

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." — Melvin Conway, 1967

In plain terms: your system architecture will mirror your org chart. Teams that don't talk to each other will build components that don't integrate well. Teams that must coordinate constantly will create tightly coupled systems.

graph TD
    subgraph Organization Structure
        T1[Frontend Team]
        T2[Backend Team]
        T3[Data Team]
        T1 ---|Coordination required| T2
        T2 ---|Coordination required| T3
    end
    subgraph System Architecture
        S1[Frontend Monolith]
        S2[Backend Monolith]
        S3[Data Pipeline]
        S1 -->|Tight API| S2
        S2 -->|ETL Jobs| S3
    end

Why Conway's Law Matters for Architects

The Inverse Conway Maneuver

Instead of letting org structure accidentally shape your system, intentionally structure your teams to produce the architecture you want.

graph LR
    A[Desired Architecture] --> B[Design Team Boundaries]
    B --> C[Teams Build Aligned Components]
    C --> D[System Reflects Architecture]

Example: Microservices Adoption

Example: Breaking Up a Monolith

Before:

• 3 feature teams share one monolith codebase
• Merge conflicts, coordinated releases, everyone touches everything

After (Inverse Conway):

• Extract bounded contexts into separate services
• Each team owns one or more services end-to-end
• Teams deploy independently

Team Topologies — A Framework

Team Topologies (Skelton & Pais, 2019) provides patterns for structuring teams to reduce cognitive load and enable fast flow:

Four Fundamental Team Types

graph TD
    subgraph Stream-Aligned Teams
        SA1[Order Team]
        SA2[Inventory Team]
        SA3[Customer Team]
    end
    subgraph Platform Team
        PT[Platform Team]
    end
    subgraph Enabling Team
        ET[DevOps Enablement]
    end
    PT -->|Self-service| SA1
    PT -->|Self-service| SA2
    PT -->|Self-service| SA3
    ET -.->|Coaching| SA1
    ET -.->|Coaching| SA2

Three Interaction Modes

Cognitive Load and Team Size

Teams have limited cognitive capacity. Overloading a team leads to:

• Slower delivery
• Higher error rates
• Knowledge silos within the team
• Burnout

Types of Cognitive Load

Team-Sized Architecture

"A team should own a piece of the system they can understand and evolve within their cognitive capacity."

Signs Your Org and Architecture Are Misaligned

Practical Application: Designing Service Boundaries

Step 1: Identify Business Capabilities

Step 2: Map to Bounded Contexts (DDD)

Each business capability often maps to a bounded context — a consistent domain model with clear boundaries.

Step 3: Align Teams to Bounded Contexts

graph TD
    subgraph Order Team
        OS[Order Service]
        ODB[(Order DB)]
    end
    subgraph Inventory Team
        IS[Inventory Service]
        IDB[(Inventory DB)]
    end
    subgraph Payment Team
        PS[Payment Service]
        PDB[(Payment DB)]
    end
    OS -->|Events| IS
    OS -->|API| PS

Step 4: Define Interaction Contracts

• API specifications (OpenAPI, gRPC)
• Event schemas (Avro, Protobuf)
• SLAs (latency, availability)

Common Anti-Patterns

Applying Conway at Scale

Amazon's "Two-Pizza Teams"

• Teams small enough that two pizzas can feed them
• Each team owns a service end-to-end (build, run, operate)
• Teams communicate via APIs, not meetings
• Architecture emerged from team structure

Spotify's Squads and Tribes