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

  • sources/2024-03-06-highscalability-behind-aws-s3s-massive-scale — Kozlovski makes Conway's-Law-as-S3-architecture explicit: "it is said that AWS ships its organizational chart… the architecture strongly exhibits Conway's Law." Four top-level components = four S3 organizations, recursive into nested teams; inter-team interactions as API contracts.
  • sources/2025-02-25-allthingsdistributed-building-and-operating-s3 — Warfield's FAST '23 keynote makes the same point with the "hundreds of microservices" org/architecture decomposition and the concepts/ownership lever.
  • — Zalando names Conway's Law as the root cause of cross-BFF inconsistency at e-commerce scale. Worked example: different BFFs independently reimplement a delivery-window computation so mobile shows "5-9 Feb" while desktop shows "1-3 Feb" for the same article. Zalando's Unified Backend-For- Frontends (systems/zalando-graphql-ubff) is an Inverse-Conway remediation: one graph shared across every client surface forces shared logic.
  • — Conway's Law + CQRS cited together as the required org change for Zalando's PODS architectural shift. "Following Conway's Law and CQRS principles, the Product department was restructured into two stream-aligned teams: Partners & Supply – Manages data ingestion (Command side); Product Data Serving – Focuses on aggregation and retrieval (Query side)." The restructure is framed as required for the technical change — without a clear query-side steward, ~350 consumer teams couldn't migrate off their bespoke local stores. Canonical wiki instance of Conway's Law + CQRS + stream-aligned teams as a triple. See systems/zalando-prapi.
Last updated · 542 distilled / 1,571 read