[Anchor Proposal]: Conway's Law

[raifdmueller]

Proposed Term

Conway's Law

Context

Source: catalog review of https://lawsofsoftwareengineering.com/ (56 "laws"). Of those, ~8 look like genuine semantic-anchor candidates rather than descriptive observations. This is one of them.

Why it may qualify as an anchor: Invoking "Conway's Law" in a prompt reliably activates reasoning about the alignment between organizational/communication structure and system architecture — a rich, bounded knowledge domain, not just a single instruction.

• Precise: specific, well-bounded claim
• Rich: triggers org-design, team-topology, module-boundary reasoning
• Consistent: widely known, stable activation across LLMs
• Attributable: Melvin Conway, 1968 ("How Do Committees Invent?")

Pre-assessment tier: ★★★ (self-standing) — likely fills a real gap (no org-↔-architecture anchor in the catalog yet).

Related existing anchors: domain-driven-design, c4-diagrams, hexagonal-architecture.

Pre-submission Checklist

• Searched existing anchors — not present
• Well-established concept

[JensGrote]

Proposal: Conway's Law as a new semantic anchor

I have reviewed Conway's Law against the anchor quality criteria. Strong candidate — fills a genuine gap with precise, attributable, and rich semantics.

---

Source verification

The original paper: Melvin E. Conway, "How Do Committees Invent?", Datamation, April 1968.

The thesis statement appears in the third-to-last paragraph:

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Conway's own 42-years-later informal restatement: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

Fred Brooks coined the name "Conway's Law" in The Mythical Man-Month (1975). The Jargon File preserved the canonical quip: "If you have four groups working on a compiler, you will get a 4-pass compiler."

---

Assessment against quality criteria

Criterion	Verdict	Evidence
Precise	✅	Single, well-bounded thesis — not a vague instruction, not a collection of unrelated claims. There is exactly one statement that is Conway's Law (the Datamation paragraph) plus well-established corollaries.
Rich	✅	Activates: org-design ↔ system architecture mapping, Inverse Conway Maneuver, Team Topologies (Skelton & Pais), module-boundary reasoning, communication-cost-driven design, the 4-pass-compiler corollary.
Consistent	✅	Universally known across LLMs; stable activation regardless of model or context.
Attributable	✅	Melvin Conway, 1968. Peer-reviewed (Datamation). Named and popularized by Fred Brooks. Well-documented provenance.

---

Gap analysis

What the catalog has	What Conway's Law adds
domain-driven-design → bounded contexts	Explains why bounded contexts follow team boundaries, not just that they should
c4-diagrams → system boundaries	Explains why those boundaries exist at the social level
hexagonal-architecture → ports/adapters	Explains when ports are needed — at team communication seams
lehmans-classification → E-type evolution	Conway's Law is the mechanism behind the feedback loop Lehman describes

---

Proposed anchor file

= Conway's Law
:categories: software-architecture
:roles: software-architect, software-developer, team-lead, business-analyst, consultant
:related: domain-driven-design, c4-diagrams, hexagonal-architecture, lehmans-classification
:proponents: Melvin Conway
:tags: conways-law, organization, architecture, communication, team-topology, module-boundaries
:tier: 3

[%collapsible]
====
Full Name:: Conway's Law (after Melvin Conway)

Also known as:: Conway's Maxim

[discrete]
== *Core Concepts*:

The original thesis::
+
--
**[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.**
-- +
Conway, "How Do Committees Invent?", Datamation, 1968

Communication structure drives architecture::
Two modules A and B cannot interface correctly unless the designer of A communicates with the designer of B. The interface structure of a software system therefore necessarily shows congruence with the social structure of the organization that produced it. This is not a normative claim about *good* design — it is an observation about *inevitable* design.

Inverse Conway Maneuver::
To achieve a target architecture, restructure the organization first. Loosely coupled modules require loosely coupled teams. The system follows the org — not the other way around.

Module boundary follows team boundary::
The cost of cross-team coordination is the primary driver for where modules split, not technical purity. A module owned by one team creates a natural seam; a module that requires coordination across N teams creates N² communication paths.

Broader applicability::
Conway intended the law in the broadest sense — any system design, not just software. Business process design is equally constrained: the communication structure of the process-owning organization stamps itself onto the process design. Roles analyzing and adapting processes (business analysts, process managers) are subject to the same dynamic.

Key Proponents:: Melvin Conway (1968); Fred Brooks ("The Mythical Man-Month", 1975); Eric S. Raymond ("The Cathedral and the Bazaar", 1999); Matthew Skelton & Manuel Pais ("Team Topologies", 2019)

[discrete]
== *When to Use*:

* Designing system architecture — mapping communication paths to module boundaries
* Planning organizational changes — using the Inverse Conway to achieve a target architecture
* Explaining why a monolith emerged or why microservice boundaries are misaligned
* Setting up platform teams and defining their service interfaces
* Evaluating whether system coupling reflects team communication overhead
* Justifying why a design organization should be structured around communication needs
* Analyzing business processes — checking whether process design reflects organizational communication paths rather than requirements

[discrete]
== *Related Anchors*:

* <<domain-driven-design,Domain-Driven Design>> — Bounded Contexts are the architectural consequence of team boundaries predicted by Conway's Law
* <<c4-diagrams,C4 Diagrams>> — System context and container boundaries reflect organizational seams
* <<hexagonal-architecture,Hexagonal Architecture>> — Port/Adapter boundaries are natural at team communication interfaces
* <<lehmans-classification,Lehman Classification>> — E-type systems evolve under the organizational feedback loop that Conway's Law describes
====

---

Proposed roles.yml entry

conways-law:
  roles:
    - software-architect
    - software-developer
    - team-lead
    - business-analyst
    - consultant
  rationale: "Organizational-architecture mirroring principle; architects align system boundaries with team boundaries, developers understand module-splitting decisions, team leads design teams for target architecture, business analysts assess process-organization alignment (business process analysis is a core business-analyst competency — Conway's Law applies as directly to process design as to software design), consultants advise on org restructure. Note: a future taxonomy extension could add a dedicated process-manager role — no current role captures process-design ownership explicitly, and Conway's Law applies equally there."

---

Proposed translator catalog entry

In skill/semantic-anchor-translator/references/catalog.md, add to the Software Architecture section:

| Conway's Law | Organizations design systems that mirror their communication structure (Conway 1968). Inverse Conway Maneuver, module boundary follows team boundary, 4-pass-compiler corollary. |

---

Open questions

Process-manager role. Conway's Law applies to any system design, not just software — process design and organizational design are equally constrained. The current role taxonomy has business-analyst (who analyzes processes) but no role for someone who owns process design (process manager, process owner, business process designer). Should the anchor reference a process-manager role that does not exist yet? Options:

a) Leave it as-is, using business-analyst + a note in the rationale (as proposed above). The role taxonomy stays stable.
b) Propose a new process-manager role as part of this PR, extending the taxonomy. This affects 50+ existing anchors that might also benefit from it.

I lean toward (a) for scoping reasons — adding a new role is a cross-catalog change beyond this single anchor — but happy to do (b) if there is consensus.

---

Next steps

If this direction is accepted, I can submit:

1. docs/anchors/conways-law.adoc (English)
2. docs/anchors/conways-law.de.adoc (German translation)
3. docs/metadata/roles.yml update
4. skill/semantic-anchor-translator/references/catalog.md update

[raifdmueller]

✅ Shipped in #554 — Conway's Law is now live in the catalog (EN + DE), with metadata, a changelog entry, and an AgentSkill catalog entry. It passed verification against the quality criteria (precise / rich / consistent / attributable) and the recognition test. Thanks for the proposal! 🙏