Management Latency messen: die Mathematik hinter Time-to-Decision

Tech Spec · Time-to-Decision

Warum Management-Latenz die blinde Stelle vieler Dashboards ist

In der IT-Infrastruktur überwachen wir Latenzen im Millisekundenbereich. Wenn der Server-Ping über 200 Millisekunden liegt, gilt das als Incident. Im Management dagegen finden Verzögerungen von 14 Tagen oft kaum Erwähnung.

Budgetentscheidungen, Produktfreigaben, Personalfragen, Priorisierungen oder Eskalationen ziehen sich über Wochen. Trotzdem tauchen sie in keinem Standard-Report auf. Genau hier setzt Management Latency an.

Im Decision-OS behandeln wir Organisationen nicht als Stimmungsraum, sondern als Entscheidungssystem. Die zentrale Frage lautet: Wie schnell wird ein erkanntes Thema in eine dokumentierte Entscheidung übersetzt? Die wichtigste Kennzahl dafür ist die Time-to-Decision.

1. Die Formel: Time-to-Decision berechnen

Time-to-Decision misst die Zeitspanne vom Moment der Erfassung bis zum verbindlichen Beschluss. In einem Decision Log ist das typischerweise die Zeit vom Status Draft oder Ready bis zum Status Decided.

Für Management-Dashboards ist zusätzlich wichtig, ob Sie ab created_at oder ab ready_at messen. Created_at zeigt die gesamte Latenz vom Auftauchen des Themas bis zur Entscheidung. Ready_at isoliert die Wartezeit, nachdem alle Informationen eigentlich vorhanden waren.

2. Das Ampel-System als Benchmark

Rohdaten allein reichen nicht. Ein Führungsteam braucht Schwellenwerte, um Latenz interpretieren zu können. Bewährt hat sich ein einfaches Raster:

• Unter 2 Tage: sehr schnell. Prüfen Sie zusätzlich, ob die Reopen-Rate niedrig bleibt.
• 2 bis 7 Tage: gesunder Standardtakt. Themen werden spätestens im nächsten relevanten Führungsrhythmus entschieden.
• 8 bis 14 Tage: Warnsignal. Entscheidungen verpassen den Wochenzyklus und bauen Decision Debt auf.
• Über 14 Tage: Stau. Hier braucht es Eingriffe in Entscheidungsvorbereitung, Mandat, Forum oder Eskalationslogik.

Diese Grenzen sind keine Naturgesetze. In regulierten Kontexten, Investitionsentscheidungen oder strategischen Weichenstellungen kann eine längere Dauer sinnvoll sein. Entscheidend ist, ob die Dauer bewusst gewählt oder durch Systemreibung erzeugt wird.

3. Cost of Delay: Zeit in Geld übersetzen

Für CFOs, COOs und Business Owner reicht die Aussage „wir entscheiden langsam“ selten aus. Management-Latenz wird ernst, wenn sie wirtschaftlich sichtbar wird. Dafür eignet sich Cost of Delay.

Eine Entscheidung, die zu spät getroffen wird, blockiert nicht nur Kalenderzeit. Sie verzögert Umsatz, verhindert Lernkurven, bindet Kapazität, erhöht Rework und verschiebt Wirkung nach hinten.

Im Dashboard sollten deshalb zwei Kurven sichtbar werden:

• Offene Entscheidungen: wie viele Themen ohne finalen Beschluss im System hängen.
• Kumulierte TtD: wie stark sich Entscheidungsdauer über Zeit aufbaut.

Steigt die Kurve offener Entscheidungen schneller als die Kurve abgeschlossener Entscheidungen, bewegt sich die Organisation auf einen Staupunkt zu. Ab dort frisst die Komplexitätslast die Entscheidungskapazität.

4. Reopen-Rate: die Gegenmetrik zur Geschwindigkeit

Jede Metrik braucht eine Gegenmetrik. Wer nur auf niedrige Time-to-Decision optimiert, erzeugt im Zweifel schnelle, aber schlechte Entscheidungen.

Deshalb gehört zur Time-to-Decision immer die Reopen-Rate. Sie misst, wie häufig bereits getroffene Entscheidungen wieder geöffnet werden.

Eine gesunde Organisation kombiniert Entscheidungsgeschwindigkeit mit Entscheidungsstabilität: niedrige Time-to-Decision, aber auch niedrige Reopen-Rate. Wird TtD niedrig und RoR hoch, entscheidet das System zu hastig. Wird TtD hoch und RoR niedrig, entscheidet es möglicherweise sauber, aber zu langsam.

5. Das Decision Log als Sensor

Narrative Protokolle sind für Management-Telemetrie kaum brauchbar. „Tom und Sarah schauen sich das mal an“ ist kein Datensatz. Ein brauchbares Decision Log braucht klare Felder.

• created_at: wann wurde der Entscheidungsbedarf erfasst?
• ready_at: wann lagen alle relevanten Informationen vor?
• decided_at: wann wurde entschieden?
• owner: wer trägt die Entscheidung?
• forum: wo wurde entschieden?
• status: Draft, Ready, Decided, Reopened oder Killed?
• review_at: wann wird überprüft?

Erst mit diesen Feldern wird das Decision Log zum Sensor. Dann kann ein Führungsteam sehen, ob Entscheidungen im Backlog hängen, ob bestimmte Foren überlastet sind oder ob bestimmte Entscheidungstypen immer wieder neu geöffnet werden.

6. Kill-Rate: die vergessene Fokus-Metrik

Neben TtD und Reopen-Rate lohnt eine dritte Kennzahl: die Kill-Rate. Sie zeigt, wie viele Initiativen bewusst beendet werden.

Eine Kill-Rate von null klingt auf den ersten Blick positiv. In Wahrheit kann sie bedeuten, dass das Portfolio voller Zombie-Initiativen ist: Projekte laufen weiter, obwohl niemand mehr klar sagen kann, welchen Wert sie erzeugen.

Decision-OS behandelt Killed nicht als Scheitern, sondern als Führungsleistung: Etwas wird bewusst beendet, weil es nicht mehr genug Wert, Priorität oder strategische Passung hat.

Fazit: Vom Gefühl zur Evidenz

Viele Diskussionen über Kultur, Mindset oder Geschwindigkeit drehen sich im Kreis, weil sie auf Eindrücken basieren. Management Latency bringt diese Debatte auf eine sachliche Ebene.

Wenn Sie im Führungsteam nicht nur sagen „wir sind zu langsam“, sondern zeigen können: „Unsere Time-to-Decision in kritischen Produktentscheidungen liegt im Median bei 16 Tagen, und 28 Prozent der Entscheidungen werden wieder geöffnet“, verändert sich das Gespräch.

Dann geht es nicht mehr um Gefühl, sondern um Architektur: Welche Entscheidungen gehören wohin? Wer darf entscheiden? Wer muss vorbereitet werden? Welches Forum ist überlastet? Wo fehlt ein Owner? Und wo braucht es ein besseres Decision Log?