TL;DR: Gewissenhafte Entwickler fragen zu spät um Hilfe — weil sie es als Schwäche empfinden. Ein Software-Unternehmer mit 15 Mitarbeitern verlor 12 Stunden Arbeit an ein Problem, das er in 30 Minuten hätte lösen können. Die Lösung: eine explizite Zeitgrenze, ab der Fragen Pflicht ist. Ohne diese Regel entscheidet jeder selbst — und die Gewissenhaften entscheiden sich fast immer zu spät.
12 Stunden an einem Problem, das in 30 Minuten lösbar war
Sie schätzt die Aufgabe auf 2 Stunden. Am Ende des Tages meldet sie sich: Die anderen Tickets schaffe ich nicht mehr. 12 Stunden hat sie an diesem einen Problem gearbeitet.
Ihr Chef — ein Software-Unternehmer mit rund 15 Mitarbeitern — fragt sie: Warum hast Du nicht nach 2 Stunden Bescheid gesagt?
Ihre Antwort: Ich wollte Dich nicht nerven.
Er hätte 30 Minuten gebraucht
Einer meiner Klienten hat mir das in einer Coaching-Session erzählt. Ich musste den Satz zweimal sacken lassen.
Er kennt die Codebasis. Er hat das Muster, an dem sie gescheitert ist, schon dreimal gesehen. 30 Minuten hätte er gebraucht, um ihr den Lösungsweg zu zeigen. Stattdessen erfährt er abends, dass 12 Stunden weg sind und 3 Tickets offen.
Sie ist eine seiner besten Entwicklerinnen. Sie macht das aus Gewissenhaftigkeit. Sie will es alleine schaffen. Sie will zeigen, dass sie es kann. Sie will ihm nicht das Gefühl geben, sie braucht Hilfe.
Und genau das ist das Problem.
Er hat mir dann erzählt, wie er selbst mit solchen Situationen umgeht: Wenn er abends an etwas hängt, probiert er 3 Stunden. Dann lässt er es liegen, schläft drüber. Am nächsten Morgen ist die Lösung da. Er hat irgendwann aufgehört, das als Versagen zu sehen.
Sie noch nicht.
Warum die besten Leute am längsten schweigen
Das Muster taucht in meinen Coaching-Sessions mit Software-Unternehmern immer wieder auf. Und es trifft fast nie die Leute, die man erwarten würde.
Schlampige Entwickler fragen schnell. Sie haben keine emotionale Bindung an das Problem. Aber die gewissenhaften, die guten — die verbeißen sich. Weil Fragen für sie heißt: Ich bin nicht gut genug.
Das ist ein Denkfehler. Aber er fühlt sich an wie eine Wahrheit. Und solange es keine explizite Regel gibt, die das Fragen zur Pflicht macht, gewinnt dieses Gefühl. Jedes Mal.
Was passiert ohne Regel: Jeder Entwickler entscheidet selbst, ab wann „zu lang" ist. Die Maßstäbe sind komplett unterschiedlich. Der eine fragt nach 20 Minuten. Die andere nach 12 Stunden. Beide glauben, sie handeln richtig.
Das Ergebnis: Du erfährst von Problemen erst, wenn Deadlines platzen. Du kannst nicht helfen, weil niemand Dich fragt. Und Du verstehst nicht, warum Dein Team, das aus guten Leuten besteht, Schätzungen so systematisch reißt.
Der Hebel ist eine Zahl. 1 Stunde, 2 Stunden — die genaue Grenze ist zweitrangig. Was zählt: dass sie existiert und dass jeder sie kennt. „Wenn Du doppelt so lang brauchst wie geschätzt, meldest Du Dich. Kein Vorwurf, kein Erklären-Müssen. Einfach melden."
Das nimmt die Entscheidung weg von der Einzelperson und macht sie zum Teamprozess. Die Gewissenhaften brauchen genau das — eine Erlaubnis, die von außen kommt, weil sie sich selbst keine geben.
Der Software-Unternehmer aus der Session hat das direkt am nächsten Tag eingeführt. Keine lange Diskussion, kein Prozess-Dokument. Ein Satz im Daily: Ab sofort gilt — wenn die Schätzung um den Faktor 2 überschritten wird, wird gefragt. Das war's.
Wie Du merkst, ob Dein Team dieses Problem hat
Schau Dir an, wie Schätzungen und tatsächliche Zeiten bei Deinen besten Leuten auseinanderlaufen. Wenn die Abweichung bei den erfahrenen Entwicklern größer ist als bei den unerfahrenen, fehlt keine Kompetenz. Dann fehlt die Erlaubnis zu fragen.
Eine Frage für Dein nächstes Daily: „Ab wann meldet Ihr Euch, wenn Ihr feststeckt?" Wenn darauf Stille kommt, hast Du Deine Antwort.
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 setze ich eine Zeitgrenze ein, ohne dass sich Entwickler kontrolliert fühlen?
Die Regel muss als Erlaubnis formuliert sein. „Melde Dich nach 2 Stunden" klingt nach Überwachung. „Wenn Du doppelt so lang brauchst wie geschätzt, frag — das ist erwünscht" gibt die Entscheidung frei. Du machst Fragen zur Stärke, nicht zum Eingeständnis.
Was mache ich, wenn mein Team sagt, sie brauchen keine solche Regel?
Vergleiche Schätzungen mit tatsächlichen Zeiten über 2 Wochen. Wenn die Abweichungen bei erfahrenen Leuten genauso groß oder größer sind als bei Junior-Entwicklern, schweigen sie zu lang. Die Daten zeigen es, auch wenn das Gefühl im Team ein anderes ist.
Gilt das auch für remote Teams?
Gerade dort. Im Büro bekommt ein Teamlead mit, wenn jemand seit Stunden grübelt. Remote sieht er nur das Ergebnis — oder eben das fehlende Ergebnis am Ende des Tages. Eine explizite Zeitgrenze ersetzt die Beobachtung, die remote wegfällt.
Welche Zeitgrenze ist die richtige?
Die genaue Zahl ist weniger wichtig als die Existenz der Regel. Ein bewährter Startpunkt: doppelte Schätzung. Wer 2 Stunden schätzt und nach 4 Stunden noch keine Lösung hat, meldet sich. Ihr könnt die Grenze nach ein paar Wochen anpassen — aber fangt mit einer konkreten Zahl an.