OKR-Implementierung für Produkt & Operations

Die meisten OKR-Implementierungen scheitern nicht, weil OKRs ein schlechtes Framework sind, sondern weil die OKRs schlecht geschrieben sind – was entweder zu vagen Ambitionen ohne messbare Ergebnisse oder zu Aktivitätszielen (Ich werde X Features ausliefern) führt, die sich als Outcome-Metriken tarnen. Gute Prinzipien für das Schreiben von OKRs: Objectives müssen inspirierend und richtungsweisend sein: „Der unangefochtene Marktführer im Wissensmanagement für CS-Teams im Mittelstand werden“ – nicht „Die Wissensdatenbank verbessern“. Das Objective sollte Fokus und Motivation schaffen, wenn es ohne Kontext gelesen wird. Key Results müssen ergebnisorientiert und binär messbar sein: KRs sollten ausdrücken, was sich in der Welt ändert, wenn das Objective erreicht wird – nicht, was das Team tun wird. SCHLECHTES KR: „Semantische Suchfunktion für die Wissensdatenbank einführen“ (Aktivität). GUTES KR: „Die Suchrate mit Nullergebnissen in der Wissensdatenbank bis Q4 von 18% auf unter 8% reduzieren“ (Ergebnis). Das schlechte KR kann durch die Einführung einer fehlerhaften Funktion abgeschlossen werden; das gute KR ist nur abschließbar, wenn die Funktion tatsächlich funktioniert. Das 70%-Stretch-Prinzip: OKRs sollten auf einem Niveau festgelegt werden, bei dem das Erreichen von 100% eine Überraschung wäre – Teams, die immer 100% ihrer OKRs erreichen, setzen sie zu sicher. Das Ideal ist eine Erreichung von 70–80%, was sowohl ehrgeizige Zielsetzung als auch echten Fortschritt anzeigt. Zu eliminierende Anti-Muster: OKRs, die KPIs mit Zielen sind (eine Metrik beibehalten vs. sie verbessern); OKRs, die als Ergebnisse getarnte Projekte sind; zu viele OKRs (> 3 Objectives und > 4–5 KRs pro Team pro Quartal verwässern den Fokus, anstatt ihn zu schaffen.

Das OKR-Cascading verbindet individuelle Team-OKRs mit den Unternehmens-OKRs, zu denen sie beitragen – wodurch eine Ausrichtung ohne Mikromanagement entsteht. Cascading-Prinzipien: Zuerst Unternehmens-OKRs: Das Führungsteam definiert 3–5 Unternehmens-OKRs für das Quartal, bevor die Teams ihre eigenen schreiben. Ableitung von Team-OKRs: Teams identifizieren, wie ihre Arbeit zu den Unternehmens-OKRs beiträgt – ihre Objectives sollten die Team-Ebene-Version der Beitrag zu einem oder mehreren Unternehmens-Objectives sein. Dies ist „ausgerichtet“, nicht „diktiert“ – Teams haben die Autonomie zu definieren, wie sie beitragen. Einige Team-OKRs passen möglicherweise nicht zu einem Unternehmens-OKR (Infrastrukturarbeit, Teamentwicklung) – diese sind gültig, sollten aber eine Minderheit darstellen. Die Kaskadenfalle vermeiden: Die Anforderung, dass jedes Team-KR mathematisch zu einem Unternehmens-KR aufgerollt werden muss, schafft eine bürokratische Starrheit, die Teams dazu zwingt, ihre Arbeit zu verzerren, um der Aggregation zu entsprechen. Die Verbindung sollte explizit, aber qualitativ sein („das KR unseres Teams trägt zu Unternehmens-KR X bei, weil die Reduzierung der AHT direkt zur Reduzierung der CPT beiträgt“). OKR-Alignment-Reviews: Mitte des Quartals identifiziert ein teamübergreifendes OKR-Review (Product Ops moderiert) Abhängigkeiten – wo das KR eines Teams von der Lieferung eines anderen Teams abhängt. Das Aufdecken dieser Abhängigkeiten verhindert Überraschungen am Quartalsende, bei denen ein Team seine beitragende Arbeit leistet, das KR aber nicht erreichbar ist, weil das abhängige Team nicht pünktlich geliefert hat.

Die OKR-Bewertung (auch „Scoring“ genannt) am Quartalsende ist eine ehrliche Einschätzung des Fortschritts – keine Leistungsbeurteilung. Die Unterscheidung ist wichtig, da die Vermischung von OKR-Scores mit der Leistungsbewertung dazu führt, dass Teams sichere statt ehrgeizige OKRs setzen. Bewertungsansätze: 0,0–1,0 Skala: Jedes KR wird von 0 (kein Fortschritt) bis 1,0 (vollständig erreicht) bewertet. Googles ursprüngliches OKR-Framework zielt auf 0,7 als Durchschnittswert ab: 0,0–0,3 = entweder zu ehrgeizig oder kein Fortschritt; 0,4–0,6 = signifikanter Fortschritt, aber nicht ganz erreicht; 0,7–0,9 = exzellent, leicht gestreckt; 1,0 = entweder erreicht oder zu sicher gesetzt. Binärer Schwellenwert: Für KRs mit einer spezifisch definierten Messung (X von Y auf Z reduzieren) ist die Bewertung unkompliziert: Messen Sie die Metrik am Ende des Quartals und bewerten Sie basierend darauf, wie viel der angegebenen Verbesserung erreicht wurde (Score = tatsächliche Verbesserung / angestrebte Verbesserung). Entscheidungen nach der Bewertung: OKR-Scores beeinflussen vier Entscheidungen. Entscheidungen über das Objective (Sind wir nah genug dran, um dieses Objective als richtungsweisend erreicht zu betrachten? Führen wir es im nächsten Quartal fort oder ändern wir es?); Entscheidungen über den Umfang (Wurden KRs zu ehrgeizig oder zu sicher gesetzt? Nutzen Sie diese Kalibrierung beim Schreiben der OKRs im nächsten Quartal); Entscheidungen über die Ressourcenallokation (Welche Team-OKRs haben wir erreicht? Dieses Team könnte bereit für eine größere Herausforderung sein); Entscheidungen darüber, was gefeiert werden soll (0,7+ bei einem Stretch-KR ist es wert, im All-Hands erwähnt zu werden – die Sichtbarkeit der OKR-Erreichung schafft eine Kultur der ehrgeizigen Zielsetzung).