Eine Flotte schneller Boote statt eines grossen Schiffs
Warum kleine autonome Teams grosse Organisationen uebertreffen -- Lehren aus meiner Zeit bei Microsoft, vier Exits und 25 Jahren im Aufbau von Tech-Unternehmen.
Ich habe den fruehen Teil meiner Karriere bei Microsoft verbracht. Die Talentdichte war aussergewoehnlich — einige der schaerfsten Ingenieure und Produktkoepfe, mit denen ich je zusammengearbeitet habe. Und trotzdem fuehlte es sich an, als wuerde man einen Felsbrocken bergauf durch Treibsand schieben, wenn man etwas Bedeutsames ausliefern wollte.
Eine Entscheidung, die einen Nachmittag haette dauern sollen, verschlang Wochen. Man startete mit einer vernuenftigen Idee und verbrachte dann Tage in Abstimmungsmeetings — Synchronisation mit Partnerteams, Freigaben von Programm-Managern einholen, Stakeholder einbinden, die vage, aber offenbar kritische Meinungen hatten. Bis alle ihren Senf dazugegeben hatten, war die urspruengliche Idee zu etwas abgeschliffen worden, das niemanden begeisterte, aber alle tolerieren konnten. Das ist die Krankheit des grossen Schiffs. Das Talent ist Weltklasse, aber das System verwandelt Geschwindigkeit in Konsens.
Diese Erfahrung hat alles gepraegt, was ich seitdem getan habe. Ueber vier Exits und 25 Jahre im Aufbau und der Skalierung von Tech-Unternehmen hinweg bin ich immer wieder zur selben Ueberzeugung zurueckgekehrt: Eine Flotte schneller Boote wird ein grosses Schiff jedes einzelne Mal ueberholen.
Warum grosse Schiffe langsam werden
Es ist keine Boesartigkeit. Es ist Physik.
Koordinationskosten skalieren quadratisch mit der Teamgroesse. Fred Brooks hat uns das 1975 gesagt, und wir lernen es immer wieder neu. Ein Team von 5 Personen hat 10 Kommunikationskanaele. Ein Team von 15 hat 105. Ein Team von 50 hat 1.225. Jede zusaetzliche Person fuegt nicht nur Kapazitaet hinzu — sie erzeugt Overhead fuer alle anderen.
Abhaengigkeiten sind der stille Killer. Wenn Team A etwas von Team B braucht, bevor es Team C entblocken kann, hat man nicht drei Teams, die parallel arbeiten — man hat eine serielle Pipeline mit vielen wartenden Leuten. Ich habe Organisationen mit Hunderten von Ingenieuren gesehen, in denen der tatsaechliche Durchsatz schlechter war als bei einem einzelnen Squad von acht Personen, weil jede Initiative durch teamuebergreifende Abhaengigkeiten blockiert war.
Dann gibt es die Verwasserung von Verantwortung. Wenn Verantwortung auf zu viele Menschen verteilt wird, gehoert das Ergebnis niemandem. Entscheidungen werden eskaliert, weil niemand falsch liegen will. Prozess ersetzt Urteilsvermoegen, weil es sicherer ist, dem Handbuch zu folgen, als selbst zu entscheiden. Und irgendwann optimiert die Organisation fuer interne Abstimmung statt fuer Kundennutzen.
So landet man in einer Welt, in der das Ausliefern eines kleinen Features ein Quartal dauert und niemand erklaeren kann, warum.
Das Schnellboot-Modell
Die Alternative ist konzeptionell einfach und in der Umsetzung schwierig: Kleine, crossfunktionale Teams mit voller Eigenverantwortung fuer eine Domaene.
Ein Schnellboot besteht aus 5 bis 8 Personen — typischerweise ein Product Manager, ein Designer und eine Handvoll Ingenieure. Sie verantworten einen Problemraum von Ende zu Ende. Nicht nur den Code, nicht nur das Feature, sondern das Problem, die Loesung, das Deployment, das Monitoring und das Geschaeftsergebnis.
Bei dieser Groesse ist Kommunikation natuerlich. Man braucht keine Stand-up-Zeremonie, um zu wissen, was die Teamkollegen machen — man weiss es, weil man vor zwanzig Minuten am Whiteboard mit ihnen gesprochen hat. Entscheidungen fallen schnell, weil die Menschen mit dem Kontext auch die mit der Entscheidungsbefugnis sind. Es ist nicht noetig, ein sechsseitiges Proposal zu schreiben und durch drei Genehmigungsebenen zu schleusen, wenn das ganze Team im selben Raum sitzt und es in einer Stunde klaeren kann.
Die Magie des Schnellboots ist, dass es Eigenverantwortung wiederherstellt. Wenn ein kleines Team eine Domaene vollstaendig besitzt, spuert es das. Die Codequalitaet liegt ihnen am Herzen, weil sie diejenigen sind, die nachts geweckt werden, wenn etwas kaputt geht. Die User Experience ist ihnen wichtig, weil sie taeglich die Metriken sehen. Sie liefern schneller, weil es niemanden gibt, auf den sie warten muessen.
Was “autonom” wirklich bedeutet
Lassen Sie mich klarstellen — autonom bedeutet nicht anarchisch. Hier machen viele Organisationen den Fehler. Sie lesen ueber Spotify Squads oder Netflix Freedom und denken, die Antwort sei, jede Struktur zu beseitigen. Das ist ein Rezept fuer Chaos.
Autonomie funktioniert, wenn sie begrenzt ist. Jedes Schnellboot braucht drei Dinge:
Eine klare Mission. Keine Feature-Liste — ein Problem, das es zu loesen gilt. “Rechnungsbearbeitungszeit fuer Non-PO-Rechnungen um 40% reduzieren” ist eine Mission. “Das neue Dashboard bauen” ist eine Anweisung. Der Unterschied ist enorm, denn die Mission gibt dem Team Spielraum, die beste Loesung zu finden, waehrend die Anweisung sie zu Auftragnehmern degradiert.
Klare Metriken. Das Team muss wissen, wie Erfolg gemessen wird, und diese Metriken muessen in ihrem Einflussbereich liegen. Wenn ein Team fuer eine Conversion Rate verantwortlich ist, aber den Checkout-Flow nicht besitzt, hat man es zum Scheitern verurteilt.
Klare Grenzen. Was ist im Scope, was ist ausserhalb, was sind die nicht verhandelbaren Punkte (Sicherheit, Compliance, Markenrichtlinien, API-Vertraege mit anderen Teams). Innerhalb dieser Grenzen — volle Freiheit in der Umsetzung.
Das ist der Unterschied zwischen Empowerment und im-Stich-lassen. Empowerment bedeutet, einem Team ein Ziel zu geben und es die Route waehlen zu lassen. Im-Stich-lassen bedeutet, es ohne Karte vor die Tuer zu setzen.
Der Hafenmeister, nicht der Kapitaen
Wenn man als CTO oder CPTO eine Flotte von Schnellbooten fuehrt, aendert sich die eigene Rolle grundlegend. Man steuert nicht jedes Boot. Man ist der Hafenmeister.
Das bedeutet in der Praxis drei Dinge. Erstens: Die Richtung vorgeben — sicherstellen, dass die Mission jedes Teams auf eine kohaerente Unternehmensstrategie einzahlt. Die Boote muessen ungefaehr in die gleiche Richtung segeln, auch wenn sie unterschiedliche Routen nehmen. Zweitens: Kollisionen verhindern — sicherstellen, dass Teams keine Arbeit duplizieren, keine inkompatiblen Systeme bauen, keine architektonischen Entscheidungen treffen, die in zwei Jahren Albtraeume verursachen. Hier kommen Plattform-Teams, gemeinsame Standards und leichtgewichtige Architektur-Governance ins Spiel. Drittens: Die Fahrrinne freiraeumen — organisatorische Hindernisse beseitigen, um Ressourcen kaempfen, Teams vor dem Rauschen der Organisation abschirmen, damit sie sich auf ihre Mission konzentrieren koennen.
Was man explizit nicht tut, ist Teams zu sagen, wie sie Dinge bauen sollen. In dem Moment, in dem man beginnt, Implementierungsdetails an ein Team faehiger Ingenieure zu diktieren, hat man das Modell wieder in eine Command-and-Control-Hierarchie mit zusaetzlichen Schritten zurueckverwandelt.
Die Verbindung zum Product Operating Model
Dies ist nicht nur meine persoenliche Meinung aus Erfahrung — es wird durch einige der besten Denkansaetze im Produktmanagement gestuetzt. Marty Cagans Arbeit ueber empowered Product Teams, insbesondere in Empowered und Transformed, legt dasselbe fundamentale Argument dar: Die besten Produktunternehmen fuehren empowered Teams, keine Feature-Teams.
Ein Feature-Team nimmt eine Roadmap von Outputs entgegen und liefert sie ab. Ein empowered Team nimmt eine Reihe von Problemen und Ergebnissen entgegen und findet den besten Weg, sie zu loesen. Die Flotte schneller Boote ist die Organisationsstruktur, die empowered Teams moeglich macht. Man kann keine empowered Teams innerhalb eines grossen Schiffs haben, weil die Abhaengigkeiten und Genehmigungsketten die Autonomie zerstoeren, die Empowerment erfordert.
Ein Muster aus Cagans Arbeit, das ich erfolgreich in mehreren Unternehmen angewendet habe, ist das Product Discovery Team — ein Trio aus Product Designer, Product Owner und Senior Engineer. Dieses kleine Team arbeitet direkt mit Kunden zusammen, um deren tatsaechliche Probleme zu verstehen und schnell Loesungen zu prototypisieren. Es ist eine extrem agile, kundengetriebene und schnelle Art zu entdecken, was gebaut werden soll. Ich habe diesen Ansatz so sehr geschaetzt, dass ich ihn in jeder Organisation, die ich gefuehrt habe, zum Standard gemacht habe.
Hier wird es richtig spannend. Mit den Produktivitaetsgewinnen durch GenAI-Tools wie Claude Code — bei denen ein faehiger Ingenieur einen funktionierenden Produktprototyp in Stunden statt Wochen bauen kann — verschwimmt die Grenze zwischen Discovery und Delivery. Ein Product Discovery Team kann jetzt das Problem entdecken UND eine funktionierende Loesung im selben Sprint bauen. Das bedeutet, dass das, was frueher ein Product Delivery Team von 5-8 Personen war, zunehmend wie ein frueheres Discovery Team von drei Personen aussehen kann. Das Schnellboot ist gerade schneller und kleiner geworden. Ich glaube, das ist die Richtung, in die sich Produktentwicklungsorganisationen bewegen: skalierte Flotten dieser schlanken, discovery-faehigen Schnellboote, von denen jedes einzelne in der Lage ist, vom Kundenproblem zur ausgelieferten Loesung in einem Tempo zu gelangen, das noch vor zwei Jahren unvorstellbar gewesen waere.
Die Kompromisse
Es waere unehrlich zu behaupten, dieses Modell haette keine Kosten. Die hat es definitiv.
Man verliert etwas Konsistenz. Wenn Teams die Freiheit haben, ihre eigenen Ansaetze zu waehlen, werden sie es tun. Ein Team nutzt React, ein anderes Vue. Ein Team schreibt ausfuehrliche Dokumentation, ein anderes liefert schnell und iteriert. Man muss entscheiden, welche Inkonsistenzen wichtig sind (API-Vertraege, Sicherheitspraktiken, Datenformate) und welche man tolerieren kann (interne Tooling-Entscheidungen, Coding-Style).
Man braucht staerkeres Hiring. Das Schnellboot-Modell funktioniert nicht mit Menschen, denen man jeden Tag sagen muss, was sie tun sollen. Man braucht selbstgesteuerte Ingenieure, Product Manager, die strategisch denken koennen, Designer, die Entscheidungen treffen koennen, ohne auf ein Komitee zu warten. Das hebt die Messlatte beim Recruiting erheblich an.
Man muss unterschiedliche Ansaetze tolerieren. Zwei Teams werden aehnliche Probleme auf unterschiedliche Weise loesen. Der Instinkt als Fuehrungskraft wird sein zu standardisieren. Widersteht dem — es sei denn, es gibt einen echten technischen Grund zur Konvergenz. Vorzeitige Standardisierung ist nur zentralisierte Kontrolle in anderem Gewand.
Kommunikation zwischen den Booten erfordert bewusste Anstrengung. Die natuerlichen Kommunikationskanaele innerhalb eines kleinen Teams sind grossartig, aber teamuebergreifende Kommunikation passiert nicht von allein. Man braucht Rituale — Architecture Reviews, Demo Days, gemeinsame Dokumentation — um die Flotte zusammenzuhalten.
Wie man dorthin kommt
Wenn man aktuell ein grosses Schiff steuert und zu einer Flotte wechseln moechte, sollte man nicht versuchen, alles auf einmal umzustrukturieren. So versenkt man das Schiff, bevor die Boote bereit sind.
Mit einem Team anfangen. Eine Domaene waehlen, die relativ eigenstaendig ist, sie mit den besten Leuten besetzen, ihnen eine klare Mission und echte Autonomie geben. Sie sollen das Modell beweisen. Dieses erste Team wird auf Probleme stossen — unklare Grenzen, fehlende Plattform-Faehigkeiten, Widerstand aus dem Rest der Organisation. Gut. Jedes dieser Probleme ist eine Lektion, die das naechste Team einfacher macht.
Die Plattform-Ebene aufbauen. Wenn man mehr Boote in Betrieb nimmt, findet man gemeinsame Beduerfnisse — CI/CD, Observability, Authentifizierung, gemeinsame Datenmodelle. In ein schlankes Plattform-Team investieren, dessen Aufgabe es ist, die Schnellboote schneller zu machen, nicht Prozesse aufzuzwingen oder als Gatekeeper zu fungieren.
Die Messgroessen aendern. Aufhoeren, Output zu messen (ausgelieferte Features, verbrannte Story Points) und anfangen, Outcomes zu messen (Kundenimpact, Geschaeftsmetriken). Das ist der bei Weitem schwierigste kulturelle Wandel, und er ist nicht verhandelbar. Wenn man weiterhin Output belohnt, werden Teams darauf optimieren, Dinge auszuliefern, statt Probleme zu loesen.
Geduld haben. Die Transformation braucht 12 bis 18 Monate, um wirklich Fuss zu fassen. Die ersten Monate werden sich langsamer anfuehlen, waehrend Teams ihre Grenzen finden und Selbstvertrauen aufbauen. Fuehrungskraefte werden nervoes und wollen die Zuegel zurueckziehen. Nicht tun. Die Zinseszins-Effekte echter Team-Autonomie brauchen Zeit, um sich zu materialisieren, aber wenn sie es tun, ist der Unterschied in Geschwindigkeit und Qualitaet transformativ.
Ich habe dieses Muster bei Early-Stage-Startups und bei Unternehmen mit Hunderten von Ingenieuren funktionieren sehen. Der Massstab aendert sich, die Prinzipien nicht. Gebt kleinen Teams echte Verantwortung, geht ihnen aus dem Weg und schaut, was passiert. Jedes Mal werden sie das grosse Schiff ueberholen.