[Ihre Organisationsstruktur hat Ihr Software-Schicksal längst bestimmt] – Conway’s Gesetz – 56 Jahre lang unterschätztes Management-Gesetz Transformation der Softwareentwicklung im Zeitalter der KI – Lerne AI langsam 171

Vorwort

• Ihre Softwarearchitektur wird nicht von Ihrem Technikteam „entworfen“, sondern „gewachsen“ – durch Ihre Organisationsstruktur. Dieses 1968 formulierte Gesetz wird in der Ära der KI immer wieder bestätigt.
• Empirische Studien der Harvard Business School zeigen: Organisatorische Distanz ist ein besseres Prädiktor für Softwarefehlerraten als Code-Komplexität. Was Sie als „Technische Schulden“ bezeichnen, ist oft eigentlich „Organisationsverschuldung“.
• Amazons Mikroservices-Imperium, Spotsifys Team-Modell, Apples Siri-Problem – drei Unternehmen mit Billionen-Dollar-Werten illustrieren dasselbe Gesetz durch völlig unterschiedliche Schicksale.
• KI-Agenten betreten nun die Organigramme. Sobald die „Knoten“ in Ihren Teams nicht mehr ausschließlich Menschen sind, wird das Conway-Gesetz auf Weise neu geschrieben, die Sie nicht erwarten.

1968 schrieb ein weitgehend unbekannter Programmierer einen Aufsatz, den die Harvard Business Review mit der Begründung ablehnte, „die These sei nicht bewiesen“. 56 Jahre später ist die Kernthese dieses Aufsatzes zur unumstrittenen Grundregel der Softwareentwicklung geworden – und im Jahr 2026, in dem KI alles neu gestaltet, ist sie wichtiger denn je.

I. Wie ein abgelehnter Aufsatz zur „Gravitationsgesetz“ der Softwaretechnik wurde

Der Prophet, den die HBR ablehnte

Im April 1968 veröffentlichte Melvin Conway in der Zeitschrift „Datamation“ einen sachlich betitelten Aufsatz: „How Do Committees Invent?“.
Die zentrale These dieses Aufsatzes besteht aus einem einzigen Satz – und doch genügt er, um jedem CTO den Schlaf zu rauben:

„Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.“
In einfachen Worten: Die Organisationsstruktur deines Unternehmens ist die direkte Abbildung deiner Software-Architektur.
Conway beschreibt in seinem Aufsatz einen eleganten Fall: Ein Unternehmen beauftragte acht Personen, zwei Compiler zu entwickeln – aufgeteilt in eine Gruppe von fünf und eine von drei Personen. Das Ergebnis? Die Fünfergruppe entwickelte einen fünfstufigen Compiler, die Dreiergruppe einen dreistufigen. Nicht, weil die Technik eine solche Aufteilung erforderte, sondern weil – jeder „seinen“ Arbeitsbereich besitzen wollte.
Conway beschrieb diese Beziehung mathematisch als „Homomorphismus“ – eine strukturerhaltende Abbildung zwischen Organisationsaufbau und Systemdesign. Es ist kein Zufall, keine Ausnahme, sondern ein nahezu mathematisch notwendiges Gesetz.

Ironischerweise reichte Conway seinen Aufsatz ursprünglich bei der Harvard Business Review ein, wurde aber vom Herausgeber mit der Begründung abgelehnt, dass er „sein Argument nicht bewiesen“ habe. Sieben Jahre später zitierte Fred Brooks diesen Gedanken in seinem Klassiker „The Mythical Man-Month“ ernsthaft und benannte ihn offiziell als „Conway’s Law“.
Seitdem wurde eine Beobachtung, die von einem führenden Wirtschaftsmagazin abgelehnt wurde, zu einer der am häufigsten zitierten Gesetzmäßigkeiten der Softwaretechnik. ## Martin Fowlers „Letztes Wort“
Wenn Conway der Kopernikus war, der die Hypothese aufstellte, dann sind die empirischen Studien der letzten zwei Jahrzehnte das Teleskop.
Im Jahr 2022 verfasste Martin Fowler, Chief Scientist bei ThoughtWorks, eine Aussage, die in der Branche weit verbreitet wurde: „Wenn es in der Software-Architektur eine Regel gibt, die von allen Praktikern akzeptiert wird, dann ist es Conway’s Law. Sie ist wichtig genug, um jedes System beeinflusst zu haben, das ich gesehen habe; sie ist stark genug, dass jeder, der versucht, ihr zu widerstehen, scheitern wird.“
Das ist nicht die theoretische Spekulation eines Akademikers im Elfenbeinturm. Fowler beobachtete in Hunderten von Unternehmensberatungen weltweit immer wieder dasselbe Phänomen: Die Organisationsstruktur ist der Schatten des Software-Designs – unabhängig davon, ob das Management sich dessen bewusst ist oder nicht.

Hier liegt eine subtile, aber entscheidende Nuance, die viele übersehen: Fowler spricht von „jedem, der versucht, gegen sie anzukämpfen“, nicht von „jedem, der versucht, sie zu nutzen“. Was ist der Unterschied? Gegen das Conway-Gesetz anzukämpfen bedeutet, Architekturveränderungen erzwungen durchzusetzen, ohne die Organisationsstruktur zu ändern; sie zu nutzen bedeutet hingegen, zuerst die Organisation anzupassen, damit die Architektur „natürlich wächst“.
Dieser Unterschied entscheidet über den Erfolg oder Misserfolg von Digitalisierungsprojekten. In unserem folgenden zweiten Artikel zu Team Topologies werden wir die Schlüsselstrategie des „Inverse Conway Maneuver“ detailliert erläutern – sie basiert genau darauf, dieses Gesetz zu nutzen, statt es zu bekämpfen.

II. Vom Labor zur Front: Drei Studien bestätigen dieses Gesetz

Die „Mirroring-Hypothese“ der Harvard Business School

2012 veröffentlichten MacCormack und Kollegen von der Harvard Business School eine wegweisende Studie, die in der akademischen Welt als „Mirroring-Hypothese“ bekannt wurde.

Die Methode war äußerst geschickt: Sie verglichen kommerzielle Software mit Open-Source-Software, die genau dieselbe Funktion erfüllten. Die kommerzielle Software wurde von hierarchisch strukturierten Unternehmenseinheiten entwickelt, die Open-Source-Software von einer lose vernetzten Community.

Die Ergebnisse bestätigen Conway’s Gesetz: Produkte von lose gekoppelten Organisationen sind signifikant modularer. Eng gekoppelte Unternehmenseinheiten erzeugen auch bei bewusstem Bemühen um modulare Gestaltung Systeme, deren Architektur ihrer organisatorischen Struktur entspricht.

Die Organisationsstruktur wirkt wie ein „Gravitationsfeld“ – man kann ihr kurzfristig widerstehen, doch langfristig wird die Systemarchitektur immer wieder in eine strukturell homomorphe Form gezogen.

Was ist die wahre Lehre dieser Studie für Entscheider? Wenn Ihr Technikteam Ihnen immer wieder sagt: „Wir müssen refaktorieren“, dann ist vielleicht nicht der Code, sondern die Organisation selbst die Ursache, die refaktorisiert werden muss. Doch wie unterscheidet man „technische Schulden“ von „organisatorischen Schulden“? Dazu benötigt man ein systematisches Diagnoseverfahren – das vollständige Bewertungsmodell stellen wir in Artikel 12 „Rahmenwerk zur Entscheidungsfindung bei der Einführung von KI-Entwicklungstools in Unternehmen“ bereit.

Das „Windows Vista-Experiment“ des Microsoft Research

2008 führten Nagappan und Kollegen vom Microsoft Research eine umfangreiche quantitative Studie zum Windows Vista-Projekt durch. Sie wollten eine zentrale Frage beantworten: Welcher Faktor prognostiziert Softwarefehler (Bugs) am besten?

Mögliche Kandidaten waren: Code-Komplexität, Zeilenanzahl, Häufigkeit von Codeänderungen, Erfahrung der Entwickler… und eine Variable, die scheinbar nichts mit „Technik“ zu tun hatte – organisatorische Distanz (d.h. der Abstand zwischen Teams, die verwandte Module entwickeln, innerhalb der Organisationsstruktur).

Die Forschungsergebnisse bereiten vielen Technologie-Optimisten Sorgen: Die organisatorische Distanz ist ein besseres Prädiktor für die Software-Fehlerrate als die Code-Komplexität. Mit anderen Worten: Module, die von Teams entwickelt werden, die im Organigramm „weit voneinander entfernt“ sind, weisen häufiger Bugs auf als Module mit extrem komplexem Code, die von eng zusammenarbeitenden Teams gewartet werden. Die Bugs, die du auf schlechten Code zurückführst, könnten eigentlich auf eine schlechte Organisationsstruktur zurückzuführen sein.

Diese Erkenntnis hat weitreichendere unternehmerische Implikationen, als es auf den ersten Blick scheint: Deine QA-Strategie sollte sich an der Organisationsstruktur orientieren – nicht an der Code-Komplexität. Module, die über Teamgrenzen hinweg entwickelt werden, benötigen strengere Testabdeckung und Review-Prozesse – selbst wenn der Code selbst einfach erscheint. Angesichts des exponentiellen Anstiegs von AI-generiertem Code heute (Copilot generiert bereits 46 % des von Nutzern geschriebenen Codes) wird dieses Prinzip immer kritischer – wir werden diesen Punkt im achten Beitrag am Fallbeispiel von Coinbase im Kontext des „Produktivitätsparadoxons“ detailliert erläutern.

Die „Beschleunigung“ und „verborgenen Risiken“ der DORA-Studie

Das DevOps Research and Assessment (DORA)-Team von Google, angeführt von Nicole Forsgren, Jez Humble und Gene Kim, veröffentlichte die bislang umfangreichste Studie zur Effizienz der Softwarebereitstellung.

Die zentralen Erkenntnisse stimmen stark mit Conway’s Law überein: „Wenn wir eine lose gekoppelte, gut encapsulierte Architektur mit einer passenden Organisationsstruktur kombinieren, können wir nicht nur die Liefergeschwindigkeit und Stabilität steigern, sondern auch bei erheblichem Wachstum der Engineering-Teams ein lineares oder sogar superlineares Produktivitätswachstum aufrechterhalten.“ Doch der DORA-Bericht von 2022 entdeckte auch eine bemerkenswerte Nebenwirkung: Obwohl lose gekoppelte Architekturen die Liefereffizienz steigern, können sie das Burnout-Risiko erhöhen. Möglicher Grund: Wenn Teams hochgradig autonom und voneinander isoliert sind, verlieren Mitglieder das Gefühl für den Gesamtzusammenhang und empfinden eine isolierte „Ich bin nur ein Zahnrad“-Haltung.

Dies ist eine wichtige Erinnerung – Architektur- und Organisationsabstimmung ist kein Allheilmittel: Sie löst Effizienzprobleme, aber kann kulturelle Probleme erzeugen. Eine nachdenklich stimmende Folgerung: Wenn lose gekoppelte Architekturen plus lose gekoppelte Organisationen menschliche Entwickler bereits isoliert fühlen lassen – was passiert, wenn AI-Agenten in diese Teams hinzukommen? AI „fühlt“ keine Isolation, aber Menschen werden noch isolierter. Dieser Aspekt wird selten diskutiert, doch in unseren Recherchen erwähnt ein BCG-Bericht aus dem Jahr 2025 das „Orchestrierungs-Dilemma von Mittelmanagement“ – und genau das ist das zentrale Thema unseres 11. Artikels.

3. Die „Conway-Momente“ dreier Billionen-Dollar-Unternehmen

Amazon: Eine E-Mail, die alles veränderte

Um 2002 herum sandte Jeff Bezos intern bei Amazon die berühmte „API-Mandat“-E-Mail – alle Teams mussten über Dienstschnittstellen (APIs) kommunizieren; direkter Zugriff auf die Datenspeicher anderer Teams war streng verboten. Der letzte Satz dieser E-Mail lautete angeblich: „Mitarbeiter, die diese Vorgaben nicht einhalten, werden entlassen.“ Viele betrachten Amazons Mikroservice-Architektur als technische Entscheidung. Doch aus Sicht des Conway-Gesetzes war Bezos’ Handeln eine organisatorische Entscheidung: Er unterband systematisch die „Abkürzungs-Kommunikation“ zwischen Teams durch Management-Maßnahmen – und die Softwarearchitektur entwickelte sich daraufhin natürlich zu isolierten Dienstmodulen. Dies führte zu Bezos’ späterem Konzept der „Two-Pizza Teams“ – jedes Team darf nicht größer sein, als zwei Pizzen füttern können (typischerweise 5–8 Personen); jedes Team besitzt seinen eigenen Dienst, deployt unabhängig und kommuniziert mit der Außenwelt ausschließlich über APIs. Amazons Mikroservice-Imperium wurde nicht von Architekten entworfen, sondern wuchs aus der Organisationsstruktur heraus. Dies ist das klassischste positive Beispiel des Conway-Gesetzes.

Doch hier gibt es eine Ebene, die viele Artikel nicht erwähnen: Amazons Ansatz war erfolgreich, nicht nur weil Bezos das Conway-Gesetz verstand, sondern weil er gleichzeitig das Problem der „Incentive Alignment“ löste. Jedes „Zwei-Pizza-Team“ besaß seine eigene P&L (Gewinn- und Verlustrechnung) und war nicht nur technisch, sondern auch kommerziell autonom. Das bedeutet, dass die Teams einen intrinsischen Anreiz haben, die Grenzen ihrer Dienste klar zu halten – denn verschwommene Grenzen bedeuten verschwommene Verantwortlichkeiten, und verschwommene Verantwortlichkeiten bedeuten verschwommene Leistungsbewertungen. Die dreieckige Ausrichtung aus Organisationsstruktur, Anreizstruktur und technischer Architektur ist das vollständige Bild des Amazon-Modells. Unternehmen, die nur die Organisationsstruktur kopieren, aber das Anreizdesign ignorieren, erhalten meist nur die Form, nicht den Kern.

Spotify: Das ideale Modell trifft auf die Realität der „Entropiezunahme“

Spotify „Squad-Modell“ wurde einst in der Silicon Valley als Bibel der Organisationsgestaltung verehrt: autonome Teams von 5–8 Personen (Squads), die zu Stämmen (Tribes) zusammengefasst wurden, technische Experten über Tribe-Grenzen hinweg bildeten Kapitel (Chapters), und interessenbasierte Communities bildeten Gilden (Guilds).
Die Design-Philosophie dieses Modells ist hochgradig konsistent mit dem Conway-Gesetz – durch kleine, autonome Teamstrukturen wird die Entstehung kleiner, autonomer Softwaredienste angetrieben.

Aber Spotify selbst gab später zu, dass die Realität viel komplexer ist als das Modell. Wenn das Geschäft auf eine bestimmte Größe wächst, nehmen die Abhängigkeiten zwischen Teams unvermeidlich zu, und reine Autonomie beginnt, Koordinationskosten zu erzeugen. Dies offenbart eine oft übersehene Implikation des Conway-Gesetzes: Die Organisationsstruktur ist nicht etwas, das man einmal entwirft und dann vergisst – sie hat, genau wie Software, eine Tendenz zur Zunahme der Entropie. Mit steigender Geschäftskomplexität verschwimmen die Organisationsgrenzen, werden Kommunikationswege immer länger, und die Systemarchitektur degradiert entsprechend. Eine hervorragende technische Organisation hat nicht „eine gute Architektur entworfen“, sondern hat die Fähigkeit etabliert, die Ausrichtung von Organisation und Architektur kontinuierlich anzupassen. Diese Fähigkeit erläutern wir ausführlich im zweiten Artikel zu Team Topologies – es bietet einen systematischeren und praktischeren Rahmen als das Spotify-Modell. ## Apple: Warum Siri von ChatGPT „zerlegt“ wurde
Im Jahr 2024–2025 wurde Apples Siri-AI-Upgrade-Plan fast zum Gegenbeispiel des Conway-Gesetzes.

Das Problem liegt nicht in der Technik. Apple verfügt über weltweit führende AI-Forschungskräfte und umfangreiche Finanzmittel. Doch die Entwicklung von Siri umfasst zwei Teams, die durch eine strukturelle Kluft in der Organisationsarchitektur getrennt sind: das AI-Forschungsteam (unter der Leitung von John Giannandrea) und das Produktentwicklungsteam (unter der Leitung von Craig Federighi).

Beide Teams haben unterschiedliche Prioritäten, unterschiedliche Rhythmen und unterschiedliche Erfolgskriterien. Das AI-Forschungsteam strebt nach frontier-breaking Fortschritten in der Modellleistung, während das Produktteam auf stabile, benutzerfreundliche Auslieferung fokussiert ist. Wenn die Kommunikationsstrukturen zwischen diesen beiden Organisationsknoten fragmentiert sind, wird das resultierende System zwangsläufig fragmentiert sein.

Was erhalten die Nutzer letztlich als Siri? Einen „funktionellen Patchwork-Assistenten“ – einzelne Module erscheinen solide, doch zusammen fehlt ihnen eine kohärente, intelligente Erfahrung. Genau das ist das Ergebnis, das Conway’s Gesetz vorhersagt: Die Risse im System spiegeln die Risse in der Organisation wider.

Der Fall von Apple ist besonders relevant für chinesische Unternehmensentscheider. Viele Unternehmen durchleben genau dieselbe Krise – AI-Teams und Geschäftsteams gehören unterschiedlichen VPs an, und AI-Implementierungsprojekte verwandeln sich in „politische Auseinandersetzungen zwischen zwei Abteilungen“ statt in „kollaborative Produktlieferung“.

Wenn Ihr Unternehmen die Einführung von KI vorantreibt, schauen Sie zurück auf Ihre Organisationsstruktur: Ist die KI-Kompetenz als eigenständige Abteilung vorhanden oder in die Geschäftsteams integriert? Die Antwort auf diese Frage könnte entscheidender für den Erfolg Ihres Projekts sein als die Wahl des verwendeten KI-Modells.

Vier: Das Zeitalter der KI – Das Conway-Gesetz wird neu geschrieben

Wenn „Organisationsknoten“ nicht mehr nur Menschen sind

Im Jahr 2026 steht das Conway-Gesetz vor seiner tiefgreifendsten Herausforderung seit 1968. Conway ging bei der Formulierung dieses Gesetzes von einer impliziten Voraussetzung aus: Jeder „Knoten“ in einer Organisation ist ein Mensch. Die Kommunikationsstruktur ist eine zwischen Menschen.

Doch heute dringen KI-Agenten in die Organisationsstruktur ein. Claude Code kann mehrstufige Entwicklungsarbeiten autonom ausführen, Stripe’s Minions-System generiert wöchentlich über 1.000 merged Pull Requests, und Cursor hat die Arbeitsweise von 100 % der Ingenieure bei NVIDIA verändert. Laut Gartner stieg die Nachfrage nach Beratung zu Multi-Agent-KI-Orchestrierung im Jahr 2025 um 1445 %.

Was geschieht mit dem Conway-Gesetz, wenn einige Knoten in der Organisation keine Menschen mehr sind?

Die Diskussion dieses Themas wird sich durch den zweiten Teil unserer Serie ziehen — die Episode 10 zum Phänomen „Einer-Mensch-unicorn“, die Episode 11 zu „Conways Gesetz trifft auf AI-Agenten“ und die Episode 14 zu „Agentic Engineering“ — doch hier zunächst drei vorläufige Einschätzungen, um Ihren Denkrahmen zu bilden:

Erstens: Kommunikationsstrukturen werden zu Strategiestrukturen. Menschliche Kommunikation beruht auf Kultur, Verständigung und informellen Interaktionen. Zwischen Menschen und AI-Agenten existiert jedoch kein „Verständnis“ — Sie müssen Interaktionsgrenzen durch explizite Strategien, Regeln und Berechtigungen definieren. Governance-Fähigkeiten ersetzen Kommunikationsfähigkeit als zentrale Variable im Organisationsdesign.

Zweitens: Organigramme werden zu Berechtigungsdiagrammen. Traditionelle Organigramme beschreiben Meldewege und funktionale Aufteilungen. Das „Organigramm“ der AI-Ära ähnelt vielmehr einem gerichteten azyklischen Graphen (DAG), der Fähigkeiten und Einschränkungen definiert: Welcher Agent auf welche Daten zugreifen kann, welche Operationen ausführen darf und unter welchen Bedingungen menschliche Genehmigung erforderlich ist.

Drittens: Institutionelles Wissen wandert vom Menschen zur Strategie. Früher war „Wenn ein erfahrener Mitarbeiter geht, nimmt er das Wissen mit“ ein Schmerzpunkt jedes Unternehmens. In der Zukunft wird entscheidendes Wissen in die Strategien und Kontexte der AI-Agenten kodiert — dies ist sowohl eine Chance (Wissen verliert sich nicht mehr) als auch ein Risiko (Fehler in der Strategie können systematisch verstärkt werden).

Jede Aussage basiert auf umfangreichen Branchenpraktiken und Daten. Beispielsweise liefert der Fall von Klarna ein eindrückliches Beispiel für die dritte Aussage zu „institutionellem Wissenstransfer“: Nach der Entlassung von 40 % der Belegschaft stellte sich heraus, dass das KI-System die impliziten Kenntnisse der entlassenen Mitarbeiter nicht ersetzen konnte, weshalb sie gezwungen waren, erneut einzustellen. Diese Geschichte werden wir in Artikel 9 „Die Klarna-Lektion“ vollständig ausführen.

Die erste und zweite Aussage teilen nicht nur wir. Im Juli 2026 präsentierte der a16z-Podcast „Software in the Age of Agents“ von Seema Amble, Partnerin im a16z Corporate Team, und Steven Sinofsky, ehemaligem CEO von Microsoft Windows, auf Basis ihrer direkten Investitionsbeobachtungen hochgradig konsistente Schlussfolgerungen. Steven brachte den Kern der ersten Aussage auf den Punkt: „The biggest network effect in enterprise software is inside of a company“ – das Netzwerk aus Menschen, Prozessen und Systemen innerhalb einer Organisation ist der wahre Quell der Bindung. Agents können sich nicht durch „Verständigung“ in dieses Netzwerk einfügen, sondern nur durch klare Strategien und Berechtigungen – das ist der praktische Antrieb dahinter, dass Kommunikationsstrukturen zu Strategiestrukturen werden. Seema bestätigte die zweite Aussage aus der Perspektive des Agent-Zugriffs auf Unternehmenssysteme: Sobald ein Agent „ausführt“ (Daten in Systeme schreibt, Buchhaltungsdaten ändert), stößt er sofort auf eine ganze Kette von Fragen – Identität, Anmeldeinformationen, Lizenzplätze, Genehmigungsrechte – die Organigramme werden gerade in Zugriffsdiagramme umgewandelt: „Wer darf auf was zugreifen? Wer genehmigt was?“ Diese beiden Aussagen sind keine Prognosen – sie beschreiben bereits das, was sich in Projekten abspielt, in die Investoren heute investieren. (Gäste: a16z-Partner / ehemalige Microsoft-Executive, VC-Perspektive.)

Fünf: Selbstprüfung: Welchen „Conway-Fehler“ begeht Ihre Organisation?

Wenn Sie bis hierher gelesen haben und denken: „Das alles kenne ich schon“, dann möchte ich Sie bitten, eine Übung durchzuführen.

Nachfolgend finden Sie fünf häufige Muster von Organisations-Architektur-Desynchronisation, die wir auf Basis des Conway-Gesetzes und seiner erweiterten Forschung identifiziert haben. Vergleichen Sie diese mit Ihrer eigenen Organisation und prüfen Sie, welche Punkte zutreffen:

• ❶ Oberflächliche Microservices: Der Code ist aufgeteilt, aber 50 Leute streiten immer noch in einer einzigen Gruppe.
• ❷ Mittelplattform-Illusion: Die Mittelplattform ist zum Kommunikationsflaschenhals für alle Geschäftslinien geworden.
• ❸ AI-Inseln: Die von dem AI-Team entwickelten Modelle können nicht in die Geschäftsprozesse integriert werden, weil sie organisatorisch „auf unterschiedlichen Wegen“ arbeiten.
• ❹ Degradierung der Remote-Zusammenarbeit: Physische Trennung führt zu unnötigen Systemfragmentierungen.
• ❺ Schlechte Integration von Übernahmen: Technische Integration scheitert aufgrund inkompatibler Organisationskulturen.

Nächster Schritt

Dies ist der erste von 15 Artikeln der Serie „Software Engineering im Zeitalter von AI“. Ausgehend vom Conway-Gesetz haben wir eine grundlegende Erkenntnis etabliert: Die Organisationsstruktur bestimmt die Systemarchitektur – das ist keine Metapher, sondern eine empirisch nachgewiesene Kausalität.

Aber die Kenntnis dieses Gesetzes ist nur der Anfang. Die eigentliche Frage lautet: Können wir es umgekehrt nutzen? Indem wir Organisationsstrukturen gezielt gestalten, um das gewünschte Systemarchitektur zu beeinflussen – das ist die Kernidee des „Inverse Conway Maneuver“.
Im nächsten Beitrag „Team Topologies – Organisationsdesign im Post-Agile-Zeitalter“ untersuchen wir, wie Matthew Skelton und Manuel Pais diese Idee zu einer vollständigen, praktisch anwendbaren Methodik entwickelt haben – inklusive vier grundlegender Teamtypen, drei Interaktionsmustern und dem stark unterschätzten Konzept der „kognitiven Last“. Praxisbeispiele von Unternehmen wie Netflix, Adidas und Accenture zeigen: Unter welchen Bedingungen wirkt der Inverse Conway Maneuver, und unter welchen scheitert er?

Reihenhinweis: Diese Serie verfolgt kontinuierlich die neuesten Entwicklungen in AI-Programmierwerkzeugen, Organisationsarchitekturen und Software-Engineering-Paradigmen – etwa die neue Rolle des Conway-Gesetzes im Zeitalter von AI-Agents ab 2026 oder die Reife neuer Tool-Ökosysteme. Folgen Sie dieser Serie, um kontinuierliche Einblicke zu erhalten.

Über diese Serie

„Die Transformation der Softwareentwicklung im Zeitalter der KI“ ist eine tiefgehende Forschungsreihe mit 15 Beiträgen, speziell für technische Entscheidungsträger in Unternehmen. Basierend auf einer systematischen Analyse von über 200 akademischen Papers und Branchenberichten liefert sie Ihnen entscheidungsrelevante Hinweise mit expliziter Evidenzstufe. Weitere Inhalte folgen.

Quellenangaben:

• Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28–31.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
• Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
• Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
• Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
• a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven-Zitat: „The biggest network effect in enterprise software is inside of a company“ + Seema Amble zur Beobachtung, wie Agenten bei der Anbindung an Unternehmenssysteme auf Berechtigungen, Anmeldeinformationen und Lizenzplätze stoßen – stützen Aussage 1 und 2 in Abschnitt 4; Primärquelle: Original-Aufnahme. Standortkennzeichnung: a16z-Partner / ehemaliger Microsoft-Executive, VC-Position. Gäste verifiziert: a16z-Partnerin Seema Amble, ehemaliger Windows-CEO von Microsoft Steven Sinofsky (Board Partner), a16z-Autorin Elena Burger; Ausstrahlung Juli 2026.)