Große Teams, kleine Teams, gleiche Energie
Auf dieser Seite
Alle paar Jahre veröffentlicht IEEE Spectrum die nächste Autopsie katastrophaler IT-Pannen1. Die neueste beziffert allein in den USA mehr als 2 Billionen $ an jährlichen Kosten durch Softwareversagen. Die Fallstudien sind bedrückend vertraut.
Kanadas Gehaltssystem Phoenix blähte sich von 310 Mio. CA$ auf 5,1 Mrd. $ auf und ließ bei 70 % der Bundesangestellten Fehler bei der Bezahlung zurück. Das Horizon-System der britischen Post schickte Unschuldige ins Gefängnis, während die Führung Fehler vertuschte, von denen sie wusste.
Ich habe in Organisationen gearbeitet, die es auf die Liste geschafft hätten, wenn sich jemand die Mühe gemacht hätte, sie aufzuschreiben.
Retrospektiven, die ins Leere laufen
Projekte laufen aus dem Ruder. Es gibt eine Crunch-Phase. Dann eine Retrospektive mit der Frage “was können die Devs besser machen?”, nie “was kann das Management besser machen?”.
Ich habe in diesen Retrospektiven gesessen. In denen alle wissen, was schiefgelaufen ist: Der Scope hat sich dreimal geändert, die Deadline stand fest, bevor es Anforderungen gab, jemand hat einen Manager dazugeholt, der “bei der Koordination helfen” soll, und plötzlich verbringst du mehr Zeit in Standups als mit Code. Aber niemand sagt es, weil es auszusprechen heißt zuzugeben, dass die Struktur das Problem ist.
So viel Macht das mittlere Management über Teamorganisation und Prozesse hat, so gut wie keine Verantwortung trägt es für Ergebnisse. Du würdest Milliarden an Ausgaben sparen und die Produktivität massiv steigern, wenn das Management schlank wäre und wie alle anderen zur Rechenschaft gezogen würde.
Die Steuer der Managementebenen
Große Projekte scheitern nicht, weil Entwickler nicht programmieren können. Sie scheitern, weil jede Managementebene Latenz hinzufügt, Verantwortung verwässert und Anreize schafft, die nicht zum Ausliefern funktionierender Software passen.
Das Muster ist vorhersehbar:
Das Projekt bekommt Budget. Budget rechtfertigt Stellen. Stellen brauchen Manager. Manager brauchen Prozesse. Prozesse brauchen Meetings. Meetings brauchen Dokumentation. Dokumentation braucht Review-Zyklen.
Irgendwo dazwischen sollte jemand Software schreiben.
Jede Ebene existiert, um die darunterliegende zu koordinieren. Aber Koordination kostet: Kontext geht in der Übersetzung verloren, Entscheidungen verzögern sich, weil sie auf Freigaben warten, und Eigenverantwortung löst sich im Komitee auf. Wenn etwas kaputtgeht, sind so viele Leute beteiligt, dass niemand klar zuständig ist.
Das Phoenix-Gehaltssystem musste 80.000 Vergütungsregeln umsetzen. Aber die Regeln waren nicht das Problem. Das Problem war eine Organisation, in der Informationen durch so viele Ebenen flossen, dass oben niemand verstand, was unten wirklich passierte, bis es zu spät war.
Warum kleine Teams funktionieren
Kleine Teams schlagen große. Nicht, weil sie bessere Entwickler haben, sondern weil sie Folgendes haben:
- Kurze Feedback-Schleifen. Du lieferst etwas aus und siehst das Ergebnis.
- Klare Zuständigkeit. Wenn etwas kaputtgeht, weiß jeder, wer es repariert.
- Direkte Kommunikation. Kein Stille-Post-Spiel über drei Managementebenen.
Linear erreichte eine Bewertung von 1,25 Mrd. $ mit 100 Mitarbeitern und 2 PMs. Keine A/B-Tests. Keine Growth-Dashboards. Keine Sprint-Planung. Keine OKRs für ICs. Nur kleine Teams aus Designern und Entwicklern, die wie Produktleute denken.
Das Produkt verkauft sich von selbst, weil es funktioniert. Und es funktioniert, weil fast nichts zwischen den Leuten steht, die entscheiden, und den Leuten, die den Code schreiben. Oft sind es dieselben.
Das ist kein Zufall. Das ist der Punkt.
Der Fehler ist nicht das Wachsen, sondern wie du wächst
Die Lehre ist nicht, dass Organisationen für immer klein bleiben sollen. Manche Probleme brauchen Größe.
Der Fehler ist, nach Managementebenen zu greifen, bevor du sie brauchst. Einen “Director of Engineering” einzustellen, wenn du 8 Entwickler hast. Ein “Project Management Office” zu gründen, weil sich zwei Projekte einmal überschnitten haben. Manager einzustellen, die Manager führen, bevor du bewiesen hast, dass du überhaupt die erste Ebene brauchst.
Jede Ebene, die du hinzufügst, ist eine Wette darauf, dass der Koordinationsaufwand den Koordinationsnutzen wert ist. Die meisten Organisationen verlieren diese Wette und merken es nicht einmal.
Ich habe das aus einem anderen Blickwinkel in meinem Beitrag über Workforce Engineering bei flowstate2 beschrieben. Das Problem der meisten Technologieverantwortlichen ist nicht, dass sie nicht wissen, was passiert. Sie haben Systeme gebaut, in denen Informationen durch so viele Ebenen wandern müssen, dass Wissen unmöglich wird.
Die Antwort sind nicht mehr Manager. Es ist bessere Sichtbarkeit.
Wenn du über das hinaus skalieren musst, was ein einzelnes Team leisten kann, sollte das Ziel sein, die Dynamik kleiner Teams durch Tooling zu erhalten, statt Komplexität durch Hierarchie zu verwalten. Mach Informationen standardmäßig sichtbar. Lass Teams die Ergebnisse von Anfang bis Ende verantworten. Gib Engineering-Leitern die Befugnis, direkt zu koordinieren.
Bei flowstate bauen wir genau das: eine Workforce-Engineering-Plattform, die Organisationen Sichtbarkeit gibt, ohne Berichtshierarchien zu schaffen. Die Blocker sichtbar macht, ohne Status-Meetings zu verlangen. Die die Führung informiert hält, ohne sie zum Flaschenhals zu machen.
Die Chance über 2 Billionen $
Alle wissen, was falsch ist. Es zu beheben verlangt, dass die Mächtigen sich selbst beschränken.
Mittleres Management existiert, weil es der Standard ist. Weil es immer so gemacht wurde. Weil große Budgets nach großen Teams aussehen und große Teams nach Ebenen.
Aber die Belege sind erdrückend. Die Organisationen, die Milliarden in gescheiterte Projekte stecken, haben Tausende Mitarbeiter. Die, die funktionierende Produkte ausliefern, haben oft nur Dutzende.
Der Unterschied ist nicht Talent. Es ist Struktur.
Irgendwann müssen wir aufhören, andere Ergebnisse zu erwarten.