TL;DR: Ein SaaS-Unternehmer mit über 500 Kunden arbeitete 50–80 Stunden pro Woche — als Hauptprogrammierer, Projektleiter und einziger Entscheider gleichzeitig. Innerhalb von sechs Monaten sank seine Arbeitszeit auf 35–40 Stunden, sein operativer Anteil auf 10–15 %. Der Hebel: Er hörte auf, Tasks zu verteilen und Code zu schreiben — und fing an, Erwartungen zu definieren.

50 bis 80 Stunden pro Woche — und das Team kommt trotzdem nicht voran

Ein SaaS-Unternehmer, Marktführer in seiner Nische, über 500 Kunden in der DACH-Region. Er arbeitete zwischen 50 und 80 Stunden pro Woche. Gleichzeitig Hauptprogrammierer, Projektleiter, einziger mit Zugang zu Deployment und Merging. Seine Sprints waren systematisch mit doppelt so viel Arbeit gefüllt, wie das Team schaffen konnte. Deadlines, die seit Monaten abgelaufen waren, standen im Board — ohne Konsequenzen. Seine Frau und Co-Gründerin beschrieb ihn als den Mann, ohne den „das Kartenhaus zusammenfällt".

Eine OP erzwang, was zwei Jahre Reden nicht geschafft hatten

Der Inhaber wusste seit zwei Jahren, dass er aus dem Operativen raus muss. Es passierte nichts. Dann musste er, halb geplant aber nicht aufschiebbar, eine Woche ins Krankenhaus, sechs Wochen Reha, danach eingeschränktes Homeoffice. Das Unternehmen musste ohne ihn funktionieren — zum ersten Mal seit der Gründung 2014.

In den Wochen vor der OP — begleitet durch anne&thorsten. — gab er Schritt für Schritt ab: Merging und Deployment an einen Entwickler, die Tagesplanung ans Team, die Feinverteilung der Sprint-Tasks an den neuen Entwicklungsleiter. Er erstellte Screencasts für den Wissenstransfer. Und er definierte seine eigene Rolle neu: Epics schreiben und Erwartungen formulieren. Keine Tickets mehr abarbeiten.

Das Ergebnis nach der Rückkehr: Der neue Entwicklungsleiter wollte die Verantwortung gar nicht mehr zurückgeben. Das Team führte Dailys, Reviews und Retros eigenständig durch. Der Inhaber löschte die Einladung zum Entwickler-Daily — sein Nachfolger erstellte eine neue, in der der Inhaber nur noch optionaler Teilnehmer war.

Warum das Team vorher nicht eigenständig arbeiten konnte

Der Inhaber glaubte, seine Mitarbeiter bräuchten seine Vorgaben, um arbeiten zu können. Das stimmte — aber aus einem Grund, den er selbst erzeugt hatte. Er schätzte Tasks allein, vergab sie allein, programmierte die komplexen Teile selbst. Seine Leute warteten auf ihn, weil sie ohne seine Freigabe keinen Schritt machen konnten. Und weil er selbst 80 Stunden arbeitete, kamen diese Freigaben spät, lückenhaft oder gar nicht. Das Team konnte ihn nicht ersetzen, weil er nie zugelassen hatte, dass jemand anderes seine Aufgaben lernt.

Das ist der Mechanismus, der in Software-Unternehmen ab fünf Mitarbeitern die Arbeitszeit als Inhaber explodieren lässt: Der Inhaber springt ein, weil es schneller geht. Das Team gewöhnt sich daran. Es baut keine eigene Kompetenz auf. Der Inhaber muss wieder einspringen. Die Schleife beschleunigt sich mit jedem neuen Kunden und jedem neuen Feature.

Der Ausweg fühlt sich kontraintuitiv an: Der Inhaber muss aufhören, die schnellste Lösung zu sein — auch wenn das kurzfristig bedeutet, dass Dinge langsamer laufen oder Fehler passieren. Beim SaaS-Unternehmer aus dieser Geschichte passierte etwas Bezeichnendes: Das Team führte Planning Poker ein, schätzte Tasks zum ersten Mal gemeinsam. Dabei wurden Wissensunterschiede sichtbar, die vorher niemand kannte — weil immer der Inhaber geschätzt hatte. Innerhalb weniger Wochen schaffte das Team erstmals alle geplanten Tasks einer Woche, ohne etwas auf die nächste Woche schieben zu müssen.

Seine Arbeitszeit sank von 50–80 auf 35–40 Stunden pro Woche. Sein operativer Anteil fiel auf 10–15 %. Die Hochsaison im November — seit zehn Jahren eine Stressphase — verlief zum ersten Mal entspannt. In der Weihnachtswoche nahmen er und seine Co-Gründerin erstmals seit zehn Jahren Urlaub.

Dein Selbst-Check für diese Woche

Zähl die Aufgaben in Deinem aktuellen Sprint, die nur Du erledigen kannst — weil nur Du das Wissen, den Zugang oder die Freigabe hast. Wenn diese Zahl über null liegt, bist Du der Engpass. Und Deine 60-Stunden-Woche wird sich mit jedem neuen Kunden verschärfen, weil die Schleife sich selbst füttert.

Weiterlesen

Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.

→ Engpass-Diagnose buchen

Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.

→ Zum 12-Wochen-Kurs

Häufige Fragen

Wie lange dauert es realistisch, bis ein Software-Geschäftsführer seine Arbeitszeit halbieren kann?

Im beschriebenen Fall dauerte es rund sechs Monate — von der ersten strukturierten Übergabe bis zur stabilen 35-Stunden-Woche. Die Dauer hängt davon ab, wie viel Wissen ausschließlich beim Inhaber liegt und wie schnell Übergaben dokumentiert und trainiert werden.

Was passiert mit der Qualität, wenn der Inhaber aufhört, selbst zu programmieren?

Die Angst vor Qualitätsverlust ist der häufigste Grund, warum Inhaber nicht loslassen. Aber: Wenn das Team gemeinsam schätzt und Wissensunterschiede sichtbar werden, steigt die Qualität — weil Fehler früher auffallen und Abhängigkeiten von Einzelpersonen sinken.

Brauche ich einen Entwicklungsleiter, bevor ich operative Aufgaben abgeben kann?

Einen formellen Titel brauchst Du dafür nicht. Du brauchst eine Person im Team, die bereit ist, Verantwortung für Sprint-Planung und Deployment zu übernehmen — und eine klare Definition, welche Entscheidungen diese Person treffen darf. Der Titel kommt danach.

Funktioniert das auch ohne externen Druck wie eine OP?

Ja, aber der Druck muss von irgendwo kommen. Ohne Anlass verschieben Inhaber die Übergabe immer wieder — weil das Tagesgeschäft dringender wirkt. Ein festes Datum, ab dem Du bestimmte Aufgaben nicht mehr erledigst, ersetzt den externen Druck. Das Datum muss verbindlich sein.