Hol den Schmerz deiner OKRs nach vorne

Eine aktuelle Umfrage von OKR International zeigte, dass 78 % der Teams bei der Einführung von OKRs Schwierigkeiten hatten, sie richtig umzusetzen. Das ist eine große Zahl. Und noch überraschender ist, dass das OKR-Framework im Vergleich zu etwas wie EoS oder Scaling Up eigentlich recht minimalistisch ist. Wie kommt es also, dass der anfängliche Erfolg bei der Einführung einer Zielsetzungsmethode mit nur 2 Komponenten (den Objectives und den Key Results) so gering ist?

Bei Tability haben wir ein ziemlich einzigartiges Verständnis für dieses Problem, denn 95 % unserer Kunden nutzen unsere Plattform, um ihre OKRs zu verfolgen. Im Laufe der Jahre haben wir mit mehr als 500 Teams über ihre Ziele gesprochen, und es gibt ein paar gute Gründe, warum es so schwierig ist, OKRs beim ersten Versuch richtig umzusetzen.

Warum OKRs beim ersten Mal scheitern

Auch wenn Unternehmen sehr unterschiedlich sein können, sind es oft dieselben Muster, die über Erfolg und Misserfolg entscheiden. Du könntest hunderte verschiedene Gespräche führen und würdest trotzdem immer wieder dieselben 3 Themen hören, wenn es um das Scheitern von OKRs geht:

• Es ist schwer, eine output-zentrierte Kultur umzudrehen
• Akzeptanz braucht Zeit
• Zu viel Reporting, zu wenig Gespräche

Problem 1: Es ist schwer, eine output-zentrierte Kultur umzudrehen 

Wenn du jemanden, der das OKR-Framework nicht kennt, fragst „Was sind deine Key Results?“, wird er dir wahrscheinlich mit einer Liste von Projekten antworten, die er liefern muss.

Er hat die Frage wörtlich genommen und dir die Liste der Dinge gegeben, die er bauen/veröffentlichen/abschließen muss.

Aber in der Welt der OKRs sollte ein Key Result die erwartete Wirkung deiner Arbeit erfassen, statt der Arbeit selbst. Anstatt zum Beispiel „Eine LinkedIn-Werbekampagne starten“ als Key Result zu haben, solltest du stattdessen „XX Kunden über LinkedIn als Kanal gewinnen“ verfolgen.

Problem 2: Akzeptanz braucht Zeit

Als ich das erste Mal mit OKRs in Berührung kam, fühlte es sich an wie eine weitere Tabelle, die man für das Management ausfüllen musste (ich war damals Product Manager). Heute, im Rückblick, denke ich wirklich, dass OKRs eines der besten verfügbaren Werkzeuge für Unternehmen sind, die Alignment skalieren wollen, ohne viele zusätzliche Ebenen des mittleren Managements einzuführen.

Der Grund, warum ich ungefähr 3 Zyklen brauchte, um den Wert von OKRs zu „verstehen“, liegt darin, dass viele der Vorteile eher kollektiv als individuell erlebt werden. Lass mich das anhand der Einführung von Design Systems erklären.

Ein Design System ist eine Sammlung von Standards und wiederverwendbaren Komponenten, die zum Erstellen von Anwendungen verwendet werden können. Es ist besonders hilfreich für Organisationen mit mehreren Produkten, die von unterschiedlichen Teams gebaut werden. Aber genau wie bei OKRs kann es anfänglich Widerstand geben, wenn du es einführst. Warum? Weil du Teams dazu zwingst, einen Standard zu übernehmen, von dem du weißt, dass er sich global auszahlen wird, der sich für sie aber lokal wie ein Rückschritt anfühlt.

Genau das habe ich erlebt, als Atlassian sein Design System einführte. Aus Sicht eines Teams fühlte es sich an, als müsste man auf ein paar großartige individuelle Komponenten verzichten, die im eigenen Produkt wunderbar funktionierten. Betrachtet man aber die Erfahrung eines Nutzers, der mehrere Atlassian-Produkte verwendet, bedeutete das, dass er eine viel bessere Erfahrung hatte, weil sich alles immer vertraut und konsistent anfühlte. Am Ende haben wir es geschafft, aber es brauchte Zeit und Aufwand, um vollständige Akzeptanz zu erreichen.

Zurück zu OKRs. Du könntest jedes Team seine eigene Zielsetzungsmethodik mit eigenen Begriffen und Regeln entwickeln lassen. Aber das würde in großem Maßstab schnell zu Chaos führen. Das OKR-Framework ist im Grunde ein Design System für die Zielsetzung und sorgt für eine konsistente und vertraute Erfahrung in der gesamten Organisation.

Aber es wird dauern, bis die Leute das erkennen.

Problem 3: Zu viel Reporting, zu wenig Gespräche

Die überwältigende Mehrheit der Leute, mit denen wir gesprochen haben, hat damit begonnen, ihre OKRs in Tabellen zu „tracken“. Ich setze tracken hier in Anführungszeichen, weil die Dinge oft so aussehen:

• Tag 1: Füge deine OKRs zur Tabelle hinzu.
• Tag 1…30: *Grillenzirpen*
• Tag 30: schnell, schnell, lass uns die Tabelle vor dem Review-Meeting aktualisieren
• Tag 30-60: *Grillenzirpen*
• Tag 60: schnell, schnell, lass uns die Tabelle vor dem Review-Meeting aktualisieren
• Usw…

Während des Monats passiert nicht viel Tracking, und es vergehen Wochen, bevor jemand wieder einen Blick auf die Ziele wirft.

OKRs sind nicht hilfreich, wenn sie am Ende jedes Monats auf eine reine Reporting-Übung reduziert werden. Erstens wird es für dein Team super schwer sein, sich auf die richtigen Dinge zu konzentrieren. Nicht weil es ihnen egal ist, sondern weil das Lösen schwieriger Probleme 100 % deiner Aufmerksamkeit erfordert. Du denkst entweder über das Problem nach, oder darüber, warum du überhaupt an diesem Problem arbeitest. Beides gleichzeitig zu tun, ist schwer.

Wenn also ein Team anfängt, an einem Lead-Generierungs-Problem zu arbeiten, stößt es vielleicht auf andere Probleme rund um die Website-Optimierung oder arbeitet an der Verbesserung des Drip-Feeds – aber ist das gerade wirklich wichtig?

Deine OKRs sollten ein ständiges Leuchtfeuer sein, das Teams hilft, schnell zu bemerken, wenn sie von ihren Zielen abdriften. Und das kann nur passieren, wenn der Fortschritt bei den Zielen zu einem fortlaufenden Gespräch wird, statt zu einer Präsentation, die zur Prüfung verschickt wird.

Einfache Lösungen für häufige OKR-Probleme

Ok, ich habe gerade 650 Wörter über Probleme geschrieben. Zeit, ein paar Lösungen anzubieten.

Bevor wir loslegen, muss ich festhalten, dass es keine Abkürzungen für kulturellen Wandel gibt. Atlassian hat die Akzeptanz des Design Systems durch wiederholte Gespräche und Präsentationen über die Entscheidung für Standardkomponenten erreicht. Du wirst höchstwahrscheinlich dasselbe tun müssen, um Akzeptanz für OKRs zu bekommen. Die Vorteile mögen für dich offensichtlich sein, aber es ist gut möglich, dass andere das anders sehen.

Warte.

Ich habe vielleicht einen kleinen Tipp.

Eine Sache, die geholfen hat, alle vom Design System zu überzeugen, war zu zeigen, wie unstimmig sich die Erfahrung anfühlte, wenn man von einem Produkt zum anderen wechselte (oder sogar von einem Screen zum anderen!). Tabs unterschieden sich, Buttons hatten unterschiedliche Muster, Nutzer hatten Schwierigkeiten, einfache produktübergreifende Workflows abzuschließen. Vielleicht kannst du das Gleiche tun, indem du jedes Team bittest, sein Strategiedokument so wie es ist zu schicken (keine neue Seite basteln, um zu schummeln), und siehst, wie leicht es für Team A ist zu verstehen, worauf sich Team B konzentriert.

Ok, schauen wir uns jetzt ein paar einfache Lösungen an.

Grenzen setzen

Das Erste, was du tun solltest, ist die Anzahl der OKRs zu begrenzen. Es ist verlockend, jedem Ziele zu geben, aber es ist besser, klein anzufangen, während du den Übergang von projektzentriert zu ergebnisorientiert vollziehst.

Hier ist ein einfaches Regelwerk:

• Nur Top-Level- und Team-Level-OKRs (keine individuellen OKRs)
• Nicht mehr als 3 Objectives pro Plan
• Nicht mehr als 4 Key Results pro Objective

Durch das Setzen von Grenzen verringerst du das Risiko, deine Roadmap einfach in deinen OKRs zu wiederholen. Knappheit schafft Fokus und Klarheit. Wenn du nur 8 bis 12 Key Results hast, um deine Absicht zu erfassen, musst du wirklich die Dinge auswählen, die den Erfolg am Ende des Quartals am besten repräsentieren.

Eine weitere Grenze: niemand sollte für das Quartal mehr als 5 Key Results besitzen. Warum? Die Aufgabe des Owners ist es, den Fortschritt durch regelmäßige Check-ins mit dem Rest der Organisation zu teilen. Das ist eine wichtige Aufgabe, die nur gut erledigt werden kann, wenn du genug Zeit zum Nachdenken hast. 5 Minuten pro KR x 5 KRs = 25 Minuten. Das klingt machbar und sogar unterhaltsam. Aber die Qualität der Check-ins wird schnell sinken, wenn du anfängst, den Leuten mehr Key Results zu geben.

Eine schnelle Möglichkeit, Pläne und Nutzer mit zu vielen OKRs zu finden

Du kannst Tabilitys Audit-Funktion nutzen, um schnell Pläne und Nutzer zu finden, die zu viele Key Results zugeordnet haben. Sobald dein Team seine OKRs in Tability hinzufügt, scannt die Plattform alle Ziele, um häufige Probleme zu identifizieren, die behoben werden sollten. Das könnte sein:

• Ein Nutzer mit zu vielen Zielen
• KRs ohne Owner oder nicht messbar
• Pläne ohne Check-ins
• Usw.

Das wird OKR-Champions helfen, die ihren Teams schnell Unterstützung bieten möchten.

Mache OKRs zu einem Teil deiner wöchentlichen Routine

Es gibt ein großartiges Zitat aus dem Buch „Continuous Delivery“.

Wenn es wehtut, mach es öfter und hole den Schmerz nach vorne” - Jez Humble

Dieser Satz wurde im Kontext von Software-Deployments geprägt, die schwer zu automatisieren sind. Du könntest weiterhin einmal im Monat dein Team versammeln, um einen mühsamen Release-Prozess durchzugehen. Oder du holst den Schmerz nach vorne und tust, was nötig ist, um deinen Code jede Woche zu deployen. Das zwingt dich, dein Problem genau anzusehen und herauszufinden, wie du Reibung beseitigen und die Dinge so schmerzfrei wie möglich machen kannst.

Dasselbe gilt für OKRs.

Zunächst einmal sollte dein Team den Fortschritt bei den Zielen zu Beginn jeder Woche überprüfen.

Das ist der beste Weg, um alle aufeinander abgestimmt zu halten und die Ziele wieder in den Mittelpunkt zu rücken (denk daran, 95 % der Woche dreht sich um Outputs).

Zweitens: Wenn das wöchentliche OKR-Tracking schmerzhaft ist, sollte die Antwort nicht sein, die OKRs seltener anzuschauen. Stattdessen solltest du herausfinden, wo die Reibungspunkte liegen, und tun, was nötig ist, um einen stressfreien wöchentlichen Rhythmus zu erreichen.

Ein einfacher Weg, OKR-Schmerz zu reduzieren

Genau wie Software-Teams CI/CD Tools nutzen, um Deployments zu automatisieren, kannst du Tability nutzen, um die lästigen Teile von OKRs zu automatisieren:

• Erhalte ein Live-Dashboard für jeden Plan
• Automatisierte Check-in-Erinnerungen per E-Mail/Slack/Push-Benachrichtigung
• Alarmbenachrichtigungen, Fortschrittsdiagramme, Insights und Metriken
• E-Mail-Digest, Präsentationsmodus usw… Alle Dashboards, die du für Stakeholder brauchst, sind nur einen Klick entfernt
• Du kannst Tability mit deinen Tools verbinden, um Daten automatisch abzurufen

Schau dir unten die Demo von Wyl an, wenn du es in Aktion sehen willst 👇

Verbinde OKRs mit strategischen Projekten

Ergebnisorientiert zu sein heißt nicht, dass Projekte keine Rolle mehr spielen. Deine Projekte zählen immer noch, aber sie werden jetzt wie Wetten behandelt, die dir helfen können, deine wichtigsten OKRs zu erreichen, statt wie kritische Verpflichtungen, die um jeden Preis geliefert werden müssen.

Das ist auch der Grund, warum du eine gesunde Feedback-Schleife zwischen deinen Outcomes (OKRs) und deinen Outputs (strategischen Projekten/Initiativen) haben solltest. Jede Woche liefert dein Team bestimmte Outputs. Und jede Woche solltest du in der Lage sein, deren Wirkung zu messen. Wenn etwas gut funktioniert, setze stärker darauf. Aber es sollte auch in Ordnung sein, Wetten aufzugeben, die sich nicht auszahlen.

In der Praxis bedeutet das, dass du einen Weg finden musst, deine übergeordneten Initiatives mit bestehenden OKRs zu verbinden (mach das nicht für Aufgaben auf niedriger Ebene). Natürlich wirst du Business-as-usual-Projekte haben, die nicht an bestimmte Key Results oder Objectives gebunden sind. Aber es sollte super einfach sein, den umgekehrten Weg zu gehen, um die Frage zu beantworten: „Was tun wir gerade, um dieses OKR zu erreichen?“

Ein schneller Weg, Outcomes mit Outputs zu verbinden

In Tability kannst du Initiatives einfach unter jedem Key Result auflisten, einschließlich der Verknüpfung von Elementen aus deinem Projektmanagement-Tool. Einmal verknüpft, bietet Tability viele verschiedene Möglichkeiten, strategische Projekte den laufenden Zielen zuzuordnen.

Was kommt als Nächstes

Ich hatte etwas Mühe, den richtigen Titel für diesen Beitrag zu finden. Ich dachte, es würde um Design- oder Software-Analogien gehen, aber es war Jez Humbles Zitat, das alles auf den Punkt brachte.

Dutzende Menschen über Dutzende Teams hinweg synchron zu halten, ist schmerzhaft. Aber das Kontraintuitive ist, dass wir uns dem Schmerz stellen und öfter in Synchronisation investieren sollten. Die Alternative wird uns wahrscheinlich nicht helfen. Schlimmer noch, sie könnte unserer Kultur auf lange Sicht schaden.

Wenn du nach weiteren Tipps suchst: Wir haben eine Liste mit 15 Regeln, die OKRs vereinfachen sollen. Wir nennen dieses Modell Flowing OKRs, und es sollte zumindest ein paar nützliche Debatten anstoßen.