How Do Committees Invent? (Conway's Law)
Conway's 1968 paper states a law that has turned out to apply to software, hardware, and almost every other designed system: "organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations." The paper is short and the claim is empirical — Conway studied committees and their outputs.
For product direction it is foundational: the shape of the team determines the shape of the product, and any attempt to produce a product shape that does not match the team shape is fighting the system.
Pair with Skelton and Pais's Team Topologies for the modern operational treatment.
The original is short; read it in the original because the paraphrases omit context.
Central argument
Conway argues, based on empirical observation of committees and their outputs, that any organisation designing a system will inevitably produce a design whose structure mirrors the organisation's internal communication structure. This is not a tendency or a risk to manage — Conway presents it as a constraint: the system cannot diverge far from the social architecture that built it. The implication is causal and directional: change the communication structure and the system design changes; leave the communication structure intact and the system design will resist change regardless of architectural intent.
Critique
Conway's evidence base is narrow and largely anecdotal — he studied committees in a pre-software-industry context, and the paper makes no attempt at statistical rigour or falsifiability. A substantive objection is that the law conflates correlation with mechanism: it describes a pattern without fully explaining whether communication structure causes system structure, whether both are caused by a third factor (such as managerial incentives or domain complexity), or whether the arrow of causation can run the other way when strong architectural governance is in place. This ambiguity matters because it makes the law hard to act on prescriptively — knowing that team shape and product shape tend to match does not tell you which one to change first, or whether changing either is sufficient.
Why it matters for product
For a CPO, Conway's Law reframes org design as a product decision: if you ship a platform with tightly coupled components, the first question is not architectural but organisational — which teams own which boundaries, and how do they communicate. It also exposes a common failure mode in digital transformation: companies attempt to modernise their architecture while leaving the communication structure of their teams unchanged, and then wonder why the new system reproduces the old shape. Concretely, decisions about API ownership, service boundaries, and feature team autonomy are inseparable from decisions about reporting lines and team interaction modes.