Transparenz um jeden Preis? Warum eine „Lüge“ mein Team rettete

Jörg Reck  January 16 2026 07:17:01 AM

Heute gilt Transparenz als das Nonplusultra moderner Führung.
In Zeiten von New Work, Agile und Radical Candor soll alles offenliegen: Gehälter, Strategien, Ängste und natürlich Deadlines.
Wer Informationen zurückhält, gilt schnell als manipulativ oder „Old School“.

Aber ist totale Transparenz wirklich immer der Schlüssel zum Erfolg?
Oder gibt es Momente, in denen ein Filter – oder sogar eine bewusste Täuschung – das Team schützt und das Ergebnis rettet?

Ein Rückblick in meine frühen Jahre als Entwicklungsleiter hat mich dazu gebracht, dieses Dogma zu hinterfragen.

Die Ausgangslage: Druck, Hierarchie und Lotus Notes

Wir schreiben die Zeit vor dem Agilen Manifest.
Ich war frischgebackener Entwicklungsleiter für ein 5-köpfiges Team im Bereich Lotus Notes.
Die Rahmenbedingungen waren das Gegenteil von heutigen Start-up-Träumen:

• Die Firma kämpfte permanent mit Liquiditätsengpässen.
• Es herrschte strikte Hierarchie; Kommunikation fand fast ausschließlich vertikal statt.
• Wir hatten ein Integrationsprojekt an Land gezogen – technisch anspruchsvoll, Festpreis, Fixtermin. Laufzeit: 6 Monate.
  

Für uns war dieses Projekt überlebenswichtig. Ein Scheitern war keine Option.

Das Manöver: Die künstliche Deadline

In der klassischen Wasserfall-Welt geschieht oft Folgendes:
Ein Projekt wird am Anfang vertrödelt und am Ende bricht Panik aus („Crunch Time“), was zu Fehlern und Burnout führt.
Ich wollte das verhindern.

Meine Entscheidung war, nennen wir es, „kreative Intransparenz“.

Ich wusste, wir hatten 6 Monate Zeit.
Doch vor mein Team trat ich mit einer anderen Botschaft:
„Leute, wir müssen das Ding in 4,5 Monaten fertig haben.“
Ich verlegte den Abgabetermin intern um volle 6 Wochen nach vorne.
Ohne Diskussion, ohne das Wissen des Teams, dass wir eigentlich mehr Luft hatten.

Das Ergebnis: Entspannter Feinschliff statt Panik

Was passierte? Das Team hängte sich rein.
Der Respekt vor dem (vermeintlich) engen Termin sorgte für Fokus.
Es gab kein „Studentensyndrom“ (das Aufschieben von Arbeit bis zur letzten Minute).

Wir wurden fertig. Pünktlich zu „meinem“ Termin.

Und dann geschah das, was in der Softwareentwicklung fast nie passiert:
Wir hatten 6 Wochen Zeit für den Feinschliff.

Während andere Teams in der Endphase oft Nachtschichten schieben, Bugs fixen und Features streichen, konnten wir das Produkt polieren.
Wir testeten, optimierten und machten die Software stabil.

Das Resultat:

1. Der Kunde war begeistert von der Qualität.
2. Die Chefs atmeten auf, weil das Geld sicher war.
3. Das Team war stolz auf die Leistung und ging ohne Burnout aus dem Projekt.
   

Die Moral: Schutz vs. Transparenz

Hätte ich dieses Manöver in einem heutigen, hyper-transparenten Scrum-Team durchziehen können? Wahrscheinlich nicht.
Irgendjemand hätte das Statement of Work (SOW) gelesen, die echte Deadline im Jira gesehen und die „künstliche Dringlichkeit“ als Manipulation entlarvt.
Die Motivation wäre vielleicht gesunken: „Wir haben ja noch ewig Zeit.“

Doch damals war diese Intransparenz ein Schutzschild.

Ich habe den Druck der Firma (Geldnot) und die Gefahr der „letzten Minute“ von meinem Team ferngehalten, indem ich die Realität kuratiert habe.
Ich habe Stress (durch die verkürzte Zeit) erzeugt, um später Stress (durch Panik und Fehler) zu vermeiden.

Fazit

Transparenz ist ein hohes Gut. Sie baut Vertrauen auf.
Aber Führung bedeutet manchmal auch, Komplexität zu reduzieren und Lasten zu tragen, damit das Team sich auf die Arbeit konzentrieren kann.

War es ethisch absolut sauber, mein Team über die echte Deadline im Unklaren zu lassen? Vielleicht nicht.

War es gut für das Projekt, die Firma und die psychische Gesundheit meines Teams? Absolut.

Vielleicht sollten wir uns öfter fragen:
Dient die Transparenz gerade dem Ziel und dem Team? Oder beruhigt sie nur das Gewissen der Führungskraft, die Verantwortung einfach „durchzureichen“?

• Comments [0]