Der Informatiker Melvin Conway formulierte die Beobachtung 1968 in einem Aufsatz mit dem Titel „How Do Committees Invent?“. Wenn vier Teams einen Compiler bauen, bekommt man einen Compiler mit vier Durchläufen. Der Grund ist einfach: Schnittstellen zwischen Systemteilen entstehen dort, wo sich Menschen abstimmen müssen. Wo Teams wenig miteinander reden, entstehen getrennte Bausteine mit schmalen Verbindungen.
Das Gesetz gilt weit über Software hinaus. Die Website eines Konzerns spiegelt häufig dessen Abteilungen statt die Fragen der Kunden. Ein Data Warehouse, das von einer zentralen IT gebaut wird, sieht anders aus als eines, an dem Fachbereiche selbst mitarbeiten. Datenarchitekturen wie Data Mesh sind im Kern der Versuch, Conways Gesetz bewusst zu nutzen: Verantwortung für Daten liegt dort, wo die Daten entstehen, also muss auch die Architektur dort geschnitten werden.
Daraus ist das sogenannte umgekehrte Conway-Manöver entstanden: Wer eine bestimmte Systemarchitektur will, organisiert zuerst die Teams so, dass ihre Kommunikation dieser Architektur entspricht. Das Buch Team Topologies von Matthew Skelton und Manuel Pais hat diesen Gedanken für die Softwareentwicklung ausgearbeitet.
Für Organisationsentwicklung ist das Gesetz eine hilfreiche Diagnose. Wer verstehen will, warum ein System so ist, wie es ist, sollte sich ansehen, wer mit wem spricht und wer nicht. Umgekehrt scheitern technische Umbauten oft, wenn die Organisation dahinter gleich bleibt (siehe auch Datenqualität ist ein Organisationsproblem).