TL;DR: Ein Software-Unternehmer mit 8 Entwicklern steckte fest: Sein erfahrenster Mann hielt das gesamte Wissen, glaubte nicht ans Projekt und bremste das Team. Der Inhaber hat ihn weder gekündigt noch überzeugt — er hat die Aufgabenverteilung so umgebaut, dass das Team unabhängig von ihm liefern konnte. Ergebnis: Statt Monate auf eine Datenmigration zu warten wurde das ERgebnis in wenigen Wochen erreicht, Teamstimmung gedreht.
Wenn der Beste im Team gleichzeitig der Bremser ist
Montag-Meeting, acht Entwickler am Tisch. Der Inhaber stellt den Plan für die neue Software vor. Sein erfahrenster Entwickler — 470.000 Zeilen Legacy-Code im Kopf, der Einzige, der die zentrale Business-Logik und die gesamte Datenbank beherrscht — sagt: „Wir schaffen das nicht." Und weil die anderen sieben zu ihm aufschauen, nicken sie. Das Projekt ist tot, bevor es begonnen hat. Ein Entwickler, der gleichzeitig unersetzbar wirkt und alles blockiert — aus dieser Falle sehen die meisten Inhaber keinen Ausweg.
Wie der Inhaber das Team am Engpass vorbeisteuerte
Der Inhaber hatte dieses Muster jahrelang akzeptiert. Wenn sein Chefentwickler sagte „Das braucht drei Jahre", dann war das gesetzt. Er fragte nie: Was müsste passieren, damit es in sechs Monaten geht? Er fragte nur: Wie kommen wir mit drei Jahren klar?
Die Arbeit lief auf Zuruf. Kein Ticket-System, keine definierten Arbeitspakete. Kunden riefen Entwickler auf der Privatnummer an. Jeder arbeitete isoliert in seinem Silo. Und der Chefentwickler saß auf dem gesamten Wissen — Projektentwicklung, Datenbankarchitektur, Tagesgeschäft. Er war gleichzeitig die wichtigste Person und der größte Engpass.
Im Coaching mit anne&thorsten. wurde der Hebel klar: Der Inhaber musste aufhören, die Einschätzungen seines Chefentwicklers als unverrückbare Grenzen zu behandeln. Er stellte dem Team eine andere Frage: „Was muss passieren, damit wir die Software Anfang nächsten Jahres an die ersten Kunden ausrollen können?" — mit einer einzigen Regel: Alles ist erlaubt, außer „Es geht nicht."
Dann setzte er sich drei Tage mit seinem designierten Nachfolger hin. Sie verteilten jede einzelne Aufgabe mit Namen. Der Chefentwickler wurde aus den meisten Bereichen herausgenommen und auf eine einzige Aufgabe fokussiert. Ein anderer Entwickler stieg in die Datenmigration ein. Zwei weitere arbeiteten zusammen an der zentralen Businesslogik. Tägliche Stand-ups und zweiwöchige Reviews machten den Fortschritt sichtbar.
Warum Umverteilen wirkt und Überzeugen scheitert
Die naheliegende Reaktion bei einem bremsenden Entwickler: ein Gespräch führen, überzeugen, Erwartungen setzen — oder kündigen. Der Inhaber hat keins von beidem getan. Er hat die Struktur verändert.
Das funktioniert, weil das eigentliche Problem bei einem bremsenden Schlüsselmitarbeiter die Abhängigkeit ist. Solange einer alles weiß und alle anderen auf ihn angewiesen sind, hat er Veto-Macht — egal ob er sie bewusst nutzt oder unbewusst ausübt. Jede Einschätzung, die er gibt, wird zur Grenze für das gesamte Team. Und jeder Inhaber, der diese Einschätzung ungeprüft übernimmt, zementiert die Abhängigkeit weiter.
Der Inhaber hat die Abhängigkeit aufgelöst, indem er das Wissen verteilte und die Aufgaben so schnitt, dass das Team ohne den Chefentwickler vorankommt. Der Chefentwickler arbeitet weiterhin mit — an einer klar abgegrenzten Aufgabe. Er wurde weder gekündigt noch überzeugt. Er wurde eingegrenzt.
Das Ergebnis stützt den Mechanismus direkt: Die Datenmigration sprang von wenigen bearbeiteten Tabellen in mehreren Monaten auf 88 % Abschluss in nur wenigen Wochen — weil drei Entwickler parallel daran arbeiteten statt einer allein. Und als der Fortschrittsbericht diese Zahl zeigte, sagte selbst der Chefentwickler nicht mehr, dass sie es nicht schaffen. Die Teamstimmung drehte sich von „unmöglich" zu „wir kriegen das hin."
Der Inhaber beschrieb es so: „Wir ziehen quasi rechts an ihm vorbei mit dem Team. Und das ist richtig toll."
Selbst-Check: Wie abhängig bist Du von Deinem besten Entwickler?
Stell Dir eine Frage: Wenn Dein erfahrenster Entwickler morgen vier Wochen ausfällt — welche Projekte stehen still? Wenn die Antwort „die meisten" oder „die wichtigsten" ist, dann hast Du kein Mitarbeiter-Problem. Du hast ein Struktur-Problem. Die Lösung liegt darin, das Wissen und die Aufgaben so zu verteilen, dass Dein Team liefern kann — unabhängig davon, ob der Beste mitzieht oder bremst.
Weiterlesen
- Software-Entwickler einstellen ohne Recruiting: Wie ein Inhaber 3 Leute gewann — durch Kultur — Drei neue Mitarbeiter, null Euro Recruiting-Kosten.
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Muss ich einen schwierigen Chefentwickler kündigen, um das Team voranzubringen?
Eine Kündigung ist eine Option, aber selten die erste. Wenn die Abhängigkeit das eigentliche Problem ist, löst Du es schneller durch Aufgabenverteilung und Wissenstransfer. Der bremsende Entwickler kann weiterhin beitragen — auf einem klar abgegrenzten Gebiet, ohne Veto-Macht über das gesamte Projekt.
Wie verteile ich Wissen, wenn nur eine Person den gesamten Legacy-Code kennt?
Fang mit den Aufgaben an, die als nächstes anstehen — nicht mit dem gesamten Codebestand. Setz einen zweiten Entwickler auf das konkreteste Arbeitspaket und lass beide parallel arbeiten. Der Wissenstransfer passiert durch gemeinsames Arbeiten an echten Tickets, nicht durch Dokumentations-Projekte, die nie fertig werden.
Was mache ich, wenn der Rest des Teams dem Bremser folgt?
Das Team folgt dem Bremser, weil er die meiste Erfahrung hat und die Informationshoheit besitzt. Sobald andere Entwickler eigene Fortschritte sichtbar machen — durch Stand-ups, Reviews, konkrete Zahlen — verschiebt sich die Gruppendynamik. Der Fortschritt selbst wird zum Gegenbeweis.
Wie lange dauert es, bis ein Team eigenständig arbeitet, das bisher auf Zuruf funktioniert hat?
Die Struktur — Ticket-System, klare Aufgabenzuteilung, regelmäßige Reviews — lässt sich in Tagen aufsetzen. Bis das Team die neue Arbeitsweise verinnerlicht hat, dauert es 4–8 Wochen. Der Durchbruch kommt, wenn das erste messbare Ergebnis auf dem Tisch liegt und das Team sieht, dass es ohne den Engpass funktioniert.