Grundlagen
Warum OKRs existieren, was einen Output von einem Outcome trennt, und wie ein gut geformtes OKR-Set aussieht. Diese drei Fragen tauchen in fast jedem Coaching-Gespraech auf. Wer sie am Anfang klaert, spart viel Korrekturarbeit spaeter.
Warum OKRs existieren
OKRs sind kein Berichtsformat. Sie sollen drei Dinge leisten, die einem Team allein selten gelingen. Focus: sich zu den wenigen wirklich wichtigen Dingen bekennen und Nein zum Rest sagen. Transparency: sichtbar machen, worauf das Team hinarbeitet und wie weit es ist, damit niemand fragen muss. Alignment: die Teamziele mit der groesseren Richtung und untereinander verbinden. Wenn ein OKR-Set keines dieser drei Dinge erzeugt, ist das Format nur Overhead.
Beginne jedes Engagement damit, Focus, Transparency, Alignment gut sichtbar an die Wand zu schreiben, und frage dann: "Gibt uns das hier mehr von einem dieser drei Dinge? Wenn nicht, warum machen wir es?"
- Schreib die drei Woerter auf, bevor irgendetwas anderes beginnt.
- Wenn das Team sich in Mechaniken verliert, zeige auf die Woerter.
- Wenn bei keinem der drei ein klares Ja herauskommt, die Session kurz unterbrechen und das laut benennen.
Beispiel: dasselbe Quartal, mit und ohne Focus
Ein Team trackt 14 Ziele, alle als wichtig markiert, keines bewegt sich. Kein Teammitglied kann die drei wichtigsten aus dem Kopf nennen.
Dasselbe Team verpflichtet sich auf 2 Ziele fuer das Quartal. Beide bewegen sich sichtbar jede Woche, und jedes Teammitglied kann sie ohne Nachschlagen benennen.
Vierzehn "wichtige" Ziele ergeben keine Richtung, sondern eine Warteliste. Zwei, die alle auswendig kennen, sind eine Verpflichtung. Der Schritt von 14 auf 2 ist der Ort, wo Focus wirklich entsteht.
Focus, Transparency und Alignment sind der Zweck. Alles andere steht in ihrem Dienst, und nur in ihrem.
Outputs, Outcomes, Impact
Ein Output ist etwas, das man erstellt oder tut: ein Feature, ein Workshop, ein Bericht. Ein Outcome ist eine messbare Veraenderung im Verhalten oder in der Situation einer Person, die der Output ausloest. Ein Impact ist das weit entfernte Ziel, zu dem viele Outcomes zusammen beitragen. Key Results leben auf der Outcome-Ebene. Outputs sind zu leicht als erledigt zu verbuchen, ohne dass sich etwas veraendert hat. Impact liegt zu weit weg, um ihn innerhalb eines Quartals zu steuern.
Wenn das Team ein Ziel vorschlaegt, frage: "Ist das etwas, das ihr macht, eine Veraenderung bei jemandem, oder eine weit entfernte Zahl?"
- Zeichne die dreistufige Leiter an die Tafel: Output / Outcome / Impact.
- Bitte jede Person, ihr vorgeschlagenes Ziel laut auf der Leiter einzuordnen, bevor jemand kommentiert.
- Die Unterscheidung lernt man durch das Sortieren eigener Worte, nicht durch Zuhoeren bei einer Definition.
Beispiel: ein Output, der nichts veraendert hat
"Wir haben das neue Dashboard-Design geliefert." Erledigt, gefeiert, abgehakt.
"Und hat jemand es danach anders genutzt?" Stille. Der Outcome wurde nie benannt, also beweist der Output nichts darueber, ob sich etwas geaendert hat.
Ausliefern ist nicht das Ziel. Das Ziel ist, dass jemand danach etwas anders tut. Wer die erwartete Veraenderung nie benennt, kann beliebig viele Outputs liefern, ohne zu wissen, ob es wirkt.
Transparency ist unmoeglich, wenn "fertig" bedeutet "wir haben gearbeitet" und nicht "bei jemandem hat sich etwas veraendert".
Wie ein gutes OKR-Set aussieht
Auf Teamebene ist die uebliche Form: ein Objective und zwei bis vier Key Results fuer eine Zeiteinheit, oft ein Quartal. Das Objective ist ein Satz, den jede Person im Team wiederholen kann. Die Key Results sind messbar und wenige. Business-as-usual-Metriken wie Uptime oder Support-Volumen werden separat als Health Metrics, also laufende Gesundheitswerte, getrackt, nicht in die OKRs gezwaengt. Weniger ist die Disziplin: ein langes OKR-Set ist ein Focus-Versagen im Planungs-Kostuem.
Gib dem Team ein absichtlich aufgeblaehtes Beispiel-Set und frage: "Welche davon sind wirklich Outcomes, und was gehoert woanders hin?"
- Drucke oder schreibe ein Set mit einem Objective und sieben Key Results auf, zwei davon BAU-Metriken.
- Bitte das Team, es auf das Minimum zu kuerzen, das es vertreten koennte.
- Lass jede Streichung laut begruenden. Das Verteidigen der Kuerzungen lehrt Focus schneller als jeder Vortrag ueber die ideale Struktur.
Beispiel: von der Wunschliste zum OKR-Set
1 Objective, 7 Key Results. Drei sind Aufgaben ("X launchen", "Y migrieren"), zwei tracken BAU-Metriken, die sich kaum veraendern, einer hat keine Baseline. Das Set sieht vollstaendig aus, gibt dem Team aber keine wirkliche Richtung.
1 Objective, 3 Outcome-Key-Results. Die Aufgaben wandern ins Backlog. Die BAU-Metriken gehen auf ein Health-Dashboard. Das Set ist kuerzer, aber jeder Eintrag zeigt tatsaechlich, ob sich das Objective bewegt.
Drei Key Results, hinter denen alle stehen, sind nuetzlicher als sieben, die niemand priorisieren kann. Das Kuerzungsgespraech ist der Ort, wo das echte Alignment entsteht.
Focus ist an der Anzahl ablesbar. Wenn die wenigen, die wirklich zaehlen, nicht erkennbar sind, dann sind sie es fuer niemanden.