Das Zwei-Personen-Team, das eine Abteilung ersetzt: Wie KI kleine Teams überlegen macht

Drei Leute liefern, wofür eine Abteilung stand

Stell dir ein Softwareprojekt vor, wie es vor fünf Jahren typisch aussah. Ein neues Kundenportal soll entstehen: ein:e Product Owner, zwei Backend-Entwickler, ein Frontend-Mensch, eine QA-Kraft, jemand für DevOps, eine:n Designer:in – und darüber ein Teamlead, der das Ganze koordiniert. Acht Leute, vielleicht neun. Laufzeit: ein knappes Jahr bis zur ersten brauchbaren Version.

Dasselbe Portal baut heute ein Team aus zwei oder drei senioren Generalist:innen mit modernem KI-Werkzeug – und ist schneller fertig. Nicht ein bisschen schneller. Spürbar schneller.

Das klingt nach der üblichen Tool-Euphorie, ist aber etwas anderes. Die interessante Verschiebung liegt nicht darin, dass jede:r Einzelne produktiver geworden ist. Sie liegt darin, dass sich die optimale Teamgröße nach unten verschoben hat. Und ein kleineres Team ist nicht nur billiger – es ist aus strukturellen Gründen schneller. Genau das macht die Sache so unintuitiv: Weniger Leute sind hier nicht der Kompromiss, sondern der Hebel.

Die alte Logik: mehr Umfang, mehr Köpfe, mehr Reibung

Jahrzehntelang folgte der Bau von Software einer einfachen Gleichung. Mehr Umfang verlangte mehr Hände. Mehr Hände verlangten Spezialisierung, weil keine einzelne Person die ganze Breite abdecken konnte. Spezialisierung verlangte Koordination – Übergaben zwischen Backend und Frontend, zwischen Entwicklung und QA, zwischen Design und Umsetzung. Und Koordination verlangte Menschen, deren Job die Koordination selbst war: Manager, Scrum Master, Projektleitung.

Das Tückische daran: Der Aufwand fürs Koordinieren wächst nicht linear mit der Teamgröße, sondern ungefähr mit ihrem Quadrat. Bei drei Leuten gibt es drei Kommunikationskanäle. Bei zehn sind es schon fünfundvierzig. Jede zusätzliche Person muss von jeder anderen abgeholt werden, in Meetings, in Abstimmungen, in Dokumenten, die nur deshalb existieren, weil das Wissen nicht mehr in einen Kopf passt.

Genau das beschreibt Brooks's Law, jene alte Weisheit aus der Softwareentwicklung: Einem verspäteten Projekt noch mehr Leute hinzuzufügen, macht es noch später. Der neue Mensch produziert nicht sofort Wert, er produziert zuerst Koordinationsbedarf. Ein großes Team verbringt einen erschreckenden Teil seiner Energie nicht damit, das Produkt zu bauen, sondern damit, sich selbst zu synchronisieren.

Das war kein Versagen schlechter Organisation. Es war die rationale Antwort auf ein reales Problem: Es gab schlicht zu viel Arbeit für wenige Köpfe, und ein Teil dieser Arbeit verlangte Spezialwissen, das man nicht in einer Person bündeln konnte. Große Teams waren der Preis für großen Umfang.

Was KI aus der Gleichung herausnimmt

Der Punkt ist nun: Ein riesiger Anteil dessen, was Teams groß machte, war gar nicht die anspruchsvolle, denkende Arbeit. Es war die Fleißarbeit – die Masse an Aufgaben, die Hände verlangte, aber kaum Genialität. Und genau diese Masse löst KI gerade auf.

Schau dir an, was in einem Softwareprojekt tatsächlich Zeit frisst:

• Boilerplate und Scaffolding – das immer gleiche Grundgerüst aus Endpunkten, Modellen, Formularen, das jedes Projekt neu braucht.
• Glue-Code – die Verdrahtung zwischen Systemen, Datenbankzugriffe, API-Anbindungen, Format-Konvertierungen.
• Migrationen und Plumbing – das Verschieben von Daten, das Aufsetzen von Pipelines, das Verkabeln der Infrastruktur.
• Erste Entwürfe von allem – die erste Version eines Moduls, eines Tests, einer Dokumentation, eines Konzepts, das man danach nur noch verfeinert.
• Recherche und Ops-Toil – das Lesen von Doku, das Nachschlagen von Fehlermeldungen, das wiederkehrende Wartungsklein-Klein.

Das war nie die Arbeit, für die man die klügsten Köpfe einstellte. Es war die Arbeit, die Köpfe absorbierte – die Begründung, warum man zwei zusätzliche Junior-Entwickler brauchte, einen halben QA-Menschen, jemanden, der sich nur um die Build-Pipeline kümmert. KI erledigt genau diese Schicht inzwischen verlässlich. Sie schreibt das Gerüst, den Glue-Code, den ersten Testfall, den ersten Doku-Entwurf – und sie tut es in Minuten.

Damit verschiebt sich die Reichweite einer einzelnen Person dramatisch. Ein:e seniore Generalist:in mit KI-Unterstützung deckt heute Rollen ab, die früher mehrere Spezialist:innen verlangten: Sie baut das Backend, verdrahtet das Frontend, schreibt die Migration, setzt das Deployment auf – nicht, weil sie in allem Weltklasse ist, sondern weil die KI die Tiefe liefert, wo das eigene Wissen flach ist. Die Person bleibt die Architektin und Urteilsinstanz. Die Fleißarbeit darunter ist nicht mehr ihr Engpass.

Warum weniger Leute selbst ein Multiplikator sind

Jetzt kommt der Teil, den man leicht übersieht. Wenn KI die Fleißarbeit übernimmt, könnte man meinen, das große Team werde einfach produktiver. Stimmt aber nicht im selben Maß – und der Grund ist die Koordination.

Ein dreiköpfiges Team hat drei Kommunikationskanäle und einen geteilten Kontext, der bequem in zwei, drei Köpfe passt. Niemand muss ein Konzept aufschreiben, damit eine andere Abteilung es versteht; man dreht sich um und sagt es. Eine Entscheidung, die in einem großen Team einen halben Sprint kostet – Abstimmung, Ticket, Review, Freigabe –, fällt im kleinen Team in einem Gespräch von zehn Minuten. Das Team, das sich nicht koordinieren muss, gewinnt an Geschwindigkeit, bevor es die erste Zeile schreibt.

Hier wirken zwei Effekte zusammen, und sie verstärken sich:

1. KI senkt die Arbeit, die Köpfe verlangte. Der Umfang, den drei Leute bewältigen, steigt steil.
2. Weniger Köpfe senken die Koordination, die mit dem Quadrat wuchs. Die Reibung, die früher die Hälfte der Energie schluckte, verschwindet fast.

Das Resultat ist nicht „kleines Team schafft etwas weniger, dafür billiger". Das Resultat ist oft „kleines Team schafft mehr – schneller und billiger". Die Produktivität pro Person steigt durch KI; die Produktivität des Teams steigt zusätzlich, weil der quadratische Koordinationsaufwand wegfällt. Genau diese Kombination ist neu.

Die Form des neuen Teams

Wie sieht das Team aus, das diesen Vorteil ausspielt? Es hat ein klares Profil, und es ist fast das Gegenteil dessen, wofür viele Organisationen über Jahre optimiert haben.

Es ist klein – zwei bis fünf Leute, nicht zwanzig. Es ist senior – die Leute haben genug gebaut, um zu wissen, was eine schlechte Idee ist, bevor sie drei Wochen kostet. Es ist generalistisch – jede:r kann das meiste, niemand ist auf einen schmalen Streifen festgelegt. Es ist vertrauensbasiert – Entscheidungen fallen lokal, ohne Freigabekaskade. Und es ist KI-gehebelt – die Werkzeuge sind kein Nice-to-have, sondern fester Teil des Arbeitsmodells.

Die wichtigste Verschiebung steckt in einem alten Begriff. Der „10x-Entwickler", der einsame Held, der das Zehnfache leistet, war immer halb Mythos – und wo es ihn gab, war er ein Risiko, weil alles an einer Person hing. Das neue Äquivalent ist nicht der Einzelne. Es ist das kleine Team als Einheit, das gemeinsam das Zehnfache einer alten Abteilung leistet, ohne deren Reibung. Der Hebel ist von der Person aufs Team gewandert – und das ist robuster, weil mehrere Köpfe den Kontext teilen.

Wir bei nh labs sind genau so ein Team. Das ist hier nicht Theorie, sondern unser Arbeitsalltag: ein kleines, seniores, generalistisch aufgestelltes Team, das mit KI-Werkzeugen Projekte stemmt, für die ein klassischer Dienstleister eine vielköpfige Mannschaft aufgefahren hätte. Und es passt unmittelbar zu unserem Time-to-Software-Denken: Der schnellste Weg von der Idee zur laufenden Software führt nicht über mehr Leute, sondern über weniger Reibung zwischen ihnen.

Wo dieses Bild kippt

An dieser Stelle muss man ehrlich sein, sonst zieht man die falsche Lehre – nämlich „entlasst die Hälfte". Das wäre ein Denkfehler. Kleine Teams sind nicht universell überlegen; sie sind in einem bestimmten Feld überlegen. Es gibt klare Fälle, in denen die alte Logik weiter gilt.

• Wirklich große Oberflächen. Manche Systeme sind schlicht riesig – ein Kernbankensystem, eine landesweite Versicherungsplattform, eine regulierte Medizintechnik-Suite. Wo die schiere Fläche des Problems groß ist und jeder Teil gleichzeitig betreut werden muss, lässt sie sich nicht in drei Köpfe falten, egal wie gut die Werkzeuge sind.
• Tiefe Spezialexpertise. Es gibt Wissen, das KI nicht ersetzt: Kryptografie, die korrekt sein muss, Echtzeit-Steuerungen mit harten Garantien, Domänen wie Aktuariat oder klinische Studien, in denen ein Fehler Menschenleben oder Millionen kostet. Hier ersetzt keine Breite die Tiefe einer echten Spezialistin.
• Wo Skalierung der Org der Punkt ist. Manchmal ist die Größe selbst das Ziel – politisch, vertraglich, regulatorisch. Eine Behörde, ein Konzern mit hundert Stakeholdern, ein Projekt, das Repräsentation vieler Parteien verlangt, wird nicht von drei Leuten getragen, und das ist kein Effizienzproblem.
• Die Junior-Frage. Man kann nicht dauerhaft nur Seniors haben. Seniors entstehen aus Juniors, die jahrelang an echten Problemen lernen durften. Ein Modell, das ausschließlich fertige Generalist:innen einsetzt, verbrennt seine eigene Zukunft. Wer ausbildet, baut bewusst Ineffizienz ein – und das ist eine Investition, keine Verschwendung.

Und ein letzter, nüchterner Punkt: Kleine Teams konzentrieren das Bus-Faktor-Risiko. Wenn das ganze Wissen in zwei Köpfen steckt und einer fällt aus, steht viel still. Was als Stärke beginnt – Kontext in wenigen Köpfen –, ist zugleich die Schwachstelle. Dem begegnet man mit Dokumentation, sauberem Code und bewusst geteiltem Wissen, aber man sollte es nie wegreden.

Was Führung daraus machen sollte

Wer diese Verschiebung ernst nimmt, steuert nicht mehr nach Kopfzahl. Ein paar konkrete Konsequenzen:

1. Stelle für Seniorität und Breite ein, nicht für Masse. Eine:e Generalist:in, der drei Rollen abdeckt, ist mehr wert als drei Spezialist:innen, die sich gegenseitig koordinieren müssen. Lieber wenige sehr gute Leute als viele durchschnittliche.
2. Schneide die Organisation auf kleine, autonome Teams. Zwei bis fünf Leute, die eine Sache von Anfang bis Ende verantworten, ohne Freigabekaskade. Autonomie ist hier kein Kulturbonus, sondern der Geschwindigkeitsmechanismus selbst.
3. Miss Output, nicht Headcount. Die Frage ist nicht „wie viele Leute arbeiten daran", sondern „was ist letzte Woche live gegangen". Kopfzahl als Erfolgsmaß belohnt genau das Falsche.
4. Investiere das gesparte Personalbudget in Werkzeug und in die wenigen Großen. Das Geld, das nicht in fünf zusätzliche Stellen fließt, gehört in erstklassige Tools, in KI-Lizenzen ohne Knausern – und in die Bezahlung der Leute, die das kleine Team tragen. Ein kleines Team gut auszustatten, ist günstiger als ein großes schlecht.

Die Faustregel dahinter ist schlicht: Solange das Problem in wenige Köpfe passt, gewinnt das kleine Team. Erst wenn die Fläche des Problems oder die nötige Tiefe wirklich darüber hinauswächst, braucht es mehr. Die meisten Projekte unterschätzen, wie viel inzwischen in wenige Köpfe passt.

Fazit

Die alte Gleichung – mehr Umfang verlangt mehr Leute – stimmt nicht mehr durchgängig. KI hat die Fleißarbeit aufgelöst, die große Teams überhaupt erst rechtfertigte, und kleine Teams gewinnen obendrein dort, wo es am meisten zählt: bei der Reibung, die mit dem Quadrat der Köpfe wuchs. Beide Effekte zusammen verschieben die optimale Teamgröße spürbar nach unten und die Geschwindigkeit spürbar nach oben.

Das heißt nicht, niemanden mehr einzustellen. Es heißt, anders einzustellen: für Seniorität und Breite statt für Masse, für kleine autonome Einheiten statt für vielschichtige Hierarchien, für Output statt Kopfzahl. Die ehrlichen Ausnahmen bleiben – riesige Systeme, tiefe Spezialdomänen, der Bedarf, Juniors auszubilden, das Bus-Faktor-Risiko. Aber außerhalb dieser Ausnahmen kippt die Rechnung zugunsten des kleinen, senioren, KI-gehebelten Teams.

Wir erleben das jeden Tag selbst. Das Zwei-Personen-Team, das eine Abteilung ersetzt, ist keine Zukunftsvision – es ist die Art, wie gute Software gerade entsteht. Wer das früh begreift, baut schneller und gibt weniger aus. Beides zugleich.