Skip to content

CONCEPT Cited by 2 sources

Conway's Law

Definition

Conway's Law (Melvin Conway, 1968) is the sociotechnical observation that systems tend to mirror the communication structure of the organizations that build them. Modules map to teams; the seams between modules map to team boundaries; inter-module APIs map to inter-team protocols.

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

At sufficient scale the effect is load-bearing: architecture is the org chart, and vice versa. The phrase "AWS ships its org chart" is an in-house restatement used by S3 engineers.

Why it happens

  • Teams own APIs; the APIs teams own become module boundaries.
  • Cross-team coordination is slow, so the slowest seam in the system tends to align with the slowest seam in the org.
  • Team-level incentives (on-call, performance reviews, promotion) optimize within the team, not across teams.
  • Changes that span teams require alignment overhead that within-team changes don't — so over time, refactors flow within teams and between modules.

S3 as the canonical instance

S3's top-level block diagram is four high-level components: a frontend REST fleet, a namespace service, a storage fleet (HDDs), and a storage management fleet (background replication, tiering). Each corresponds 1:1 to a distinct S3 organization with its own leaders and teams. Each top-level box recurses into nested components with their own teams and fleets. Inter-team interactions are literal API-level contracts. (Source: sources/2024-03-06-highscalability-behind-aws-s3s-massive-scale, sources/2025-02-25-allthingsdistributed-building-and-operating-s3)

Warfield's generalization: teams that own their services end-to-end (API, durability, performance, pagers, post-incident improvement) go faster than teams that own only one slice — an argument for concepts/ownership as a scaling lever that deliberately leans into Conway's Law rather than against it.

Strong vs weak reading

  • Weak (descriptive): systems will reflect their builders' communication structure unless actively countered. Useful as a diagnostic for why a system feels wrongly shaped.
  • Strong (prescriptive, "Inverse Conway"): design the communication structure you want — pick the seams you want in the system and organize the teams around those seams. Used deliberately at hyperscalers (AWS, Amazon 2-pizza teams) and in microservice transformations.

Practical implications

  1. Org boundaries will leak through as API boundaries. If two modules are co-owned by one team, expect the interface to be sloppier (because the co-owners can fix up internals freely).
  2. Shared-fate teams produce tighter couplings than they should. A single team that owns three "independent" microservices often produces three very non-independent services.
  3. Re-orgs produce re-architectures — and vice versa. A re-architecture without a re-org often fails to land; a re-org without a re-architecture often creates contradictory ownership.
  4. You cannot ship a 100-team system with 10-team coordination machinery. The coordination cost grows faster than linear in team count; the seams have to absorb it.

Interactions

  • concepts/ownership — the ownership model Warfield calls out is an Inverse-Conway application: design the team to own a full service surface.
  • Microservice architecture is effectively Conway's Law turned into a design principle.

Seen in

Last updated · 319 distilled / 1,201 read