Conway's Law

Melvin Conway's 1967 observation is one of the most empirically validated ideas in software engineering and org design: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." Teams build systems that look like the communication patterns between them. If you have three teams that barely talk to each other, you will end up with three services with fragile, hand-wavy integration points between them. Conway's Law is less a prescription than a gravitational constant — ignoring it doesn't make it go away.

Origin

Melvin Conway was a programmer working on committee-driven software projects in the 1960s. He noticed that the structure of the software his colleagues produced consistently mirrored the structure of the groups producing it. He wrote up the observation in a paper titled "How Do Committees Invent?" (1968). The paper was initially rejected by Harvard Business Review on the grounds that the claim was "unproven" — a judgment that has aged poorly.

The "law" was largely ignored in mainstream engineering literature for decades until it was resurrected by Fred Brooks in The Mythical Man-Month (1975) and, more forcefully, by the microservices and DevOps communities in the 2010s. James Coplien's Lean Architecture (2010), Eric Evans's Domain-Driven Design (2003), and especially Matthew Skelton and Manuel Pais's Team Topologies (2019) made Conway's Law central to modern thinking about team and system design.

Empirical studies by Nagappan et al. at Microsoft (2008) and later at Google and other companies have confirmed Conway's original observation: organizational metrics (team size, organizational distance between contributors, number of teams touching a module) are better predictors of software defects than most technical metrics.

The Framework

The Original Statement

"Any organization that designs a system (defined broadly) will
 produce a design whose structure is a copy of the organization's
 communication structure."
                                        — Melvin Conway, 1968

"Design" here is broad: software architecture, product architecture, API boundaries, user experience. "Communication structure" means who talks to whom, how often, and how easily.

The Inverse Conway Maneuver

In the 1980s and '90s, engineers tried to work around Conway's Law: design the "right" architecture, then force the teams to deliver it, regardless of org structure. This almost always failed. The system gradually warped back toward the shape of the organization.

By the 2010s, a more effective approach emerged: the Inverse Conway Maneuver. Instead of fighting Conway's Law, exploit it.

Standard approach (usually fails):
  1. Design the desired system architecture
  2. Build it with the current team structure
  3. Notice it's warped back toward the org chart
  4. Blame engineers

Inverse Conway Maneuver (usually works):
  1. Decide what architecture you want
  2. Reshape the team structure to match
  3. Let Conway's Law produce the architecture naturally
  4. Adjust as needed

The Inverse Conway Maneuver is now a standard tool in engineering org design. It's why microservices work well when teams are structured around services, and fail when teams are structured functionally (e.g., all back-end engineers on one team).

What Counts as "Communication Structure"

- Who reports to whom
- Who sits near whom (or in which Slack channels)
- Who attends the same meetings
- Team size and composition
- How teams are measured and rewarded
- Geographic distribution (especially timezones)
- Tooling (shared repos vs separate repos)
- Documentation practices (shared docs vs internal-only)

Each of these shapes the communication graph between engineers, and therefore the shape of what they build.

The Second-Order Effects

Conway's Law operates in multiple directions:

1. Team structure shapes architecture.
   Two teams → two services with a coordination interface.

2. Architecture shapes team structure.
   A monolith that's always broken makes every team share an
   incident rotation. Architecture forces coupling.

3. Culture shapes both.
   A high-trust culture produces looser interfaces; a low-trust
   one produces rigid contracts and more bureaucratic APIs.

4. Tools shape communication.
   A shared monorepo encourages different communication than
   separate repos with separate owners.

Mature engineering orgs understand Conway's Law bidirectionally. They use it as a tool, not just a constraint.

Cognitive Load

Team Topologies (Skelton & Pais) reframes Conway's Law through cognitive load. A team can only hold so much in its head. When a team owns more than its cognitive capacity, its communication with adjacent teams degrades:

- Engineers on the overloaded team stop being able to discuss
  everything they own
- They drop context, miss questions, respond late
- Adjacent teams build around them, not with them
- The architecture drifts toward what the overloaded team
  cannot defend

This gives a practical lever: size teams to fit their cognitive load, and the communication structure (and therefore architecture) will be healthier.

How to Use It

Diagnostic Use

When architectural problems appear, look first at team structure:

- Services that are tightly coupled but owned by different teams
  → those teams likely do not communicate well
- Services with fragile interfaces
  → likely team boundaries at those interfaces
- Services nobody owns
  → team structure has a gap
- Services owned by too many teams
  → communication overhead is breaking them

Prescriptive Use (Inverse Conway Maneuver)

When designing or redesigning an architecture:

1. Identify the desired architecture.
   Usually: services with clean boundaries, each owned by one team,
   with well-defined interfaces.

2. Map the team structure you need to produce that.
   One team per service. Teams sized to their service's cognitive load.
   Teams geographically located to support tight collaboration.

3. Compare to your actual team structure.
   Where are the mismatches?

4. Reorganize.
   Usually: merge teams that should have been one, split teams that
   should have been two, add or eliminate layers.

5. Let the architecture drift into alignment.
   Over 3-6 months, the system reshapes itself.

Ongoing Use

- When adding a new service, decide the owning team first.
- When splitting a team, decide how the architectural boundary
  will change.
- When an existing service needs a major rework, consider whether
  team structure needs to change to support it.
- In retrospectives on architectural pain points, ask: "What team
  communication produced this?"

Tech & Company Example

Example 1: The Failed Microservice Migration

Company: 200-engineer SaaS company.

Existing architecture: Monolithic Rails application.
Existing team structure: Functional (Front-End team, Back-End team,
                         Platform team, Database team).

Decision: Migrate to microservices.

Initial approach (ignoring Conway's Law):
  - Designed 12 target services based on domain analysis.
  - Kept functional team structure.
  - Each service was built by the back-end team with front-end
    work from the front-end team.

Result after 18 months:
  - Services were technically deployed separately but every
    release required coordinated deployment across all of them.
  - The "microservices" were a distributed monolith.
  - Every service change required the back-end team to negotiate
    with the front-end team.
  - Database team owned the shared database; every service depended
    on it.

Root cause: The communication structure hadn't changed. The
back-end team communicated with the front-end team through formal
processes; the services they built reproduced those formal processes
as RPC calls.

Corrective action:
  - Reorganized into 12 cross-functional teams, one per service.
  - Each team had front-end, back-end, and database engineers.
  - Dissolved the functional teams.

Result after 12 months of the new structure:
  - Services became genuinely independent.
  - Release velocity per service increased 4x.
  - Cross-service contracts became explicit APIs instead of
    implicit assumptions.
  - The architecture aligned with the team structure, and the
    team structure supported the architecture.

This is a textbook failure of ignoring Conway's Law, followed by a successful Inverse Conway Maneuver.

Example 2: Timezone as Architecture

Company: Fully remote 100-engineer company. Teams distributed
         across US, EU, and India.

Observation: A service with owners in both US and India was
             chronically unreliable. A similar-complexity service
             with owners only in the EU was reliable.

Investigation:
  - The US/India-owned service had high bus-factor per timezone
    (2-3 engineers each).
  - Incidents happened during US-only hours; India engineers didn't
    see context for 10 hours.
  - Decisions made in US standups weren't re-explained to India.
  - Gradual drift in code conventions between the two halves of
    the team.
  - Integration tests broken; each half thought the other would fix.

Conway's Law explanation:
  - The team's communication structure had a 10-hour gap.
  - The architecture produced by that team had a 10-hour coupling
    problem — exactly what Conway predicts.

Corrective action:
  - Reorganized so each service was owned by a timezone-colocated team.
  - US/India engineers were reassigned to different services, each
    timezone-colocated.
  - Documentation practices formalized for cross-service handoffs.

Result:
  - Reliability converged across services.
  - Cross-service handoffs became explicit (documented interfaces)
    rather than implicit (ongoing communication).

The architecture healed when the team's communication structure was made consistent.

Example 3: The API That Matches the Org Chart

A SaaS company's public API has 7 major product areas.
The company has 7 major product teams.

Each API area reflects its team:
  - The team that owns "Users" has a clean, well-versioned API.
    (Senior staff engineer leads it; strong review culture.)
  - The team that owns "Reports" has inconsistent naming, bespoke
    auth handling, and legacy endpoints.
    (Team has rotated leadership; no durable ownership.)
  - The team that owns "Billing" has strict schemas and formal
    review processes.
    (Team has regulatory pressure; culture of rigor.)

The API is a mirror of the company.

For external developers, this is confusing. They experience
inconsistent quality within what appears to be one product.

Corrective action: The platform team standardized API conventions
(authentication, pagination, error formats) across all teams.
This required addressing the team-level cause: setting up an API
review guild with representation from every product team, standardized
tooling, and shared libraries.

The technical fix (uniform API standards) could only succeed via
a communication-structure fix (the guild that cuts across team
boundaries).

Conway's Law predicts this outcome. Fixing the API required fixing the communication.

When It Works

Architectural decisions of any scale
Engineering org design
Diagnosing why systems behave the way they do
Planning team growth or restructuring
Mergers and acquisitions (where two org structures must merge)
Microservices adoption
Platform team design

When It Does Not Work

Nothing fails Conway's Law — this is the thing. But people fail to apply it.
Very small teams — In a 5-person startup, there's only one team; Conway's Law is trivial.
External constraints dominate — If an API must match a legal or partner-dictated schema, team structure can't change that.
Legacy systems — A 20-year-old architecture can't easily be reshaped by team structure changes; historical Conway is baked in.
Contractors / consultants — They're outside the communication structure in some ways; their code often violates Conway's Law in small pockets.

Common Failure Modes

Diagnostic

Blaming Engineers — Architecture problems get attributed to individual engineer failings rather than to team structure. Fires rather than prevents.
Over-Indexing on Architecture — Treating architectural problems as purely technical; ignoring the communication substrate.
Single-Cause Thinking — Attributing every architecture issue to team structure. Sometimes the issue is technical debt, tooling, or scope.

Intervention

Reorg Without Architecture Plan — Shuffling team structure without clarity on what architecture that should produce. Produces noise, not improvement.
Architecture Without Reorg — Redesigning architecture and expecting current teams to deliver it. The system warps back.
Reorg Theatre — Re-labeling teams without actually changing communication patterns. Same meetings, same dependencies, same architecture.

Cognitive Load

Oversized Teams — 15-20 person "teams" that cannot coordinate internally. They produce architectures as fragmented as their internal communication.
Over-Fragmented Teams — 2-3 person teams per service. Too small to sustain the service through personnel changes; creates bus-factor problems.
Ignoring Cognitive Load — Making teams own everything in their domain. Teams hit capacity and architecture warps to their limits.

Culture

Conway-as-Excuse — Using Conway's Law to avoid accountability. "Our architecture is bad because our org is wrong" — but no one takes responsibility for fixing the org.
Inverse Conway Without Thought — Reshaping teams aggressively around architecture goals, ignoring human impact (career paths, relationships, existing context).
Permanence Bias — Treating the current team structure as fixed. Conway's Law only helps when team structure is malleable.

Scale

Premature Inversion — Using Inverse Conway Maneuver in a 10-person company where one team should handle everything. Adds overhead.
Frozen Snapshot — Reorganizing once and treating it as permanent. Organizations evolve; Conway's Law keeps applying.

Team Topologies (Skelton & Pais) — Builds on Conway's Law; provides specific team patterns (Stream-aligned, Platform, Enabling, Complicated-Subsystem) and interaction modes. Most important modern companion.
Domain-Driven Design (Evans) — Bounded contexts map to team boundaries; DDD is Conway's Law applied deliberately.
Inverse Conway Maneuver — The explicit strategy of shaping teams to produce desired architecture.
Dunbar's Number (~150) — Organizational limit on who can meaningfully communicate; implies limits on flat org structures.
Brooks's Law — "Adding manpower to a late project makes it later" — a Conway-adjacent observation about coordination cost.
Microservices patterns — Many microservices patterns are implicitly Conway-informed; one-service-per-team is an applied Inverse Conway Maneuver.
Monorepo vs polyrepo — A tooling choice that shapes communication structure, which shapes architecture. Pure Conway's Law in practice.