5 Gehälter. Output von 2. Und alles hängt an einem einzigen Entwickler. Das ist der Single Point of Failure im Dev-Team: Wenn ein Schlüsselentwickler das gesamte Architekturwissen monopolisiert, entsteht ein Flaschenhals, der Velocity, Teamwachstum und Unternehmensresilienz gleichzeitig bremst. Die Lösung liegt nicht darin, diese Person zu ersetzen, sondern Wissen systematisch zu verteilen und Abhängigkeiten aufzulösen.
Was ist ein Single Point of Failure im Dev-Team?
Ein Single Point of Failure (SPOF) ist eine Komponente, deren Ausfall das gesamte System zum Stillstand bringt. In der IT kennen wir das Konzept von Servern und Netzwerken: Fällt ein zentraler Server aus, steht alles.
Im Dev-Team funktioniert das Prinzip genauso. Nur dass die "Komponente" ein Mensch ist.
Wenn ein einzelner Entwickler der Einzige ist, der die Codebasis wirklich versteht, dann ist diese Person ein Single Point of Failure. Geht sie in Urlaub, stockt alles. Kündigt sie, geht das komplette Wissen mit raus.
Unersetzbar heißt nicht, dass jemand gut ist. Es heißt, dass alle anderen es nicht können.
Laut einer Analyse von TechMiners haben Teams mit einem Bus Factor von 1 ein erhebliches Risiko: Fällt die eine Schlüsselperson weg, kann das Projekt zum Stillstand kommen -- oder muss im schlimmsten Fall komplett neu aufgesetzt werden.
Bus Factor: Die Kennzahl, die jeder Geschäftsführer kennen sollte
Der Bus Factor (manchmal auch Truck Factor oder Lottery Factor genannt) ist eine Kennzahl aus der Softwareentwicklung. Sie beantwortet eine einfache Frage:
Wie viele Personen müssten das Team verlassen, bevor das Projekt in Gefahr ist?
Das Konzept stammt aus dem Software-Projektmanagement der 1990er-Jahre und tauchte erstmals auf der Pattern Languages of Programs-Konferenz 1994 auf. Bus Factor 1 bedeutet: Es reicht, dass eine einzige Person ausfällt, und das Projekt hat ein ernsthaftes Problem. Je höher der Bus Factor, desto besser ist Wissen im Team verteilt.
Wie erkennst du, dass dein Bus Factor bei 1 liegt?
Typische Warnsignale:
- Code Reviews stauen sich, weil nur eine Person die Architektur wirklich versteht.
- Urlaub bedeutet Stillstand. Bestimmte Aufgaben bleiben liegen, bis die Schlüsselperson zurück ist.
- Entscheidungen warten. Technische Fragen werden aufgeschoben, weil "nur der Senior das beurteilen kann".
- Onboarding dauert ewig. Neue Teammitglieder brauchen Monate, weil Wissen nicht dokumentiert ist.
- Ein Name fällt immer. Wenn bei jeder technischen Frage derselbe Name fällt, ist das kein Zeichen von Stärke. Es ist ein Warnsignal.
Warum dein "bester" Entwickler das Problem ist
Hier liegt der Denkfehler, den ich bei vielen Geschäftsführern sehe: Sie verwechseln Abhängigkeit mit Kompetenz.
Ja, der Senior-Entwickler ist gut. Aber wenn alles an ihm hängt, heißt das nicht, dass er unersetzbar gut ist. Es heißt, dass die anderen vier es nicht können. Und das ist ein Strukturproblem, kein Personalproblem.
Die Kosten der Abhängigkeit
- Du zahlst 5 Gehälter und bekommst den Output von 2, weil vier Entwickler auf den einen warten.
- Dein Senior verbringt seine Zeit mit Reviews und Konzeptarbeit statt mit den Aufgaben, für die du ihn eigentlich bezahlst.
- Deine Juniors entwickeln sich nicht weiter, weil der Senior alles selbst macht. Weil es halt schneller geht.
- Du bist in Gehaltsverhandlungen erpressbar, weil du weißt: Wenn der geht, steht alles.
Cape of Good Code zeigt in ihrer Analyse, dass sich Teams häufig auf einzelne Top-Entwickler verlassen. Kurzfristig effizient, aber ein großes Risiko, wenn diese Person krank wird oder kündigt.
Der Senior merkt es selbst
Dein Senior-Entwickler leidet unter der Situation genauso wie du. Er ist überlastet. Er wird bei jeder Frage gestört. Er kann nicht in Ruhe an den wichtigen Dingen arbeiten, weil er ständig als Wissensquelle herhalten muss.
Das ist kein Zeichen von Wertschätzung. Das ist ein Weg ins Burnout. Oder in die Kündigung.
Meine Geschichte: 2 Jahre Bottleneck, ohne es zu merken
Ich spreche hier nicht nur als Berater. Ich habe das selbst erlebt.
Neues Produkt. Mittelständisches Logistikunternehmen. Ich war technischer Leiter, das Team hatte Bock und wir haben richtig Gas gegeben. Ich hab extrem viel selbst gemacht -- Konzepte, Architektur, Code. Ich hatte den Überblick über das große Ganze. Die anderen Entwickler? Haben ihre Bausteine abgearbeitet. Aber das große Ganze? Hatten sie nicht im Blick. Weil ich es ihnen nie beigebracht hatte.
Dann war ich im Urlaub. Bali. Sieben Stunden Zeitverschiebung. Und dann ist das Produktivsystem gecrasht. Einer der größten Ausfälle, die wir hatten. Und ich war nicht da.
Was dann passiert ist, hat mich nachhaltig verändert: Die Jungs haben sich reingekniet. Problem analysiert, Lösung gebaut, System wieder hochgefahren. Ohne mich. Weil sie wussten, dass sie das jetzt alleine schaffen mussten. Es hat nur funktioniert, weil ich nicht da war. Weil ich nicht wie sonst gesagt habe: "Lass mich mal kurz draufschauen."
Danach habe ich dafür gesorgt, dass es nie wieder an mir hängt. Wissen verteilt. Verantwortung abgegeben. Mich bewusst rausgenommen. Bestes, was ich je gemacht habe.
Die Lösung: Den Senior entlasten, nicht ersetzen
Der Reflex vieler Geschäftsführer ist: Mehr Leute einstellen. Oder den Senior ersetzen. Beides löst das Problem nicht.
Mehr Leute verschärfen das Problem sogar, weil noch mehr Entwickler auf den einen Wissensträger angewiesen sind. Und den Senior ersetzen bringt nichts, wenn die Strukturen gleich bleiben. Dann hast du in 12 Monaten einen neuen Single Point of Failure.
Die echte Lösung hat drei Hebel:
1. Wissen dokumentieren und verteilen
Klingt banal. Ist es nicht. In den meisten Dev-Teams steckt das entscheidende Wissen in den Köpfen einzelner Personen. Architektur-Entscheidungen, die vor drei Jahren getroffen wurden. Workarounds für Bugs, die nie sauber gefixt wurden. Kontextwissen über Kundenanforderungen, das nirgendwo steht.
Dieser Wissenstransfer muss aktiv gestaltet werden: Pair Programming, Code Reviews mit Lernfokus, Architektur-Dokumentation. Das kostet kurzfristig Zeit. Langfristig senkt es das Risiko massiv.
2. Juniors in Konzeptarbeit einbinden
Solange der Senior alle Konzepte alleine schreibt, bleiben die Juniors Junior. Sie müssen in die Denkarbeit eingebunden werden -- nicht nur Tickets abarbeiten, sondern mitdenken: Welche Stellen könnten kaputt gehen? Was haben wir nicht bedacht? Welche Alternativen gibt es?
Das macht sie besser. Und es entlastet den Senior.
Wenn du wissen willst, wie das bei euch konkret aussehen könnte: So helfen wir Dev-Teams, den Flaschenhals zu lösen
3. KI als Wissens-Multiplikator einsetzen
Und hier wird es spannend. Heute gibt es einen Weg, der vor zwei Jahren noch nicht existiert hat.
Wie KI den Flaschenhals sprengt
Wenn ich "KI in der Softwareentwicklung" sage, denken die meisten an Code-Generierung. An Copilot, der Funktionen autocompleted. Das ist nicht das, wovon ich spreche.
Ich spreche von KI-Agenten als Wissens-Multiplikatoren.
Ein KI-Agent kann die komplette Codebasis scannen. Patterns erkennen. Die Architektur verstehen. Abhängigkeiten kennen. Das ist die technische Basis.
Aber das Entscheidende: Dein Senior kann dem Agenten sein Wissen diktieren. Erfahrungen, Entscheidungen, Kontext, der nirgendwo dokumentiert ist. Der Agent wird mit der Zeit immer schlauer. Er lernt nicht nur den Code, sondern auch das "Warum" hinter dem Code.
Was dann passiert:
- Dein Junior setzt sich mit dem KI-Agenten hin und arbeitet ein Konzept aus. Welche Stellen könnten kaputt gehen? Was habe ich nicht bedacht?
- Er stellt dem Agenten Fragen, ohne den Senior aus der Arbeit zu reißen. Jederzeit. Ohne schlechtes Gewissen.
- Der Senior reviewt nur noch das Ergebnis. Muss nicht mehr drei Stunden selbst dran sitzen.
Junior lernt. Senior hat Luft. Flaschenhals gesprengt.
Und die KI hat keine einzige Zeile Code geschrieben.
KI ersetzt keine Entwickler. Aber Entwickler mit KI ersetzen Entwickler ohne KI.
Laut Fraunhofer IPA helfen KI-Agenten dabei, "Wissen zugänglich zu machen, aktuell zu halten und teamübergreifend zu nutzen, ohne dass alles manuell gepflegt werden muss."
Konkrete erste Schritte
Du erkennst dein Team in diesem Artikel wieder? Hier sind drei Dinge, die du diese Woche tun kannst:
- Bus Factor ermitteln. Frag dein Team: "Wer von euch versteht Bereich X gut genug, um daran alleine zu arbeiten?" Wenn bei jeder Antwort derselbe Name fällt, weißt du Bescheid.
- Wissensinseln identifizieren. In welchen Bereichen der Codebasis gibt es nur einen Wissensträger? Priorisiere die geschäftskritischen Bereiche.
- Ein Gespräch führen. Sprich mit deinem Senior. Nicht über die Probleme. Sondern darüber, wie du ihn entlasten kannst.
Fazit
Ein Single Point of Failure im Dev-Team ist kein Zeichen von Stärke. Es ist ein Unternehmensrisiko. Der Bus Factor zeigt dir, wie verwundbar dein Team ist -- ein Bus Factor von 1 bedeutet: Eine Kündigung kann alles lahmlegen.
Die Lösung ist nicht, den Senior zu ersetzen. Die Lösung ist, ihn zu entlasten und Wissen zu verteilen. KI-Agenten sind dabei ein neuer, mächtiger Hebel: Sie machen implizites Wissen zugänglich und entlasten deine Schlüsselperson, ohne eine einzige Zeile Code zu schreiben.
Das ist kein Zukunftsszenario. Das machen wir heute. Bei echten Kunden. Mit echten Dev-Teams.
