Conway schlägt zurück: Warum kleine Teams zurückkommen

Im ersten Beitrag dieser Serie ging es um die Menschen – wie sie sich als Team organisieren, wenn KI-Agenten zu neuen Teammitgliedern werden. Dieser Beitrag nimmt die nächste Ecke der Triade auseinander: die Organisation und den Teamzuschnitt.

Direkt vorweg die Kernbeobachtung: Die spannendste Entwicklung der KI-Ära ist nicht, dass Teams verschwinden – sondern dass kleine Teams plötzlich wieder mächtig werden.

Damit das Ganze nicht einfach nur unsere Behauptung bleibt, gehen wir doch direkt mit einem Datenpunkt ins Rennen. Bei Amazons Agentic-AI-Sparte erledigen heute 6 bis 8 Leute, wofür früher 30 bis 40 nötig waren. (6) Die naheliegende Frage: Wenn KI so viel Arbeit abnimmt – warum schrumpfen Teams dann nur auf die klassische Größe eines Scrum-Teams (sechs bis acht) und nicht auf zwei oder drei Personen?

Der Artikel erklärt, warum Organisationsdesign in der KI-Ära wichtiger wird, nicht unwichtiger – und gibt Dir wie immer erste Schritte an die Hand, mit denen Du starten kannst.

1. Die alte Grenze: Warum Teams bei rund acht endeten

Im ersten Artikel haben wir gezeigt, dass KI-Agenten als neue Kollegen durchaus eine gute Idee sind – sofern man ihre Grenzen kennt und beachtet. Martin Fowler bringt die Haltung auf den Punkt: Behandle einen KI-Agenten wie einen „zwielichtigen, aber extrem produktiven" Kollegen – nutzbar, aber niemals ungeprüft. (8)

Damit könnte man auf die Idee kommen – und in Deutschland passiert das gerade –, Teams auf einen minimalen Rumpf zu schrumpfen. Selbst in der körperlichen Fertigung hält dieser Traum aber nicht: Adidas eröffnete 2016 hochautomatisierte „Speedfactories" und schloss sie 2019 wieder, weil Roboter mit weichen Materialien und der Skalierung nicht zurechtkamen; Nike landete in seiner Roboter-Fabrik bei mehr Personal als geplant, nicht weniger. (9) Wenn schon das Stanzen von Sohlen die Vollautomatisierung übersteht – wie naiv ist dann der Gedanke, ein ganzes Wissensteam einfach „mit KI" zu ersetzen?

In der Tat sehen wir das auch schon bei dem einen oder anderen Kunden. So wurde kürzlich einem Team-Lead bei der Kommunikation der Stellenstreichung mitgeteilt, dass er die Lücke mit Sicherheit mithilfe von KI schließen könnte. Eine nachvollziehbare Argumentation – mit einem großen Fehler, der am Ende teuer wird.

Aus unserer Sicht hat hier der Irrglaube Einzug gehalten, ein Team sei deshalb so groß, weil man so viele Hände zum Bauen braucht. Das stimmt nicht. Die Obergrenze effektiver Teams lag nie an der Baukapazität, sondern am Koordinationsaufwand.

Fred Brooks hat das schon 1975 vorgerechnet: Die Kommunikationswege in einem Team wachsen quadratisch – nach der Formel n·(n−1)/2. Sechs Leute haben 15 Verbindungen, zwölf schon 66, fünfzig sage und schreibe 1.225. (2) Daraus folgt sein berühmtes Gesetz: „Adding manpower to a late software project makes it later." Mehr Köpfe heißt eben nicht automatisch mehr Output (und schon gar nicht Outcome), sondern erst einmal mehr Abstimmung.

Richard Hackman kam aus der Teamforschung zum selben Schluss: Die Zahl der zu managenden Verbindungen wächst fast exponentiell mit der Teamgröße; ab rund zehn Personen verwaltet ein Team mehr, als es liefert. (3) Schon 1913 hatte Maximilien Ringelmann gemessen, dass die Leistung pro Person sinkt, je größer die Gruppe wird – teils aus Koordinations-, teils aus Motivationsverlust. (4)

Deshalb existieren Faustregeln wie Amazons „Zwei-Pizza-Team" oder das „10 oder weniger" des Scrum Guide. Sie sind keine Willkür, sondern die organisatorische Antwort auf ein hartes Limit menschlicher Abstimmung. Wer das ignoriert, baut keinen schnelleren Apparat, sondern einen größeren Flaschenhals.

2. Was KI verschiebt: vom Programm zum Team

Wenn die Teamgröße aus Koordination kam und nicht aus Baukapazität (Kapitel 1) – warum brauchten wir dann überhaupt mehrere Teams? Zwei Gründe, und der zweite ist der interessantere.

Der erste ist schlichte Menge: Die Arbeit überstieg die Kapazität eines Teams, also verteilte man sie – und zahlte den vollen Koordinations-Aufpreis (Programm-Manager, Plannings, Integration).

Der zweite ist Wissensbreite: Kein Achter-Team hält das ganze nötige Spezialwissen – Frontend, Backend, Datenbank, Security, Domäne. Weil ein Team bei ~8 gedeckelt ist, hängte man weitere Teams an, um Wissensdomänen abzudecken. Das Programm war oft weniger ein Mengen- als ein Wissens-Konstrukt.

Genau hier greift KI am tiefsten: Sie skaliert nicht nur Output, sondern Reichweite. Ein einzelner Experte greift mit KI in Nachbardomänen hinein, die früher eigene Köpfe brauchten – tiefer, schneller, einfacher. Salopp: Wissen auf Abruf, ein Nachschlagewerk auf Steroiden. Sinkt die Zahl der nötigen Wissensträger, sinkt die Zahl der Teams – und das Programm-Gerüst darüber kollabiert. Die Inference-Engine für Amazon Bedrock entstand mit sechs Engineers in 76 Tagen statt mit 30 in 12–18 Monaten. (6)

Aber hier endet das schöne Bild: KI erweitert die Reichweite, nicht das Urteil. Und anders als ein echtes Nachschlagewerk ist dieses unzuverlässig – es halluziniert gelegentlich überzeugend. Es gilt also: prüfen statt vertrauen. Der Backend-Experte erreicht jetzt Frontend-Antworten; ob er auch erkennt, wann eine subtil falsch ist, entscheidet sich an der Kompetenzgrenze aus Kapitel 1. Deshalb schrumpft das Team nicht auf eine Person. Was bleibt, ist die kleine Einheit, die Urteil, Gegenprüfung und Verantwortung trägt.

Und das ist – ehrlich gesagt – eine gute Nachricht, kein Drohbrief: Dasselbe Team stemmt jetzt einen deutlich größeren Auftrag. Amazon nennt es „gleiche Leute, größerer Charter" – also gleiche Köpfe, größerer Verantwortungsbereich. Wer Ambition wachsen lässt, gewinnt Schlagkraft, statt Stellen abzubauen. Die Kehrseite gehört zur Ehrlichkeit: Wert verschiebt sich von der Ausführung zum Urteil – wer dort mitwächst, liefert mehr in derselben Zeit. Und das sollte man, denn die Möglichkeit steht allen offen; wer sie liegen lässt, wird von denen überholt, die sie nutzen.

3. Conway als Bauplan, nicht als Schicksal

Hier kommt das Gesetz ins Spiel, dem keine Organisation entkommt. Melvin Conway formulierte 1968: Systeme spiegeln die Kommunikationsstrukturen der Organisation, die sie baut. (1) Drei Teams, die kaum miteinander reden, produzieren drei schlecht integrierte Komponenten – ganz egal, was die Architektur-Folie behauptet. Wer einen Monolithen in Microservices zerschneidet, ohne die Organisation anzupassen, bekommt einen verteilten Monolithen: dieselbe Verflechtung, jetzt übers Netzwerk verteilt.

Die produktive Wendung daraus heißt Inverse Conway Maneuver: Schneide die Teams bewusst so, dass die gewünschte Architektur entsteht – statt die zufällige Architektur Deines Orgcharts hinzunehmen. In der KI-Ära wird das mächtiger, weil das Umschneiden billiger wird – kleine Teams brauchen weniger Koordination, und KI deckt die Wissensbreite, für die man früher zusätzliche Spezialisten (und damit zusätzliche Teams) brauchte. Kleine, autonome Teams sind so nicht länger ein Luxus, den man sich mit viel Personal erkauft, sondern der Normalfall.

Wie man konkret schneidet, hat das Modell Team Topologies (Skelton & Pais) auf vier Team-Typen gebracht: (5)

• Stream-aligned: am Wertstrom ausgerichtet – das Primärteam, das liefert.
• Platform: stellt Selbstbedienungs-Dienste bereit, die Stream-Teams beschleunigen.
• Enabling: bringt zeitlich begrenzt fehlende Fähigkeiten ins Team und zieht sich dann zurück.
• Complicated-Subsystem: kapselt Spezialwissen (z. B. komplexe Algorithmik), damit die Stream-Teams es nicht tragen müssen.

Das Leitkriterium ist die kognitive Last: Ein Team darf nur so viel verantworten, wie es geistig wirklich durchdringt. Genau hier hilft KI – sie senkt die Last für Routinen und Spezialthemen – und genau hier lauert die Falle, wenn man einem kleinen Team im KI-Rausch einen zu großen Charter aufbürdet.

Drei Schnitt-Heuristiken, die sich bewähren: am Wertstrom schneiden, nicht an der Technik – ein Team besitzt eine Nutzer-Reise end-to-end; ein Team = ein Charter, den es kognitiv trägt – lieber Spezialwissen in ein Platform- oder Complicated-Subsystem-Team auslagern als überladen; Übergaben über Teamgrenzen minimieren – jede Kreuzung kostet Koordination. Oder mit Ghostbusters: Kreuzt niemals die Ströme.

In der Tat setzen wir genau das gerade mit mehreren Kunden um – einmal eher zufällig über eine Zell-Organisation (10), einmal mit einem sauberen Schnitt entlang der Wertströme (11). In beiden Fällen lässt sich – neben den üblichen Schmerzen einer Umstellung – dasselbe beobachten: Viele Teams, zunehmend aus Menschen und KI-Agenten, übernehmen die erweiterte Verantwortung ausgesprochen gern, weil sie mit mehr Selbstbestimmung und Selbstverwirklichung einhergeht. Ehrlich bleibt aber auch: Nicht alle wollen das – und dieser Unterschied bleibt auf Dauer nicht folgenlos.

Bei denen, die mitziehen, ist das Ergebnis bemerkenswert. Bei einem Kunden entstand praktisch aus dem Nichts ein komplett neuer Geschäftsbereich – mit Millionenumsatz und drei neuen Teams, besetzt mit Menschen, die in der ursprünglichen Organisation kaum noch klar zugeordnet waren. Die durch KI frei gewordene Kapazität wurde also nicht abgebaut, sondern in neue Wertschöpfung umgelenkt. Genau das ist der Unterschied zwischen „Stellen streichen" und „Charter vergrößern".

4. Der neue Zuschnitt: fluide, aber verantwortlich

Bisher war Re-Organisation teuer – aber nicht wegen der einzelnen Teams, sondern wegen der Menge an Menschen. Dass der Koordinationsaufwand überproportional mit der Kopfzahl wächst, haben wir in Kapitel 1 gesehen: Kommunikationswege wachsen quadratisch (Brooks), und der Einsatz des Einzelnen sinkt mit der Gruppengröße (Ringelmann (4)). Steiner bündelt beides als „process loss". (13) Empirisch ist das gut belegt: Große Software-Teams brauchen für denselben Umfang ein Vielfaches an Aufwand und produzieren mehr Fehler – optimal sind oft drei bis sieben Leute. (14) Ein ganzes Programm aus 30–40 Personen neu zu schneiden, war deshalb ein Großprojekt für sich.

Genau hier setzt KI an: Sie senkt die Zahl der nötigen Menschen und Teams (Kapitel 2). Weniger Köpfe bedeuten weniger Kommunikationswege – und damit drastisch geringere Koordinations- und Formungskosten. Man rangiert kleine Einheiten, statt ein 40-Personen-Programm neu zu verdrahten. So wird Umschneiden billig.

Das verschiebt auch die Haltbarkeit von Teams. Bisher ließ man sie lange zusammen, weil ein eingespieltes Team zu formen Zeit kostet – „Forming, Storming, Norming, Performing" (Tuckman) (12) – und sich diese Investition über Jahre amortisieren musste („Velocity"). Sinkt der Preis fürs Formen, schwächt sich diese Logik ab. An ihre Stelle kann ein fluideres Modell treten, eher wie in der Filmproduktion: Ein Team formiert sich um ein Problem und löst sich danach wieder auf. Ehrlich gesagt ist das bislang eher Beobachtung aus der Praxis als gesicherte Empirie – aber die Richtung zeichnet sich ab.

Fluide heißt aber nicht beliebig. Zwei Grenzen bleiben:

• Erstens der Bus-Faktor: Eine Person allein ist ein Single Point of Failure, kein Team. Die kleine Gruppe existiert auch, damit Wissen geteilt und Urteil gegengeprüft wird.
• Zweitens die Verantwortung: Auch das fluideste Team braucht jemanden, der für das Ergebnis geradesteht. KI darf einspringen, aber sie übernimmt keine Haftung. Und wenn wir sie erwischen, hören wir eigentlich immer nur „Good catch!“.

Und ein neuer Gedanke gehört in jeden Zuschnitt: Das Team besteht künftig aus Menschen und Agenten. Die relevante Einheit ist nicht mehr „acht Personen", sondern „acht Personen plus ihre Agentenflotte". Wer Teams plant, plant Token-Budgets und Agenten-Zuständigkeiten mit – wie Amazon, das KI-Token bereits wie Betriebskosten verbucht. (6) Dazu kommen wir aber mit Sicherheit im Technik-Teil.

Wie ist Dein Team geschnitten?

Eine ehrliche Standortbestimmung – diesmal entlang der Frage, wie nah Dein Zuschnitt am Wertstrom liegt:

Dein Ziel ist nicht Level 4 über Nacht. Es ist, die Silos von Level 1/2 zu verlassen – denn dort frisst Conway jede KI-Beschleunigung wieder auf, bevor sie beim Kunden ankommt.

Chancen und Risiken – eine ehrliche Abwägung

Chancen

• Kleine Teams werden wieder mächtig: Mehr Ownership, kürzere Wege, weniger Programm-Overhead – das alte Zwei-Pizza-Versprechen, jetzt für größere Vorhaben.
• Architektur nach Absicht: Wird das Umschneiden billig, kannst Du die Organisation an der gewünschten Architektur ausrichten, statt umgekehrt.
• Dynamische Engpass-Überbrückung: Fehlt eine Fähigkeit, springt KI als temporärer Pair-Partner ein – im Rahmen der Kompetenzzone und unter Verantwortung des Teams.

Risiken

• Der verteilte Monolith aus Teams: Teams umschneiden, ohne die Architektur mitzudenken, verschiebt die Komplexität nur. Schneller wird dadurch nichts.
• Bus-Faktor & Wissensverlust: Wenn pro Aufgabe nur noch eine Person plus KI arbeitet, droht das geteilte mentale Modell zu erodieren – Wissen lebt dann gefährlich nah am Einzelnen.
• Überladener Charter: Ein Team hat eine begrenzte kognitive Last; wird sie überschritten, sinkt die Leistung – das ist der Kern von Cognitive Load Theory (7) und Team Topologies. (5) Einem kleinen Team im KI-Rausch zu viel aufzubürden, sprengt genau diese Grenze. Tückisch dabei: Mit KI kippt die Qualität leise, weil die gefühlte Produktivität täuscht (siehe Post-Agile-Beitrag).
• Survivorship Bias: Amazon ist KI-nativ, mit Spitzenleuten und eigenen Tools. Die Zahlen zeigen eine Richtung, kein Versprechen für eine gewachsene Organisation.

Monday Morning Actions: 3 Schritte für morgen früh

1. Der Conway-Check (30 Min.): Zeichnet euer Orgchart und eure Systemarchitektur nebeneinander. Wo sie sich spiegeln, ist alles gut. Wo eine saubere Architektur quer zu euren Teamgrenzen liegt, habt ihr euren ersten Umbau-Kandidaten gefunden.
2. Den Wertstrom suchen: Nehmt eine wichtige Nutzer-Reise und fragt: Wie viele Teams muss sie durchqueren? Jede Übergabe ist Koordinationskosten. Ziel ist ein Team, das diesen Strom besitzt.
3. Einen Engpass per KI statt per Stelle überbrücken: Wo ihr gerade „mehr Leute" fordern würdet, prüft zuerst, ob KI die fehlende Fähigkeit im bestehenden Team überbrückt – bewusst als Experiment, mit klarer Verantwortung.

Offene Fragen und nächste Schritte

1. Wie überträgt sich „AI-nativ" auf gewachsene Organisationen? Nächster Schritt: In einem Bereich einen ehrlichen Vorher-Nachher-Vergleich aufsetzen – mit und ohne Anpassung des Teamzuschnitts.
2. Wie verhindern wir den Bus-Faktor-Effekt? Nächster Schritt: Auch in kleinen, KI-gestützten Teams feste Review- und Pairing-Rituale verankern, damit Wissen geteilt bleibt.
3. Wie planen wir Agenten als Teammitglieder? Nächster Schritt: Agenten-Zuständigkeiten und Token-Budgets in den Teamzuschnitt aufnehmen, nicht nur Köpfe.

Fazit: Schneide bewusst, sonst schneidet Dein Orgchart

KI macht Teams nicht überflüssig – sie macht den bewussten Zuschnitt erst richtig wertvoll. Die kleine Einheit kommt zurück, weil ihre Grenze nie aus der Baukapazität kam, sondern aus Koordination und Urteil; was kollabiert, ist das teure Gerüst darüber. Und Conway bleibt gnadenlos: Du bekommst die Architektur, die Deine Organisation abbildet – ob Du sie geplant hast oder nicht.

Die eigentliche Führungsaufgabe ist deshalb nicht „KI einführen", sondern „Teams für die Architektur schneiden, die wir wollen". Das Werkzeug nimmt Dir das Bauen ab. Den Schnitt nicht.

Bilder und sonstige Dankeschöns!

• Titelbild: Foto von Brett Jordan auf Unsplash

Quellen

• 1 – Conway, M. E. (1968) Quelle: How Do Committees Invent?, Datamation. Aussage im Text: Conways Gesetz – Systeme spiegeln die Kommunikationsstrukturen der bauenden Organisation; daher „verteilter Monolith" bei Microservices ohne Org-Anpassung. Fundort: Kernthese des Aufsatzes. Link: melconway.com
• 2 – Brooks, F. P. (1975) Quelle: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Aussage im Text: Kommunikationswege wachsen quadratisch (n·(n−1)/2: 6 = 15, 12 = 66, 50 = 1.225); „Brooks’s Law" – Koordinationsaufwand deckelt die Teamgröße, nicht die Baukapazität. Fundort: Kapitel zum Aufwand der Intercommunication / „Brooks’s Law". Link: Wikipedia-Übersicht
• 3 – Hackman, J. R. (2002 / 2009) Quelle: Leading Teams: Setting the Stage for Great Performances (HBS Press); pointiert in „Why Teams Don’t Work", Harvard Business Review (2009). Aussage im Text: Zu managende Verbindungen wachsen fast exponentiell mit der Teamgröße; ab rund zehn Personen überwiegt der Koordinationsaufwand. Fundort: Argument zur Teamgröße; HBR-Interview. Link: hbr.org (2009)
• 4 – Ringelmann, M. (1913) Quelle: „Recherches sur les moteurs animés: Travail de l’homme", Annales de l’Institut National Agronomique – „Ringelmann-Effekt". Aussage im Text: Die Leistung pro Person sinkt mit wachsender Gruppengröße (Koordinations- und Motivationsverluste). Fundort: Originaluntersuchung zum Tauziehen / Gruppenleistung. Link: Übersicht (Wikipedia)
• 5 – Skelton, M.; Pais, M. (2019) Quelle: Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. Aussage im Text: Vier Team-Typen (stream-aligned, platform, enabling, complicated-subsystem), drei Interaktionsmodi, kognitive Last als Grenzkriterium, „Inverse Conway Maneuver". Fundort: Kernframework; Kapitel zu Team-Typen und Conway. Link: teamtopologies.com/key-concepts
• 6 – Sivasubramanian, S. / AWS (2026), berichtet von GeekWire Quelle: Todd Bishop: „Two pizzas and a prototype: How agentic AI is rewiring Amazon’s teams", GeekWire, 16.06.2026 (Interview + AWS-Blog). Aussage im Text: 30–40 → 6–8 Personen; Bedrock-Engine mit 6 Engineers in 76 Tagen statt 30/12–18 Monate; „gleiche Leute, größerer Charter"; KI-Token werden wie Betriebskosten verbucht. Fundort: Abschnitte „Back to two pizzas", „Bigger goals, same team". Link: geekwire.com
• 7 – Sweller, J. (1988) Quelle: Cognitive Load During Problem Solving: Effects on Learning. Cognitive Science, 12(2), 257–285. Aussage im Text: Das Arbeitsgedächtnis ist begrenzt; übersteigt die kognitive Last seine Kapazität, bricht die Verarbeitung ein. Wissenschaftliche Wurzel des „team cognitive load"-Konzepts (Team Topologies). Fundort: Kernthese der Cognitive Load Theory. Link: Wiley – Cognitive Science
• 8 – Fowler, M. / Thoughtworks Quelle: Exploring Generative AI (Artikelserie auf martinfowler.com). Aussage im Text: KI-Output wie einen „zwielichtigen, aber sehr produktiven" Kollegen behandeln – nutzbar, aber konsequent zu prüfen. Fundort: Artikel „Exploring Generative AI" und zugehörige Memos. Link: martinfowler.com
• 9 – Schuh-Automatisierung: Adidas Speedfactory & Nike (2019) Quelle: CNN/Quartz zur Schließung der Adidas „Speedfactories" (2019/20); IndustryWeek/MH Education zu Nikes Automatisierungs-Schwierigkeiten. Aussage im Text: Vollautomatisierte Schuhfertigung scheiterte weitgehend – Adidas schloss seine Roboter-Fabriken; Nike endete mit mehr Personal als geplant. Beleg gegen den „einfach wegautomatisieren"-Reflex. Fundort: Berichterstattung zur Speedfactory-Schließung bzw. zu Nikes Fabrik-Problemen. Link: CNN (Adidas) · IndustryWeek (Nike)
• 10 – Hermann, S.; Pflaeging, N. (2019) / Haier Quelle: Cell Structure Design (Red42); reales Vorbild: Haiers „RenDanHeYi" mit über 4.000 Mikro-Unternehmen (je 10–15 Personen). Aussage im Text: Organisationsdesign rund um Wertschöpfung statt um Funktionen – dezentrale, autonome Zellen als Schnitt-Muster. Fundort: Cell-Structure-Design-Konzept; Haier-Fallbeispiel. Link: redforty2.com · Haier RenDanHeYi
• 11 – Kersten, M. (2018) Quelle: Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press (aufbauend auf Womack & Jones, Lean Thinking). Aussage im Text: Wertstrom = die end-to-end-Aktivitäten, die einem Kunden über ein Produkt Wert liefern; Organisation entlang von Wertströmen statt Silos. Fundort: Definition Value Stream / Flow Framework. Link: itrevolution.com
• 12 – Tuckman, B. W. (1965) Quelle: Developmental Sequence in Small Groups. Psychological Bulletin, 63(6), 384–399. Aussage im Text: Teams durchlaufen Phasen („Forming, Storming, Norming, Performing"); ein eingespieltes Team zu formen kostet Zeit – was historisch für lange, feste Besetzungen sprach. Fundort: Phasenmodell der Teamentwicklung. Link: Übersicht (Wikipedia)
• 13 – Steiner, I. D. (1972) Quelle: Group Process and Productivity. Academic Press. Aussage im Text: Tatsächliche Gruppenleistung = Potenzial − Prozessverluste; diese (Koordinations- und Motivationsverluste/Social Loafing) nehmen mit der Gruppengröße zu. Fundort: Modell „actual = potential productivity − process loss". Link: Übersicht (Steiner’s Taxonomy)
• 14 – Putnam, D. / QSM (2005) Quelle: QSM-Studien zur Teamgröße (Doug Putnam), u. a. „Team Size Can Be the Key to a Successful Software Project". Aussage im Text: Große Teams liefern bei gleichem Umfang nur marginal schneller, kosten aber ein Vielfaches an Aufwand und produzieren mehr Defekte; optimal oft 3–7 Personen. Fundort: Auswertung von Projektdaten nach Teamgröße (Effort, Schedule, Defect Density). Link: qsm.com