vault

Conway's Law

37 min read

Conway’s Law

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” — Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968.

Conway’s Law is one of the rare empirical generalizations in software engineering that has held up across six decades, multiple paradigm shifts, and several waves of organizational fashion. Its claim is not that it is bad for systems to mirror their org charts — Conway’s 1968 paper does not editorialize — but that it is unavoidable. Whatever team boundaries you build, the system you design will reflect them. This insight predates structured programming, predates object-oriented design, predates the entire field of software architecture as it is now practiced, and yet remains the dominant explanatory mechanism for why microservices (Microservices Architecture) became feasible exactly when team-autonomous organizational designs (Spotify squads, Amazon two-pizza teams, Netflix’s “freedom and responsibility”) became dominant. The modern engineering reaction to Conway’s Law — design the teams you want, then let the architecture follow — is called the Inverse Conway Maneuver (ThoughtWorks, ~2014; widely promoted by Skelton & Pais’s Team Topologies 2019) and is the conscious design philosophy underneath most successful microservices migrations. This note covers the law’s origin, the canonical formal statement, the empirical evidence that supports it, the modern Inverse Conway practice, and the corollaries that fall out of it.

1. The 1968 Paper — Origin and Original Argument

Mel Conway’s paper How Do Committees Invent? appeared in Datamation magazine in April 1968 — five years before Brooks’s Mythical Man-Month, fourteen years before Edsger Dijkstra’s “humble programmer” Turing Award lecture, twenty-six years before the Gang of Four’s Design Patterns. Conway was working as a researcher at the time and the paper was, in form, a short article aimed at the working programmer. It was rejected by Harvard Business Review before Datamation accepted it. Conway has often noted, with some amusement, that HBR declined a paper that subsequently became one of the most-cited claims in software engineering.

The paper’s central argument has three steps:

  1. Designing a system requires partitioning it. Any non-trivial system is too large for one mind to hold; the design has to be broken into modules, each owned by a person or sub-team.
  2. The interfaces between modules must be negotiated by the people who own them. Changing an interface requires the two people on either side to agree on the change. Therefore an interface is negotiated by a communication path.
  3. Therefore the system’s interface graph is constrained to be a subgraph of the team’s communication graph. If two modules need an interface, the two teams owning them need a communication path. If two teams cannot or do not communicate, the modules they each own cannot share an interface — so the system finds another way.

Conway’s exact phrasing in the paper: “organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.”

Two things are worth noticing about the original wording:

  • Conway said “copies of communication structures,” not “copies of org charts.” The communication structure may differ from the formal hierarchy: two teams that report to different VPs but sit next to each other and pair-program daily do communicate; two teams that report to the same VP but are in different time zones and barely email don’t. The law is about actual communication patterns, not boxes-on-the-org-chart.
  • Conway framed the law as a managerial constraint, not a technical one. The point of the law in his original paper was prescriptive for managers: if you want a particular system architecture, you need to organize the design effort to create the corresponding communication structure. The paper’s title — “How Do Committees Invent?” — telegraphs this; he was responding to the question of why committee-designed systems take particular shapes.

The argument’s logical structure is essentially a homomorphism claim: there is a structure-preserving map from the org’s communication graph to the system’s interface graph. Modern formalizations (notably MacCormack, Baldwin, & Rusnak 2012, Exploring the duality between product and organizational architectures) give it this graph-theoretic statement and provide empirical evidence that the homomorphism holds across thousands of open-source and commercial software products.

2. Why The Law Is So Durable

Conway’s Law has survived because the underlying mechanism is structural, not cultural. Three forces independently push the system toward mirroring the org:

2.1 Communication Overhead

The cost of designing a shared interface scales super-linearly with the number of people involved. Brooks’s classic insight from The Mythical Man-Month (1975) is that a team of n people has roughly n(n−1)/2 communication channels — quadratic growth. Two people on a single team have one communication channel; ten people on a single team have forty-five. When the design effort spans a single co-located team, those forty-five channels are saturated daily; the team can negotiate any interface among any pair of modules at low marginal cost.

When the design effort spans two teams, the intra-team channels remain cheap but the inter-team channels become expensive: scheduled meetings, async email threads, formal RFC-and-review processes. The cost of negotiating an interface across the inter-team boundary is much higher than negotiating one within a team. Engineers, being generally rational, design fewer cross-team interfaces. The system’s interface graph thins along the team boundary precisely because the communication channel is expensive.

This is the bottom-up mechanism of Conway’s Law. It does not require any management directive; it emerges from individual engineers responding to local incentives.

2.2 Merge-Conflict Management

When two teams own the same code module, every change requires merge-conflict resolution and shared understanding of the module’s invariants. The cost of that coordination scales with the rate of change, the number of contributors, and the size of the module. If the rate is high, the teams will choose either (a) to consolidate ownership in one team (re-collapsing the boundary) or (b) to split the module along the team boundary (creating a new internal interface that aligns with the team boundary).

Conway’s Law surfaces here as: teams will refactor shared code into separate modules to escape merge-conflict pain. After the refactor, each team owns a separate module, and the system has a new interface that was created by the team boundary. The mechanism is mechanical: shared editing is unpleasant, so teams design it away by creating a code boundary that matches the team boundary.

2.3 Ownership Clarity and On-Call

In modern operational practice, every service has an on-call rotation. The team on call for a service is responsible for diagnosing and fixing its incidents. If a service straddles a team boundary, the on-call rotation becomes ambiguous: which team is paged at 3 AM when the service goes down? In practice teams resolve this either by reorganizing the service to align with one team or by reorganizing the team to fully own the service.

This creates a strong version of Conway’s Law in operationally mature organizations: services map one-to-one with on-call rotations, which map one-to-one with teams. Amazon’s “you build it, you run it” doctrine (Werner Vogels 2006) makes this explicit. The Spotify model’s squad-owns-component is the same pattern under a different name.

2.4 Expertise Locality

Engineers learn the parts of the system they touch. Engineers on a team touch the parts of the system the team owns. Therefore expertise on a module pools in the team that owns it. When that module is touched by an engineer from another team, the change is slower (less expertise) and riskier (less context). Over time the easy path is for each module to be touched only by its owning team, which strengthens the team-module alignment.

Together these four forces — communication overhead, merge-conflict management, on-call clarity, expertise locality — make Conway’s Law a gravity well in software organization. You can fight it, but you cannot ignore it. Most systems that violate Conway’s Law are systems on their way to a refactor that will restore the alignment.

3. Yourdon and Constantine’s Mid-1970s Elaboration

Edward Yourdon and Larry Constantine’s 1979 book Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design (whose ideas had circulated as IBM technical reports through the mid-1970s) extended Conway’s Law from system architecture into module decomposition. They argued that the principles of cohesion (a module’s parts belong together) and coupling (dependencies between modules are loose and explicit) are not just internal-to-software design principles — they are mirrored by analogous principles in organizational design.

A team is “highly cohesive” if its members share a goal, a vocabulary, and a daily working context. A team-pair is “loosely coupled” if their interactions are bounded and predictable (clear contracts, scheduled checkpoints, rare ad-hoc requests). Yourdon and Constantine’s contribution was to claim that org cohesion and org coupling directly produce system cohesion and system coupling — the org-design lever and the architecture-design lever are the same lever, viewed from different sides.

This insight has been widely cited as the bridge between Conway’s Law and modern modularity-design practice. The Domain-Driven Design community (Eric Evans 2003, Vaughn Vernon 2013) explicitly leverages it: a “bounded context” in DDD is both a code boundary and a team boundary. The two are not separately chosen; they are the same choice viewed in two ways.

4. The Mirroring Hypothesis and Empirical Evidence

The most rigorous test of Conway’s Law in the academic literature is MacCormack, Baldwin, & Rusnak’s 2012 paper Exploring the duality between product and organizational architectures: A test of the ‘mirroring’ hypothesis in Research Policy. The authors compare pairs of software products that perform the same function — one developed by a tightly-coupled organization (a single company with co-located teams) and one developed by a loosely-coupled organization (an open-source project with distributed contributors). They computed propagation cost (a metric of architectural coupling: the percentage of components affected by a change) and showed that:

  • The tightly-coupled organizations produced more tightly-coupled software (higher propagation cost).
  • The loosely-coupled organizations produced more modular software (lower propagation cost).
  • The effect is significant and persists across many product comparisons.

This is the empirical corroboration that Conway’s Law is not just a pithy observation but a measurable phenomenon. The “mirroring hypothesis” is the modern academic name for the law’s testable form.

A complementary line of evidence is in Forsgren, Humble, & Kim’s Accelerate (2018), which presents data from the State of DevOps Reports showing that team autonomy (the ability to deploy without coordinating with other teams) is one of the strongest predictors of high-performing engineering organizations. Team autonomy is impossible without architectural autonomy — the team’s services do not block on other teams’ services for change. Conway’s Law predicts that the architectural autonomy and the team autonomy must develop together; Accelerate shows that high performance correlates with both being high.

5. The Inverse Conway Maneuver

If Conway’s Law says “architecture mirrors organization,” then a manager who wants a particular architecture should first design the organization to produce that architecture. This idea — sometimes called “designing the team to fit the architecture you want” — is the Inverse Conway Maneuver. The phrase emerged in ThoughtWorks consulting practice around 2010–2014; it appeared on the ThoughtWorks Technology Radar and was promoted heavily by James Lewis (co-author with Martin Fowler of the influential 2014 Microservices article on martinfowler.com).

The maneuver has three steps:

  1. Define the desired system architecture. What services do you want? What are their boundaries? What are the interfaces between them?
  2. Redraw team boundaries to match the desired services. Each service has exactly one owning team. Each team owns one or a small number of services. The communication structure of the org now has the shape you want the system’s interface graph to have.
  3. Build (or migrate to) the architecture. Conway’s Law now works for you, not against you. The system the teams design will, by the law, mirror the new org structure — which is what you wanted.

Skelton & Pais’s 2019 book Team Topologies gives the most thorough modern treatment. They describe four team types optimized for fast flow:

  • Stream-aligned teams (the default; aligned with a flow of work — a product, a customer journey, a domain).
  • Enabling teams (help stream-aligned teams adopt new capabilities; temporary).
  • Complicated-subsystem teams (own a deeply technical subsystem requiring specialized expertise: ML platform, payment processing, video transcoding).
  • Platform teams (offer self-service infrastructure to stream-aligned teams).

And three interaction modes between teams:

  • Collaboration (close, intense, time-bound; good for discovery, bad ongoing).
  • X-as-a-service (clear consumer/provider boundary; the dominant steady-state interaction).
  • Facilitating (one team teaches another, then withdraws).

Their thesis is that engineering organizations should be designed deliberately at the level of these team types and interaction modes, with the team boundaries and interactions chosen to produce the architecture the organization wants. This is Inverse Conway formalized into an organizational-design framework.

5.1 Real-World Inverse Conway Examples

Amazon’s “two-pizza teams” (Jeff Bezos, ~2002–onward). Bezos famously declared that no team should be larger than two pizzas can feed (~6–8 people). The constraint is operational — keep team sizes small to keep communication overhead low — but the architectural consequence is that each team owns its own service. As Amazon’s catalog of services exploded in the early 2000s (becoming the precursor to AWS), Conway’s Law operated in service of the design: small teams, each owning a service with a network API, each independently deployable. The microservices architecture that AWS later sold as a paradigm was the architectural shadow of the two-pizza-team org structure.

Netflix’s “freedom and responsibility” (codified in Reed Hastings’s 2009 culture deck). Netflix’s engineering org gave each team broad latitude over their technical choices in exchange for full operational responsibility. The architectural consequence was that teams chose the languages, frameworks, and operational patterns that suited their service. The system architecture became a federation of independent services, each running on the infrastructure abstractions that the platform teams provided. Conway’s Law: the federated, polyglot, service-oriented architecture mirrored the federated, autonomous team structure.

Spotify’s tribes / squads / chapters / guilds model (Henrik Kniberg, 2012 white paper). Spotify codified team types into squads (small, autonomous, owning a product area), tribes (collections of squads with related missions), chapters (cross-squad expertise groups within a tribe — e.g., all backend engineers in the discovery tribe), and guilds (cross-tribe communities of interest — all Scala enthusiasts company-wide). The architecture mirrored the squads: each squad owned its services. The “Spotify model” became fashionable in the 2014–2018 period; many imitators copied the org structure without realizing they were also copying the architectural assumptions, with mixed results.

Microsoft’s One Engineering System and the Azure DevOps reorganization (~2015 onwards). Microsoft restructured large parts of its engineering org around services and product flows, deliberately moving away from the deep functional silos (test team, dev team, ops team — separate orgs) that had produced waterfall-style architectures. The Inverse Conway intent was to produce a microservices-style architecture that supported continuous deployment.

In each case, the architectural change was paired with — or preceded by — an organizational change. The companies that only changed their architecture without changing their org have a recurring pattern of failure (the “we adopted microservices but everything still has to be released together” complaint), which Conway’s Law predicts: if you change the boxes-and-arrows but not the org structure that was producing the old boxes-and-arrows, the org will pull the architecture back to its old shape.

6. Corollaries

Conway’s Law produces a small number of useful corollaries, each of which is independently quotable in design discussions.

6.1 You Cannot Have Services Smaller Than the Team That Owns Them

If a single team is split across five microservices, ownership becomes ambiguous. Within the team, who owns service B vs service C? The on-call rotation covers all five, but the codebase-level knowledge fragments. In practice, sub-team services accumulate ownership ambiguity that surfaces as quality decay (no one feels final responsibility for any single service). The pragmatic minimum is: one team owns at least one service, and a service’s primary owner is at most one team.

The consequence is an upper bound on microservices granularity — at most as many services as there are teams. A 50-team org cannot meaningfully maintain 500 microservices unless it consolidates ownership (each team owns 10 services, which means each team is operating like a small platform team for those ten — a different operating model). The “nano-services” anti-pattern (Newman 2021) — services so small that no team owns enough of them to have full context — is a Conway’s Law violation.

6.2 A Single Team Owning Many Independent Services Deteriorates Each One

Symmetrically: a single team owning, say, 20 services cannot give each service the architectural attention it deserves. The team’s bandwidth for design quality is finite; spreading it over 20 services means each one gets 1/20th. If the services are not independent (they share a domain, share data, share operational concerns), the team’s local optimization tends to collapse them back into something that is structurally a monolith but deployment-wise distributed. This is one path to the Distributed Monolith Anti-Pattern.

The healthy ratio is roughly one team to one to a few services, where “few” means services tightly related enough that the team’s expertise transfers across them.

6.3 The Failure Mode of “A Microservice Mesh Owned by One Team”

A common dysfunctional pattern is a single team owning what is nominally a “microservice mesh” — say, 10 microservices that all interact tightly. Because the team owns all of them, the team can change them in lockstep; the team starts treating the cluster as a single mental unit. The deployment artifacts are 10 separate services, but the design and the change-management treat them as one unit. Eventually the system has all the operational cost of microservices (10 deployment pipelines, 10 sets of monitoring, 10 sets of on-call alerts) and none of the architectural benefits (no team-level decoupling, no independent deployment, no failure isolation). The team would be better off with a Modular Monolith Architecture or a Monolithic Architecture with internal modules.

This is Conway’s Law diagnosing the architecture: the single team’s communication structure produces a single system, no matter how many services the team has nominally split it into. The fix is to either (a) consolidate the services into a monolith (architecture follows org) or (b) split the team into multiple teams (org changes to enable architecture). Both are valid; both follow the law.

6.4 Cross-Cutting Concerns Need Cross-Cutting Teams

Concerns like security, observability, identity, deployment infrastructure, and developer productivity affect every service. By Conway’s Law, if every team handles these concerns ad hoc, every team’s ad-hoc solution will differ, and the system as a whole will have inconsistent security, observability, etc. The Inverse Conway response is to create platform teams (Skelton & Pais’s term) that own the cross-cutting concerns and offer them as services to the stream-aligned teams. The platform team’s “service” is then mirrored into the architecture as a shared platform layer (e.g., the service mesh, the centralized identity provider, the unified observability stack).

6.5 Geographical Distribution Imposes Architectural Constraints

Teams in different time zones cannot have the same low-latency communication that co-located teams have. Conway’s Law predicts that architecture spanning a multi-timezone team boundary will be more loosely coupled than architecture within a co-located team. This is observable in practice: Amazon’s services that span multiple sites have more rigid contracts than services within a single site. Twitter’s early multi-site architecture was a recurring source of pain because the org structure (originally co-located in San Francisco, then expanded internationally) lagged the architectural needs.

The pragmatic implication: when a team must span time zones, plan for the architectural seam to span time zones. Don’t try to maintain a single tightly-coupled module across a team boundary that is six time zones wide. The org will lose.

7. The Inverse Conway Maneuver in Practice — How To Actually Do It

The maneuver sounds simple in principle but is operationally hard. The recurring failure modes:

7.1 Org Changes Are Politically Expensive

Reorganizing teams means moving people, changing reporting structures, reassigning ownership, and inevitably some loss of expertise (the engineer who was the world expert on service X now reports to the team owning service Y, where her expertise is less applicable). Org changes often face resistance from managers whose teams shrink or whose mandates change. Inverse Conway is a political exercise as much as a technical one. The architects proposing it usually need executive sponsorship and a multi-quarter timeline.

7.2 The “We’ll Fix the Org Later” Trap

Many microservices migrations start with the architectural change and defer the org change indefinitely. The classic shape: a senior architect or a CTO says “we’re moving to microservices; the team structure will catch up.” It does not catch up. Six months later the org is the same as before, the architecture has been forced into the old org’s shape, and the team has built a Distributed Monolith Anti-Pattern. Inverse Conway requires the org change to happen first or concurrently, not later.

7.3 Inverse Conway as Cargo Cult

Some companies do org changes that look like Inverse Conway (creating “squads,” renaming teams to “tribes,” writing OKRs about “team autonomy”) without changing the underlying communication structure. If two squads still need to coordinate daily because they share a database, the squads-on-paper organization has not changed Conway’s Law’s predictions. The architecture will mirror the actual communication structure, which has not moved. The fix is to change the actual coupling — e.g., split the database, create proper service contracts — not just relabel the teams.

7.4 Ignoring the Domain Boundaries

The team boundaries in Inverse Conway must align with domain boundaries — the natural seams in the business problem (DDD bounded contexts; Newman’s “stable boundaries”). Drawing team boundaries on lines other than domain boundaries (e.g., “we’ll have a Java team and a Go team,” or “we’ll have a senior team and a junior team,” or “we’ll have an architecture team that designs and a delivery team that builds”) produces architectures that are weird at best and broken at worst. The right axes for team-boundary design are domain (what part of the business this team serves) and flow (what end-to-end customer journey this team optimizes), not technology and not seniority.

7.5 Confusing Conway’s Law with Its Negation

Conway’s Law is descriptive, not prescriptive. It says the architecture will mirror the org, not the org should mirror the desired architecture. Inverse Conway is a prescription that uses the law: if you accept the law, then to get a particular architecture you must engineer the org. But Conway’s Law itself does not say the org should mirror anything. Some organizations choose to leave the architecture/org alignment ambiguous (e.g., temporary projects, research divisions, R&D groups). This is fine if the organizational structure is itself temporary; the law still operates, but on a moving target.

8. Manifestations and Examples

8.1 The Open-Source Project Whose Modules Match Its Maintainers

Linux: the kernel’s subsystem map (mm, net, fs, drivers) maps almost one-to-one onto the maintainer-and-contributor structure. Each subsystem has a maintainer (the person who sends pull requests for that subsystem to Linus); the subsystem boundary is also the social-organizational boundary of the people who work on it. Conway’s Law operating on a planet-scale volunteer organization produces a planet-scale modular architecture. (The Pipe and Filter Architecture of the Unix command line is similarly traceable to the small AT&T Bell Labs team that designed it; the team’s small size and tight communication produced a tightly-cohesive but heavily-modular system.)

8.2 The Bank’s Mainframe Architecture That Matches the 1970s Org Chart

Most large banks’ core systems are stratified in a way that exactly mirrors the 1970s organizational divisions — retail banking, corporate banking, investment banking, treasury, ops — and the systems do not interoperate well across those divisions because the original 1970s org had separate VPs and departments that did not interoperate. Decades of acquisition and modernization have not undone the fundamental shape. Conway’s Law is durable enough to outlive multiple CTO turnovers, multiple technology platform changes, and the original VPs’ retirements.

8.3 The Microservices Migration That Stalls

A common pattern: a company at, say, 200 engineers decides to “go microservices.” They hire consultants, choose Kubernetes, adopt Istio, deploy a CI/CD platform — all the framework choices. Two years later they have 80 microservices, but every release is still coordinated across teams, the database is still shared, and the lead time from commit to production has not improved. The architects diagnose this as “we just need more discipline,” propose more design reviews, and the situation continues. Conway’s Law diagnoses it as: the org structure did not change, so the system’s real coupling has not changed; the deployment artifact count went up, but the architectural-coupling graph stayed the same. The fix is org change, not more architecture review.

8.4 Spotify Squads — and the Limits of Copying

Many organizations copied the Spotify squads/tribes/chapters/guilds model in 2014–2018. Henrik Kniberg, the author of the original Spotify white paper, has been on record saying the model evolved continuously inside Spotify and that the static description in the white paper was already obsolete by the time it was published. Companies that copied the static description got a rigid taxonomy that did not match their domain or scale, and the architectural consequences were predictable: rigid team boundaries that did not match natural domain seams produced rigid service boundaries that did not match natural domain seams.

Conway’s Law warning: copying the team structure of a company whose architecture you admire does not mean you will get their architecture. The team structure produced their architecture given their domain, their scale, and their history. Without the same domain, scale, and history, the same team structure produces different architecture.

8.5 The Conway’s Law Violation That Self-Heals

A useful case study: a team at a hypothetical company is given a “shared library” to maintain. Two product teams use the library. Initially the library team makes changes that both product teams adopt at their own pace. Over time the product teams’ needs diverge. The library team accumulates conflicting feature requests. Eventually the library either (a) bifurcates into two libraries (one per consuming product), (b) stagnates (because no change can satisfy both consumers), or (c) is absorbed by one product team and forked-or-deprecated by the other. In all three cases, Conway’s Law has predicted the outcome: the system settled into a shape that mirrored the org’s actual communication, which was that the two product teams did not communicate with each other and the library team could not bridge them.

9. Diagram — Conway’s Law as a Structure-Preserving Map

flowchart LR
    subgraph Org["Organization Communication Graph"]
        T1["Team A<br/>(Catalog)"]
        T2["Team B<br/>(Orders)"]
        T3["Team C<br/>(Payments)"]
        T4["Team D<br/>(Shipping)"]
        T1 -.->|"daily<br/>standup"| T2
        T2 -.->|"weekly<br/>sync"| T3
        T2 -.->|"weekly<br/>sync"| T4
        T1 -.->|"rare"| T3
    end
    subgraph Sys["System Interface Graph"]
        S1["Catalog<br/>Service"]
        S2["Order<br/>Service"]
        S3["Payment<br/>Service"]
        S4["Shipping<br/>Service"]
        S1 -->|"API<br/>called daily"| S2
        S2 -->|"API"| S3
        S2 -->|"API"| S4
        S1 -.->|"weak<br/>contract"| S3
    end
    Org ==>|"Conway's Law<br/>(structure-preserving<br/>map)"| Sys

What this diagram shows. The left side is the org’s communication graph: four teams, with edge thickness representing how often pairs of teams communicate. The right side is the system’s interface graph: four services, with edge thickness representing the strength of the interface (frequency of calls, number of shared types, depth of contract). The arrow between the two subgraphs labeled “Conway’s Law” represents the law’s claim — there is a structure-preserving map (a graph homomorphism) from the org’s communication graph to the system’s interface graph. Wherever the org communicates strongly, the system has strong interfaces; wherever the org communicates weakly, the system has weak interfaces. Note especially the dashed edge between Team A and Team C — they barely communicate — which mirrors the dashed edge between the Catalog and Payment services — they barely interact directly. The Inverse Conway Maneuver is to first design the right side (the desired system interface graph), then redraw the left side (the org communication graph) so that the structure-preserving map produces the desired result.

10. Pitfalls and Anti-Uses

10.1 Conway’s Law as Excuse

A common abuse: “we have this architecture because Conway’s Law forces it.” This treats the law as deterministic when it is in fact a gravity — strong but resistible at managerial cost. If your team boundaries produce architecture you don’t want, you can change the team boundaries. The law is not absolution; it is a force that has to be paid attention to.

10.2 Inverse Conway as Reorgs-Without-Strategy

Org changes are expensive and disruptive. Doing an Inverse Conway maneuver without a clear architectural target produces churn — the org changes, but no one is sure what architecture is supposed to follow, so the architecture meanders. Successful Inverse Conway requires (a) a clear, communicable target architecture, (b) executive sponsorship, (c) a multi-quarter timeline, and (d) measurable success criteria for both the org and the architecture. Without these, “we’re going to reorg around microservices” produces six months of confusion and a different shape that is no better than the old one.

10.3 Ignoring the Org Structure Already Exists

A new architectural design that ignores the current org structure will be quietly distorted by Conway’s Law during implementation. A pragmatic architect will look at the current org, identify the team boundaries, and design for them — choosing service boundaries that align with team boundaries even if the alignment is awkward. Pretending the org doesn’t matter and that a “pure” architectural design will somehow override the org is a recipe for a frustrated architect.

10.4 Conway’s Law in Federated / Open-Source / Cross-Company Systems

When a system spans organizational boundaries (open-source consortiums, multi-company integrations, public APIs consumed by external developers), Conway’s Law operates across organizations. The W3C, IETF, and other standards bodies are themselves communication structures, and the standards they produce mirror their meeting structures, member-company priorities, and working-group splits. This is why standards committees produce standards that look like committee outputs (compromised, with extension points everywhere, with alternative conformance levels).

10.5 The Law Is About Communication, Not Hierarchy

The org chart often misrepresents the communication structure. Two teams that report to different VPs but share a Slack channel and pair-program weekly have high communication; two teams that report to the same director but sit in different countries and barely speak have low communication. Conway’s Law operates on the actual communication graph, not the formal hierarchy. This is why “let’s just reorganize the org chart” sometimes fails to change the architecture — the actual communication patterns are stickier than the boxes on the chart.

11. Comparison with Sibling Concepts

Conway’s Law is one member of a family of “alignment laws” in software engineering. It is worth distinguishing them:

  • Conway’s Law (1968). Architecture mirrors the org.
  • The Mirroring Hypothesis (academic formalization, MacCormack et al. 2012). Conway’s Law stated graph-theoretically and tested empirically.
  • The Inverse Conway Maneuver (~2014). A prescription that uses Conway’s Law: design the org to produce the desired architecture.
  • Brooks’s Law (1975). “Adding manpower to a late software project makes it later.” A separate but compatible observation about communication overhead.
  • Cunningham’s Law of Technical Debt (Ward Cunningham, 1992). Code that doesn’t fit the team’s understanding accumulates rework cost. Adjacent to Conway’s Law: an architecture mismatched to the team is de facto technical debt.
  • Hyrum’s Law (Hyrum Wright, ~2011). “With a sufficient number of users of an API, all observable behaviors of your contract will be depended on by somebody.” A different consequence of Conway-like dynamics: external users’ implicit interfaces become real interfaces.
  • Domain-Driven Design’s Bounded Contexts (Eric Evans 2003). A bounded context is the unit of both code and team alignment; DDD operationalizes Conway’s Law as a design discipline.
  • Team Topologies’ Four Team Types (Skelton & Pais 2019). A modern operationalization of Inverse Conway.

The clean way to think about all of these: Conway’s Law is the physics (the underlying force); DDD bounded contexts and Team Topologies are engineering disciplines that work with the physics; Inverse Conway is the technique for shaping the system by shaping the org.

12. Interview Discussion Points

Senior-level system-design and engineering-leadership interviews probe Conway’s Law explicitly. The dimensions an interviewer is looking for:

  • “How would you migrate this monolith to microservices?” A weak answer is a list of technologies (Kubernetes, Istio, Spring Cloud). A strong answer leads with the Inverse Conway Maneuver: first identify the team structure that should own the target services; then design the migration path so the team changes happen alongside or before the architectural changes; then choose the technology. The interviewer is signaling for organizational-architectural fluency, not just framework knowledge.
  • “What organizational issues caused architectural problems at your last job?” This is a Conway’s Law fishing question. The interviewer wants you to articulate (a) the team structure, (b) the architecture it produced, (c) the mismatch between the architecture you wanted and the architecture you got, (d) what you tried to do about it. Vague “we had communication problems” is weak; specific “the database was shared because the org had no team that owned it; without a database-owning team, no one could break the dependency” is strong.
  • “How do you decide service boundaries?” The Conway’s Law-aware answer is “by domain (DDD bounded contexts) and by team (existing or planned ownership).” The non-aware answer is a technical heuristic (“by data ownership,” “by call frequency,” “by deploy cadence”). Interviewers at senior levels expect the org dimension to appear in the answer.
  • “What’s the difference between a microservices architecture and a distributed monolith?” The Conway’s Law answer is: a microservices architecture has services that map to teams; a distributed monolith has services that don’t. The same set of artifacts, organized in two different orgs, produces two different categories.
  • “How would you organize a team to build $system?” This is an Inverse Conway question. The strong answer first sketches the system architecture, then describes the team structure that would mirror it, then describes the dependencies and interactions between the teams.

The pattern across all of these: Conway’s Law-fluent answers integrate the organizational layer into architectural reasoning. Conway’s Law-illiterate answers treat architecture as a purely technical exercise. The signal value at senior levels is high.

13. Open Questions

  • How does Conway’s Law operate in fully remote, asynchronous organizations (post-COVID-19 norm at many tech companies)? Is the communication graph topology different in shape, and if so, does it produce systematically different architecture?
  • Has the rise of platform engineering (the platform team as a service to stream-aligned teams) changed the law’s predictions? Skelton & Pais argue it has — the platform layer is a deliberate Inverse Conway abstraction.
  • When does Conway’s Law fail to predict architecture? Are there counterexamples — systems whose architecture doesn’t mirror their org? (One candidate: small projects where one heroic engineer designs everything; the org-graph has only one node but the system is multi-module. The law degenerates because the org structure has no edges to mirror.)
  • How does AI-assisted development change the law’s mechanism? If LLMs reduce the cost of cross-team interface negotiation and merge-conflict resolution, do the Conway constraints relax? Early evidence is mixed.
  • Is there a quantitative mirroring metric — propagation cost (MacCormack 2012) — that should be a standard architectural KPI? Most engineering orgs do not measure it.

12A. Conway’s Law in Distributed-Team and Remote-First Organizations

The post-2020 shift to remote-first engineering organizations has run a natural experiment on Conway’s Law’s mechanism. Pre-2020, the dominant communication channel between team members was face-to-face — desk neighbors, conference-room meetings, hallway conversations — and team boundaries were partially defined by physical co-location. Post-2020, the dominant channels became Slack, Zoom, GitHub, and Notion. The communication graph’s edge weights are now determined less by physical proximity and more by Slack-channel membership, meeting-cadence agreements, and explicit documentation practices.

The Conway’s Law prediction: as the medium of communication changes, the shape of the communication graph changes, and therefore the shape of the architecture changes. Several observable consequences:

  • Higher emphasis on written interfaces. Remote-first teams have to communicate through writing because synchronous communication is more expensive (timezone coordination, less spontaneous overhearing). Architecturally, this favors explicit API contracts and formal documentation over implicit assumptions. Many remote-first organizations have aggressively adopted ADRs (see Architecture Decision Records) precisely because the institutional memory cannot rely on co-located conversations.
  • Sharper team boundaries. Co-located teams had fuzzy boundaries — a conversation overheard at lunch might inform a decision in a neighboring team’s code. Remote teams have hard boundaries — what isn’t in writing in a shared channel doesn’t reach the other team. The architectural consequence is that interfaces between teams have to be more explicit and stable; ad-hoc coordination is harder to sustain.
  • Asynchrony as default. In a co-located environment, “let me grab so-and-so for a quick chat” is a low-cost operation. Remote, it’s a calendar negotiation. Teams that adapt successfully shift toward asynchronous coordination — pull requests, design docs, issue threads — which architecturally favors event-driven and contract-first patterns (Event-Driven Architecture, API-first design) over synchronous-tight-coupling patterns.
  • Time-zone-driven service ownership. When teams span multiple time zones, on-call and incident-response cannot be served from a single location. The result is either follow-the-sun rotations (teams must coordinate handoffs daily) or per-region service ownership (each region owns its own services). The latter leads to cell-based architectures (Cell-Based Architecture) where each cell is independently operable from a single time zone.

The early evidence (e.g., GitHub’s Octoverse 2022 reports, Atlassian’s State of Teams 2023) is that remote-first organizations produce more modular and contract-explicit architectures than the same organizations did when co-located. This is consistent with Conway’s Law: the communication structure has become more formalized, so the architecture has become more formalized. The risk is the inverse — over-formalization producing over-engineered interfaces — but the empirical effect on modularity is real.

The interview-relevant implication: when discussing architecture at a remote-first or hybrid organization, expect the communication-structure dimension to be more visible. Senior interviewers may ask “how does your team coordinate across time zones?” not as a culture question but as an architectural-diagnostic question — the answer reveals what the resulting architecture must look like.

13A. Quantitative Mirroring — The Propagation-Cost Metric

The most rigorous quantitative formulation of Conway’s Law is in MacCormack, Baldwin, & Rusnak (2012). They define propagation cost as the percentage of components that must be modified when a single component changes, computed from the design-structure matrix (DSM) of the codebase. A modular system has low propagation cost (a single change propagates to few components); a tightly-coupled system has high propagation cost (a single change ripples through many components).

The mirroring hypothesis predicts: tightly-coupled organizations produce tightly-coupled software (high propagation cost); loosely-coupled organizations produce loosely-coupled software (low propagation cost). MacCormack et al. tested this empirically by comparing pairs of products with similar functionality but different organizational origins. Tight-org commercial products had propagation cost in the range of 17–43%. Loose-org open-source equivalents had propagation cost of 1–14%. The effect was robust and statistically significant.

The implication for engineering management is that propagation cost should be a measured KPI. Most engineering organizations do not measure it — instead they rely on subjective signals like “how often does a small change require coordinated releases?” — but the metric is computable from any version-control history (using tools like the open-source cda from Carnegie Mellon, or commercial tools like CodeScene). A team that measures propagation cost has a quantitative early-warning signal for architectural drift: rising propagation cost over time indicates the system is becoming more coupled, which under Conway’s Law means the org’s communication structure is becoming more tightly-coupled. The intervention may be either architectural (refactor for modularity) or organizational (split the team, narrow ownership).

The metric is also useful as an Inverse Conway target: “we will reorganize teams such that propagation cost drops below 15% within four quarters” is a quantitatively measurable architectural-and-organizational goal. Without quantification, Inverse Conway maneuvers can drift into vague “we want to be more modular” goals that fail because nobody can tell when they’re done.

13B. Conway’s Law and Open-Source Communities

Open-source projects are organizational structures, even if loose ones, and Conway’s Law operates on them. The Linux kernel’s modular subsystem structure (mm, net, fs, drivers, each with named maintainers) maps directly to its contributor sociology. The Linux maintainership model — Linus Torvalds at the top, lieutenants for major subsystems, sub-maintainers under each lieutenant — is a hierarchical communication structure that has produced a hierarchical-modular kernel.

GitHub-era open source is more federated: a project like Kubernetes has SIGs (Special Interest Groups) for storage, networking, autoscaling, etc., each with co-chairs and a separate governance structure. Kubernetes’ codebase is correspondingly federated — pkg/storage/, pkg/network/, pkg/autoscaling/ are largely owned by their respective SIGs. The architecture mirrors the SIG structure with high fidelity.

What Conway’s Law predicts about open source: projects whose contributor base spans many independent organizations will have more modular architectures than projects whose contributor base is a single organization. Empirically this is observable. A single-company open-source project (e.g., a company’s own developer tools) tends toward tight coupling because the contributors all communicate inside one Slack workspace. A consortium open-source project (e.g., a CNCF graduated project with contributors from many companies) tends toward loose coupling because the contributors must communicate via formal interfaces (GitHub issues, mailing lists, design docs) that scale better than informal coordination.

The Inverse Conway insight applied to open-source governance: when designing a successful open-source project, deliberately federate the governance early — adopt SIGs or working groups, give them autonomy, accept the architectural-modularity that federation produces. Projects that retain centralized governance (one BDFL — “Benevolent Dictator For Life” — and tight coordination) tend to produce monolithic codebases. Both are valid choices, but the architectural consequence is predictable.

13C. The Communication-Structure Heuristic for Architectural Diagnosis

A practical diagnostic technique for architects: to predict where the architectural seams are, draw the team communication graph. Wherever two teams communicate weakly, expect a weak architectural seam (often a fragile one). Wherever two teams communicate strongly, expect a strong seam (or no seam at all, with the two teams effectively merged at the code level). Where communication is asymmetric (Team A frequently bothers Team B, but Team B rarely contacts Team A), expect a one-directional dependency in the architecture — the bothering team’s code depends on the bothered team’s code.

This heuristic is fast and cheap. A 30-minute conversation with the engineering manager of a large team can produce a sketch of the communication graph; the architectural map can then be predicted before any code is read. When the predicted architecture matches the actual architecture, Conway’s Law has been confirmed; when they diverge, there is something interesting going on (often a recent reorg whose effects haven’t propagated to the architecture yet, or an architectural choice that consciously fights the org structure — an unusual case).

The heuristic is symmetrical for architectural-design proposals: when designing a new system, draw the team communication graph that would exist if the system existed, and ensure it matches the org you have or can create. If the design requires team interactions that do not currently happen, plan for creating those communication channels alongside the system. Otherwise the system will fail to materialize as designed; the missing communication will be the failure mode.

14. See Also

Graph View

Backlinks