TL;DR: Software-Unternehmer mit 16-Stunden-Tagen und 3.100 Jahresstunden kontrollierte jeden Commit, jedes Deployment, jedes Support-Meeting. Sein Team hatte gelernt, auf ihn zu warten — weil er nie den Raum ließ, eigenständig zu handeln. Als er sich schrittweise aus den Meetings zurückzog, sank seine Arbeitszeit auf 2.700 Jahresstunden, und Support-Anfragen an ihn fielen auf drei pro Woche. Der Hebel war kein Tool und kein neuer Prozess, sondern das Streichen seiner eigenen Präsenz aus den Abläufen.
28.000 Commits doppelt reviewt — und trotzdem alle fünf Minuten ins Postfach geschaut
Ein Software-Unternehmer, Team von rund zehn Leuten, reviewte jeden einzelnen Code-Commit. 28.000 davon doppelt — einmal im offiziellen Repository, einmal in einem privaten Schatten-Repo, das nur er kannte. Er war bei jedem der zwei täglichen Support-Meetings dabei, machte alle Deployments selbst, gab zu jedem Ticket Feedback. Alle fünf bis fünfzehn Minuten checkte er seine Mails, weil er Angst hatte, einen Server-Ausfall zu verpassen. Seine Arbeitszeit: 3.100 Stunden im Jahr. Ein 16-Stunden-Tag war normal. Er wusste, dass er seine 60-Stunden-Woche reduzieren musste. Er wusste nur nicht, wo anfangen, ohne dass alles auseinanderfliegt.
Was passierte, als er einen Kalendertermin löschte
Im Coaching mit anne&thorsten. wurde ein Muster sichtbar: Sein Team hatte über Jahre gelernt, auf ihn zu warten. Wenn ein Monitoring-Alert reinkam, reagierte niemand — weil alle davon ausgingen, dass er ihn sowieso schon gesehen hatte. Als eine Entwicklerin ein Deployment übernehmen sollte, weigerte sie sich. Die Angst, etwas kaputtzumachen, war zu groß. Auf die Frage, ob er ihr je erzählt habe, dass er selbst früher Angst vor Deployments hatte, sagte er: „Nein, habe ich ihr nie erzählt."
Im Juli 2024 strich er den Support-Meeting-Termin aus seinem Kalender — zunächst jeden zweiten Tag. Was er dann beobachtete, überraschte ihn: „Die sind am Lachen, die haben Spaß. Und wenn ich dabei bin, ist es immer so effizient. Nur kein Nebenbei irgendwas machen, durch, durch, durch." Er gab der Entwicklerin vollständigen Zugriff auf die Produktivdatenbank und ließ sie eigenständig deployen. Er kommunizierte dem Team transparent, warum er sich zurückzieht. Im August fuhr er vier Wochen in die Flitterwochen — das erste Mal, dass er so lange weg war. Und nichts Schlimmes passierte.
Der Engpass, den Du selbst erzeugst — und warum „mehr delegieren" ihn nicht löst
Wenn Du als Software-Unternehmer Deine 60-Stunden-Woche reduzieren willst, lautet der Standard-Ratschlag: Delegiere mehr. Stell jemanden ein. Automatisiere. Das Problem: Solange Du in jedem Ablauf steckst, delegierst Du keine Verantwortung — Du delegierst Aufgaben und kontrollierst das Ergebnis hinterher. Dein Team lernt dabei genau eine Sache: abwarten, bis Du draufschaust.
Der Mechanismus dahinter ist simpel. Kontrolle erzeugt Passivität. Wenn der Chef jeden Commit reviewt, prüft niemand sonst ernsthaft. Wenn der Unternehmer selbst bei jedem Meeting sitzt, übernimmt niemand sonst die Moderation. Wenn der Inhaber jedes Deployment freigibt, drückt niemand sonst den Knopf. Das Team ist nicht unfähig. Es ist darauf trainiert, Dich als Engpass zu nutzen.
Der Hebel liegt darin, Deine Präsenz aus dem Ablauf zu streichen — und die entstehende Lücke bewusst offen zu lassen. Im konkreten Fall sank die Jahresarbeitszeit von 3.100 auf 2.700 Stunden. Support-Anfragen an den Inhaber fielen von täglicher Dauerpräsenz auf drei pro Woche. Das passierte, weil das Team begann, sich gegenseitig zu reviewen, eigene Lösungen zu finden, die Support-Dokumentation ohne Auftrag zu überarbeiten. Die Qualität stieg, weil mehrere Augen draufschauten — statt immer derselben zwei.
Das funktioniert, weil Eigenständigkeit kein Skill-Problem ist. Es ist ein Raum-Problem. Solange Du den Raum besetzt, kann ihn niemand anders füllen.
Dein Selbst-Check für diese Woche
Zähle, wie viele Entscheidungen Du diese Woche getroffen hast, die jemand in Deinem Team genauso gut hätte treffen können. Wenn die Zahl über zehn liegt, ist Deine Arbeitszeit kein Kapazitätsproblem. Dann bist Du der Engpass — und Dein 16-Stunden-Tag ist das Symptom, nicht die Ursache.
Weiterlesen
- Arbeitszeit als Geschäftsführer reduzieren: Von 80 auf 35 Stunden — Ein SaaS-Geschäftsführer halbierte seine Wochenarbeitszeit von 80 auf 35 Stunden.
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
Wie lange dauert es realistisch, bis sich die Arbeitszeit spürbar reduziert?
Im beschriebenen Fall vergingen etwa drei Monate vom ersten gestrichenen Meeting-Termin bis zur vierwöchigen Abwesenheit. Die Jahresarbeitszeit sank über zwei Jahre schrittweise von 3.100 auf 2.700 Stunden. Schnelle Ergebnisse kommen durch das Streichen einzelner Termine — der größere Effekt braucht Monate, weil das Team Zeit braucht, Eigenständigkeit aufzubauen.
Was passiert, wenn mein Team Fehler macht, sobald ich mich zurückziehe?
Fehler passieren — und genau das ist der Punkt. Solange Du jeden Fehler vorher abfängst, lernt niemand, mit Fehlern umzugehen. Kläre vorher, welche Fehler passieren dürfen und welche eskaliert werden müssen. Dann hat Dein Team einen Rahmen, innerhalb dessen es selbstständig handeln kann.
Mein Team ist zu klein — ich kann mich nicht einfach rausziehen. Gilt das trotzdem?
Gerade bei kleinen Teams von fünf bis zehn Leuten ist der Effekt am stärksten, weil der Inhaber dort den größten Anteil aller Entscheidungen auf sich zieht. Der erste Schritt ist kein komplettes Rausziehen, sondern ein einzelner gestrichener Termin oder ein einziges Deployment, das jemand anders macht. Klein anfangen, beobachten, wiederholen.
Kann ich als Inhaber Arbeitszeit reduzieren, ohne dass die Qualität leidet?
Im konkreten Fall stieg die Qualität, weil das Team begann, sich gegenseitig zu reviewen statt auf eine einzelne Person zu warten. Mehr Augen auf dem Code und gegenseitige Kontrolle ersetzen die Einzel-Prüfung durch den Inhaber. Eine einzelne Person als Engpass ist das größere Qualitätsrisiko als verteilte Verantwortung.