Kaskadierende OKRs sind schlecht für Startups

„Ziele zu haben verbessert die Leistung. Stundenlang Ziele durch das ganze Unternehmen zu kaskadieren, tut das aber nicht. Es kostet viel zu viel Zeit, und es ist zu schwer, sicherzustellen, dass alle Ziele zusammenpassen.“
Lazlo Bock, ehemaliger VP of People Operations @ Google

Das obige Zitat könnte eigentlich der gesamte Beitrag sein. Das Kaskadieren von OKRs ist eine der ersten Fragen, die wir von Teams hören, die Tability einführen, und meine Antwort ist immer eine Variante von „das willst du wahrscheinlich nicht machen“.

Kaskadieren wirkt von oben verlockend, aber von unten sieht es furchtbar aus

Kaskadieren klingt in der Theorie großartig – stell dir vor, du könntest jedes Ziel vom obersten bis zum untersten Ende des Unternehmens verfolgen und sehen, wie jedes Team zum großen Ganzen beiträgt. Das würde für so viel Klarheit sorgen! Und es ist sicher auch eine großartige Möglichkeit, alle aufeinander abzustimmen, weil alles miteinander verbunden ist.

Wunderschön.

Aber Unternehmen sehen selten wie eine Reihe Dominosteine aus (oder wie eine Fußballmannschaft – zwinker, zwinker). Ich habe bereits früher über die Ineffizienzen des OKR-Kaskadierens geschrieben, aber hier möchte ich noch ein paar andere Probleme hervorheben:

• Menschen sind generell schlecht im Vorhersagen
• Bei OKRs sollte es um das Schaffen von Gesprächen gehen, nicht um Wartungsarbeit

Du müsstest ein fantastischer Stratege sein, damit das Kaskadieren von OKRs funktioniert. Jeder Fehler an der Spitze kann den Rest der Organisation gegen die Wand fahren lassen. Ein schlechtes Key Result kann schnell dazu führen, dass das ganze Unternehmen die falschen Ergebnisse verfolgt.

Beim Kaskadieren musst du exzellent darin sein vorherzusagen, was funktionieren wird. Und genau deshalb ist es kein gutes Modell, dem man folgen sollte.

Unternehmen wie Netflix, Airbnb und Amazon führen jeden Monat Hunderte Experimente durch, weil sie wissen, dass sie sich irren – selbst mit Hunderten der klügsten Köpfe, die sich auf ihre Probleme konzentrieren. Es gibt keine Möglichkeit, dass ein in alle Richtungen gedehntes Startup perfekte Entscheidungen treffen kann, und umso wichtiger ist es für solche Unternehmen, wendig und flexibel zu sein.

Das bringt uns zum zweiten Problem beim Kaskadieren von OKRs. Es führt dazu, dass wir unsere Ziele wie einen Netzwerkgraphen behandeln. Manager erwarten, jederzeit durch das gesamte Unternehmen navigieren zu können. Jede Änderung an den OKRs löst einen Tanz um Tabellen und Dokumente aus, um die Beziehungen zu reparieren. Dadurch kümmert sich dein Team mehr um die Verwaltung des Graphen als um das eigentliche Gespräch über die OKRs.

Ehrlich gesagt ist das nur eine andere Form von Mikromanagement.

Behandle deine OKRs wie Vektoren, nicht wie Graphen

Ein besserer Ansatz besteht darin, jedes Team als eigenen Vektor zu behandeln. Du kannst OKRs dann als einfache Möglichkeit nutzen, die Richtung jedes Teams zu sehen und sicherzustellen, dass sie alle auf ein gemeinsames Ziel zusteuern.

‍

OKRs funktionieren am besten, wenn du sie als Kommunikationswerkzeug statt als Reporting-Maschine nutzt. Das Framework bietet deiner Organisation eine einheitliche Sprache, um über Fokus und Fortschritt über Funktionen hinweg zu sprechen. Nutze das zu deinem Vorteil, um schnelle Feedback-Schleifen zwischen Outputs und Outcomes zu schaffen.

Wöchentliche Fortschritts-Reviews (OKRs + Roadmap) sind ein großartiger Weg, um aufzuhören, dir Sorgen über schlechte Ziele zu machen. Fehlausrichtungen zeigen sich nach ein paar Iterationen ganz von allein, und Korrekturen lassen sich leicht vornehmen.

Das Ziel dieses Prozesses ist nicht Perfektion. Es ist Agilität.

Ausrichtung sollte nicht bedeuten, strikte Kontrolle über die Arbeit deines Teams zu haben. Es bedeutet, Klarheit in deiner gesamten Organisation zu haben. Verzichte aufs Kaskadieren, wenn du deinem Team ermöglichen willst, sich schnell zu bewegen, und ersetze es durch bessere Wege, euch über den Fortschritt abzustimmen.

Technologie ist großartig, aber wir sind es auch

Es ist immer verlockend, jedes Problem mit mehr Code und mehr Features zu lösen. Warum nicht einen Graphen bauen? Warum nicht etwas maschinelles Lernen einbauen? Warum nicht Abhängigkeiten vorschlagen?

Unsere Antwort ist, dass wir glauben, dass Menschen immer noch im Vorteil sind, wenn es darum geht, komplexe Daten zu verstehen. Manchmal ist es besser, die Dinge einfach zu halten und Komplexität durch die richtigen Gespräche zu ersetzen.

Weiterführend

• Sieh dir Whitney O'Banners Vortrag Bottoms Up With OKRs an.
• Lies über die Kosten des Kaskadierens von OKRs.
• Sieh, wie du deine OKRs wie Code behandeln kannst.