Conways Gesetz ist nur die halbe Wahrheit: Lernen Sie den „Conway-Drift“ kennen

Die meisten Führungskräfte im Ingenieurwesen haben schon einmal von Conways Gesetz gehört. Weitaus weniger kennen hingegen Conway-Drift, und genau in dieser Lücke verlieren viele Unternehmen still und leise an Dynamik.

Conways Gesetz ist eine jener Beobachtungen, die fast zu einfach klingen, um nützlich zu sein – bis man miterlebt, wie es das Schicksal eines mehrjährigen Produktprogramms bestimmt. „Conway Drift“ ist die Fortsetzung in Zeitlupe: Was passiert, wenn… danach Man hat die Struktur richtig hinbekommen, wenn niemand mitbekommt, wie die Ausrichtung nachlässt. Das Erste ist eine Momentaufnahme. Das Zweite ist eine Entwicklung.

Dieser Artikel behandelt vier Themen: Was Conways Gesetz eigentlich besagt, warum der „Conway-Drift“ die gefährlichere Fehlerquelle ist, wie man ihn im eigenen Unternehmen diagnostizieren kann und was zu tun ist, wenn man ihn entdeckt hat.

Was das Conway-Gesetz eigentlich besagt

Im Jahr 1968 machte Melvin Conway eine strukturelle Beobachtung, die sich bis heute als bemerkenswert zutreffend erwiesen hat:

Organisationen entwickeln Systeme, die ihre eigenen Kommunikationsstrukturen widerspiegeln.

Das war’s. Die Architektur, die Sie ausliefern, wird dem Organigramm ähneln, nach dem sie entwickelt wurde – ganz gleich, ob das beabsichtigt war oder nicht. Wenn drei Teams einen Compiler entwickeln, erhalten Sie einen Drei-Pass-Compiler. Wenn Ihre Firmware-, Cloud- und Mechanik-Teams nie miteinander kommunizieren, erhalten Sie drei Subsysteme mit einem Niemandsland dazwischen, in dem sich die Integrationsfehler tummeln.

Wichtig ist, dass das Gesetz keine Metapher für Kultur ist. Es handelt sich um eine Aussage über die Kopplung. Jede architektonische Grenze bedeutet gleichzeitig eine Koordinationsgrenze während der Entwicklung. Eine Schnittstelle zwischen zwei Teilsystemen wird zu einer Schnittstelle zwischen zwei Teams. Eine Abhängigkeit, die eine Teamgrenze überschreitet, wird zu einem Meeting, einem Ticket, einer Übergabe oder einer Verhandlung. Die Interaktionsstruktur des Systems und die Kommunikationsstruktur der Organisation sind keine zwei getrennten Dinge, die man unabhängig voneinander verwalten kann: Es handelt sich um zwei Sichtweisen auf dasselbe Objekt.

Meistens wird das Conway-Gesetz als Einschränkung betrachtet: als eine Tatsache, die man umgehen muss. Interessanter ist es jedoch, es als Hebel zu nutzen. Wenn man es bewusst einsetzt, kehrt sich das Verhältnis um: Man kann auswählen die gewünschte Architektur festlegen und anschließend Teams zusammenstellen, die diese umsetzen. Das ist die umgekehrtes Conway-Manöver, und darauf kommen wir später noch zurück. Vorerst geht es darum, dass sich Architektur und Organisation – bewusst oder unbewusst – gemeinsam weiterentwickeln. Wenn man nur das eine steuert, wird man vom anderen gesteuert.

Die Ausrichtung lässt auf natürliche Weise nach

Das Problem ist folgendes: Ein junges Unternehmen hat in der Regel eine klare Vorstellung von seiner Produktarchitektur, und die Organisationsstruktur leitet sich daraus ab. Doch im Laufe der Zeit entwickelt sich die Architektur weiter: Ein Teilsystem wird ausgegliedert, eine neue Plattformfunktion entsteht, eine Neuausrichtung auf den Markt verändert die Anforderungen an das Produkt.

Auch die Organisation entwickelt sich weiter, nach ihrem eigenen Zeitplan: Mitarbeiter verlassen das Unternehmen, Teams werden aus Budgetgründen zusammengelegt, bei einer Umstrukturierung wird eher ein Personalziel als ein architektonisches Ziel verfolgt. Die beiden Strukturen waren einst aufeinander abgestimmt. Nun weichen sie nach und nach ein wenig voneinander ab, und keine einzelne Entscheidung kam jemals wie die falsche vor.

Ein etabliertes Unternehmen kann natürlich eine Umstrukturierung durchführen, um diese Fehlausrichtung zu korrigieren. Wenn dies funktioniert, laufen die Abläufe tatsächlich schneller – für ein oder zwei Quartale, bis sich die beiden Strukturen wieder voneinander entfernen. Häufiger jedoch lehnen Teile der Organisation die Veränderung stillschweigend ab. Die Kästchen werden im Organigramm verschoben, doch die alten Kommunikationswege bleiben bestehen. Ein gewisses Maß an Abstimmung ist besser als gar keine, doch die Effizienz, die die Umstrukturierung versprochen hat, stellt sich nie ganz ein.

Warum “Drift” der Teil ist, der wehtut

Das heißt Conway-Drift: Architektur und Organisation entkoppeln sich nach einer anfänglichen Angleichung allmählich voneinander. Grenzen, die einst übereinstimmten, driften auseinander, da sich die eine Seite schneller entwickelt als die andere. Und da dies schrittweise geschieht, löst es niemals einen Alarm aus. Es gibt keinen Vorfall, keinen Ausfall, keinen Moment, der die Unternehmensleitung auf den Plan ruft. Es gibt lediglich einen stetigen Anstieg der Koordinationskosten, mit dem sich alle abfinden.

Der Schaden ist subtil, summiert sich jedoch. Wenn die Diskrepanz nicht behoben wird, wird die Kohärenz auf Systemebene untergraben. Widersprüchliche Sichtweisen werden nicht mehr durch Entwurf und beginnen, durch Kompromiss. Ein Beispiel dafür ist das Integrationsmeeting, bei dem sich zwei Teams auf einen Kompromiss einigen, weil keines von beiden die Gesamtverantwortung trägt. Das vorhersehbare Ergebnis ist ein Produkt, dem es an konzeptioneller Integrität mangelt und das keinen der Beteiligten besonders gut zufriedenstellt. Im Diagramm modular, in der Praxis verworren.

Die Automobilindustrie hat dies vor aller Augen durchlebt. In den 2020er Jahren hatten etablierte Autohersteller Mühe, ihre Organisationen an die Architektur elektrischer und softwaregesteuerter Fahrzeuge anzupassen. Die „Mechanical-First“-Organisationsstruktur, die ein Jahrhundert lang Fahrzeuge mit Verbrennungsmotor baute, passt nicht mehr zu einem Fahrzeug, dessen Wert zunehmend in der Software und der zentralisierten Rechenleistung liegt. Die Architektur hat sich verändert. Die Organisation hat sich nicht mit ihr mitbewegt. „Conway’s Drift“ im industriellen Maßstab! Und dadurch entstehen genau jene Koordinationsprobleme erneut, die die neue Architektur eigentlich hätte beseitigen sollen.

Das ist das Grausame daran. Man kann die architektonische Arbeit korrekt ausführen und trotzdem den alten Koordinationsaufwand erben – einfach weil das menschliche System dem technischen nicht gefolgt ist.

So wird die Diagnose gestellt

Conway Drift bleibt verborgen, weil es sich nie zu erkennen gibt. Man muss also danach suchen. Hier sind einige Diagnoseschritte, vom einfachsten bis zum aufwendigsten:

Teamgrenzen mit den architektonischen Grenzen abgleichen

Legen Sie die Aufgliederung Ihrer aktuellen Architektur und Ihr aktuelles Organigramm übereinander. Markieren Sie, wo ein Team für eine klar abgegrenzte Komponente verantwortlich ist – und wo die Zuständigkeiten sich überschneiden. über eine architektonische Grenze. Jeder Ort, an dem sich Zuständigkeiten und Architektur nicht decken, ist ein potenzieller Drift-Punkt. Wenn ein einzelnes Teilsystem zwei Teams untersteht oder ein Team für drei lose miteinander verbundene Bereiche zuständig ist, kommt es dort zu Koordinationslücken.

Beobachten Sie, wo die Koordination tatsächlich stattfindet. 

Falls Ihr Produkt sieht aus Modularität – doch das Thema Integration taucht immer wieder in Besprechungen, bei der Übergabe von Aufgaben und bei Integrationsengpässen zum Quartalsende auf: Die Modularität existiert nur auf den Folien, nicht im System. Wiederkehrende Integrationsfehler, die sich entlang bestimmter Teamgrenzen ziehen, sind ein deutliches Anzeichen dafür. Ebenso wie die Aussage “Wir brauchen alle in einem Raum, um das fertigzustellen” für etwas, das laut Architektur eigentlich unabhängig sein sollte.

“Wir brauchen alle hier im Raum” ist ein Anzeichen für den „Conway-Drift“.

Verfolgen Sie Ihre letzte Umstrukturierung bis zu ihrem Auslöser zurück. 

Fragen Sie sich bei einer kürzlich erfolgten organisatorischen Umstrukturierung: Wurde sie durch eine konkrete architektonische oder strategische Veränderung ausgelöst oder durch etwas anderes, wie beispielsweise einen Haushaltszyklus oder die Führungsspanne eines Managers? Umstrukturierungen, die nicht in der Architektur verankert sind, führen dazu, dass Abweichungen entstehen eingeführt, nicht korrigiert.

Viele Umstrukturierungen führen zu Conway-Drift, anstatt ihn zu beseitigen.

Prüfen Sie, ob die Anreize noch mit der Struktur übereinstimmen. 

Bei „Drift“ geht es nicht nur um Kästchen in einer Tabelle. Kennzahlen und Anreize, die auf eine frühere Organisationsstruktur abgestimmt sind, werden Teams still und leise wieder in die alten Grenzen zurückdrängen, ganz gleich, wie man diese neu definiert. Das Verhalten richtet sich nach den Anreizen, nicht nach den erklärten Prioritäten.

Wenn Sie einen schnelleren, strukturierten Einstieg suchen, geben Sie Ihre Situation in den Anti-Pattern-Finder. Conway-Drift gehört neben folgenden Beispielen zur Familie der Anti-Muster der Organisationsentwicklung: Gefrorene Struktur (die Organisation bleibt immer gleich, während sich das Produkt ändert) und Das Theater der Umstrukturierung (Die Struktur ändert sich ständig, jedoch ohne architektonische Absicht). Der Finder hilft Ihnen dabei, zu benennen, welche Sie gerade betrachten. Eine präzise Benennung ist wichtig, da die drei Fehler auf den ersten Blick ähnlich aussehen, jedoch gegensätzliche Reaktionen erfordern: Bei „Frozen Structure“ müssen Sie bewegen, „Reorganization Theater“ braucht dich, um Hör auf, dich wahllos zu bewegen, und Conway Drift braucht dich, um sich zielgerichtet auf ein bestimmtes Ziel zubewegen.

Was kann man dagegen tun?

Eine Diagnose ohne Reaktion ist nichts als Angst. Sobald man die Abweichung ausgemacht hat, gibt es drei sich ergänzende Maßnahmen.

1. Wenden Sie das umgekehrte Conway-Manöver an

Anstatt die Struktur, die sich aus der derzeitigen Organisationsform ergibt, einfach hinzunehmen, sollten Sie die Teamgrenzen so gestalten, dass produzieren die gewünschte Architektur. Wenn bei einem Produkt eine klare Trennung zwischen beispielsweise einem Sensor-Subsystem und einem Cloud-Backend erforderlich ist, ist die Bildung von zwei Teams mit einer klar definierten Schnittstelle zwischen ihnen ebenso sehr eine architektonische wie eine organisatorische Entscheidung. So funktioniert das SpaceX führt ein großes Entwicklungsprojekt durch: Gruppen, die mit physischen und funktionalen Modulen verbunden sind – Starship, der Booster, die Zylinderabschnitte, der Startturm –, wobei jede Gruppe über eigene Bereiche für Software, Maschinenbau, Beschaffung und Qualitätssicherung verfügt, die über stabile, klar definierte Schnittstellen miteinander verbunden sind. Die Teams arbeiten als Kunden und Lieferanten miteinander zusammen, anstatt sich hinter einer zentralen Projektleitung anzustellen. Das Organigramm ist die Architektur – ganz bewusst.

2. Die Organisation gezielt umgestalten

Der „Conway-Drift“ verleitet zu zwei gleichwertigen, aber gegensätzlichen Fehlern. Der eine besteht darin, die Struktur einzufrieren, um Störungen zu vermeiden, wodurch sich die Kluft weiter vergrößert. Der andere besteht darin, ständig Umstrukturierungen vorzunehmen, wodurch das angesammelte Fachwissen zerstört wird, das langlebigen Teams ihren Wettbewerbsvorteil verschafft. Beides ist dem Produkt nicht dienlich. Eine praktische Heuristik: Eine Refaktorisierung sollte dann erfolgen, wenn der Koordinationsaufwand der aktuellen Struktur die Umstellungskosten für eine Änderung deutlich übersteigt, und zwar nur dann, wenn der architektonische oder strategische Auslöser konkret genug ist, um den Zielzustand zu definieren. Wenn man ohne klares Ziel umstrukturiert, wird daraus nur ein „Reorganisations-Theater“; wartet man zu lange und lässt offensichtliche Reibungspunkte ungelöst, häufen sich organisatorische Schulden an, die sich schnell vervielfachen. Wenn man den Schritt wagt, sollte man den Zielzustand definieren. vorher Du bewegst Menschen, bewegst Menschen mit die ihnen bekannten Komponenten und finanzieren den Wissenstransfer gezielt. Eine Umstrukturierung, die den mühsam erworbenen Fachkontext auflöst, zerstört genau das Kapital, das für eine Steigerung der Geschwindigkeit sorgt.

3. Geben Sie der Verwaltung die Befugnis, die Linie durchzusetzen

Drift entsteht, wenn niemand da ist, dessen Aufgabe es ist, für Kohärenz zu sorgen. Jemand muss die Verantwortung dafür übernehmen, dass Absicht und Einschränkungen des Systems über Übergänge hinweg: Nicht die Umsetzung, sondern die Abstimmung zwischen Struktur und Architektur. Das ist die Aufgabe der Systemverantwortung, und sie funktioniert nur, wenn sie über echte Autorität verfügt. Ein Verantwortlicher, der zwar für die Kohärenz zuständig ist, aber keine Befugnis hat, diese durchzusetzen, sieht dem Abdriften lediglich mit einem besseren Vokabular zu. Kombinieren Sie diese Autorität mit Kennzahlen, die Kompromisse ehrlich aufzeigen, und Eskalationswegen, die Konflikte durch das Design lösen und nicht dadurch, wer in der Besprechung am stärksten darauf drängt.

Das Fazit

Conways Gesetz besagt, dass Ihre Architektur und Ihre Organisation ein und dasselbe System sind, das aus zwei verschiedenen Blickwinkeln betrachtet wird. Es ist schon eine Leistung, beides einmal aufeinander abzustimmen. Aber diese Abstimmung ist kein Zustand, den man erreicht: Es ist ein Zustand, den man pflegen, da sich beide Hälften ständig bewegen und sich selten mit derselben Geschwindigkeit bewegen.

Der Conway-Drift ist die natürliche Folge von Untätigkeit. Er vollzieht sich schleichend, ist unsichtbar und verursacht hohe Kosten – gerade weil niemand bewusst zulässt, dass er eintritt. Die Organisationen, die ihre Dynamik aufrechterhalten, sind nicht diejenigen, die vom ersten Tag an die perfekte Struktur gefunden haben. Es sind diejenigen, die immer wieder prüfen, ob die Struktur noch zum System passt, und die über die Befugnis und die Disziplin verfügen, Anpassungen vorzunehmen, bevor die Abdrift zum Engpass wird.

Legen Sie zunächst Ihre beiden Organigramme übereinander: das von der Personalabteilung gepflegte und das, das sich aus Ihrer Architektur ergibt. Wo immer Abweichungen auftreten, bildet sich bereits Ihr nächster Engpass.