OKRs erreichen vs. einfach die Arbeit machen

• In der Engineering-Arbeit wirken quartalsweise OKRs (Objectives & Key Results) oft wie eine Dopplung der Produktplanung
  • Meist werden sie so verstanden, dass sie dasselbe bedeuten wie „die Roadmap umsetzen“
  • Wenn OKRs etwas anderes enthalten als die Roadmap, geraten sie in Konflikt mit der Roadmap
  • Fiktives Beispiel
    • Objective: Frontend Observability bereitstellen
    • Key Result: Alle Funktionen von Phase 1 bereitstellen
    • Key Result: Fehlerrate unter 3 % halten
    • Key Result: 1000 Nutzerinteraktionen pro Tag
• Im Marketing drücken quartalsweise OKRs die Absicht des Unternehmens klar aus und funktionieren effektiv
  • Marketing-Teams beschweren sich seltener darüber, OKRs schreiben zu müssen
  • Fiktives Beispiel
    • Objective: Die Pipeline durch den Launch von Frontend Observability aktivieren
    • KR: 3 Medien berichten über den Launch
    • KR: 2000 Besuche auf der Landingpage
    • KR: 100 Marketing Qualified Leads (MQLs) aus Ziel-Accounts gewinnen
• Warum sind OKRs im Marketing einfacher?
  • Teilweise, weil:
    • Marketing eher projektartig arbeitet und innerhalb eines Quartals oder zweier Quartale abgeschlossen werden kann
    • Engineering eher laufende Produktarbeit ist und einem Rhythmus ständiger Updates folgt
  • Natürlich gibt es auch im Marketing wiederkehrende Arbeitsrhythmen
    • Anzeigen, Webinare, E-Mail-Versand, Events usw.
    • OKRs drücken klar aus, auf welche Anzeigen, Webinare und Events man sich in diesem Quartal konzentriert
    • Das kann sich mit einer Kampagnenübersicht überschneiden, richtet den Fokus aber auf neue Kampagnen, neue Zielgruppen oder neue Kanäle
    • Es geht nur darum, welchen Aufwand an Kosten und Zeit man in diesem Quartal für etwas Neues investiert, das man nicht jedes Quartal macht

Laufende, regelmäßig stattfindende Arbeit erscheint im Allgemeinen nicht in OKRs. Genau dafür gibt es KPIs (Key Performance Indicators)

• Im Marketing gibt es KPIs für die Kernarbeit, Leads zu gewinnen, aus denen „Sales Opportunities“ werden, und diese werden gemessen
  • Web-Traffic, Anzeigenleistung, SEO-Rankings, Webinar-Teilnahme und die Zahl der Kontakte auf Events werden überwacht
  • Solche KPI-Werte tauchen nur dann in OKRs auf, wenn man sie verbessern oder auf andere Weise erreichen will, etwa mit neuen Zielgruppen oder neuen Botschaften
  • OKRs drücken einen Fokuswechsel, Prozessänderungen oder die Gespräche aus, die wir führen müssen
  • Fiktive Beispiele
    • Objective: Die Bekanntheit von Honeycomb in 3 Ländern steigern
    • Objective: Kosten pro Opportunity senken
      • KR: Die Conversion-Rate von MQL zu SQL von 7 auf 10 % steigern
    • Objective: 2 Use Cases finden, in die es sich zu investieren lohnt
• Im Engineering gibt es KPIs für die Kernarbeit, Software auszuführen und Updates auszurollen
  • An SLOs (Service-Level Objectives) und DORA-Metriken wie Deployment Frequency lässt sich erkennen, ob die Arbeit reibungslos läuft
  • Funktionen aus der Roadmap zu launchen ist Teil der Kernarbeit. Normalerweise sollte das nicht in OKRs stehen
    • OKRs zeigen, was sich in diesem Quartal ändern soll, was wir verändern wollen und was wir herausfinden möchten
  • Fiktive Beispiele
    • Objective: Reibungsloser Launch von Frontend Observability
      • KR: Fehlerrate unter 3 %
    • Objective: 3 neue Teammitglieder in die On-Call-Rotation aufnehmen
    • Objective: 2 Services anderer Teams übernehmen
    • Objective: Die Reaktionsfähigkeit der Timeline-Ansicht verbessern
      • KR: Mit Distributed Tracing den Beitrag zur Latenz identifizieren
  • Im obigen Beispiel heißt es „reibungsloser Launch von Frontend Observability“ – fällt das nicht unter „Roadmap ausrollen“?
    • Ein Feature-Launch ist Teil eines reibungslosen Launches, aber es endet nicht dort
    • Von allen Features, die in diesem Quartal gelauncht werden, ist dieses für das Geschäft am wichtigsten
    • Dass dieses Feature im OKR steht, signalisiert anderen, dass wir auch weitere Arbeit dafür vorantreiben, sofort auf Bug-Reports reagieren und diesen Release mit vollem Einsatz unterstützen werden
  • Wenn die OKRs eines Teams nur die Roadmap wiederholen, kann das als „Absicht, den aktuellen Zustand ohne Verbesserungsversuch beizubehalten“ gelesen werden
    • Das könnte also bedeuten: „Dieses Quartal ist ein Quartal des Status quo“ – und das ist nicht gut
• OKRs sind „Was ist der Unterschied in diesem Quartal?“ „Was ist neu?“ „Wie wollen wir anders werden?“ „Was wollen wir herausfinden?“
  • Sorgt dafür, dass OKRs einen besonderen Fokus hervorheben. Versucht nicht, jede einzelne Arbeit in OKRs zu packen

[jhj0517]

Wir sollten Ziele, deren Ergebnisse sich später in Zahlen ausdrücken lassen, klar von solchen unterscheiden, bei denen das nicht möglich ist.

[aer0700]

Wenn man einen Plan erstellt, fließt darin eine Einschätzung der Marktlage ein. Aber wie viel Prozent dieser Einschätzung beruhen auf Statistik und wie viel Prozent sind Wunschdenken des CEO? Das lässt sich wohl nur schwer in Zahlen ausdrücken.

[roxie]

Was ist Ihrer Meinung nach ein Ziel, das sich nicht in Zahlen ausdrücken lässt?

[ethanhur]

OKRs, zielorientierte Organisationen und Agile wirken zwar alle fancy und vermitteln den Eindruck, die Probleme einer Organisation lösen zu können, aber ich glaube, dass sie in der Praxis nicht zu den Dingen gehören, die sich leicht gut umsetzen lassen.

In letzter Zeit denke ich auch, dass man OKR je nach Fähigkeiten der Organisation und dem Business wirklich sehr sorgfältig abwägen und anwenden sollte. Die Kosten, wenn es nicht gut funktioniert, scheinen mir einfach zu hoch zu sein.

https://x.com/sundarpichai/status/1543328071532523521

[GN⁺]

Hacker-News-Kommentare

• Nachdem ich bei Facebook gearbeitet hatte und dann in einem kleinen Team arbeitete, wurde mir klar, wie großartig es ist, arbeiten zu können, ohne sich um OKRs und Leistungsbeurteilungen sorgen zu müssen. Sich im Team selbst zu branden und zu vermarkten, war extrem ermüdend.

  • Aus der Perspektive des Systemdenkens lehne ich OKRs grundsätzlich ab, weil sie menschliche Aktivitäten auf Zahlen reduzieren. Das entfernt einen von den tatsächlichen Problemen und lenkt in die falsche Richtung.
  • Ich erinnere mich an eine Anekdote aus W. Edwards Demings Buch "The Essential Deming". Um ein ineffizientes System zu verbessern, mit dem eine Firma Öl per Lastkahn transportierte, entwickelte ein neuer Manager Kennzahlen, setzte aber keine Ziele. Infolgedessen begannen die Lastkahnkapitäne freiwillig miteinander zu konkurrieren, um Kosten zu senken, und das Projekt wurde schließlich sehr profitabel.

• Frameworks zur Festlegung von Unternehmensprioritäten und -zielen wie OKRs helfen dabei, Unstimmigkeiten darin aufzudecken, wie Teams Prioritäten setzen. Unternehmen betrachten das jedoch oft als lästig und verpassen die Chance zu lernen.

• Wenn OKRs eingeführt werden, versteht man als Führungskraft, dass Zielorientierung und die Übersetzung in konkrete Ergebnisse nötig sind. Aber nur wenige Führungskräfte können das gut, und viele interessieren sich nur dafür, ihren eigenen Bereich auszubauen.

  • Als Ingenieur gibt es viele Dinge, die OKRs, den Betrieb und die Wochenplanung stören. Ein guter PM kann das reduzieren, aber in den meisten Fällen passiert das nicht.

• Manche Menschen interessieren sich nicht für OKRs. Sie arbeiten 2–3 Jahre im Unternehmen, bekommen Gehaltserhöhungen, nehmen es im ersten Jahr locker, werden im zweiten Jahr ernsthafter und suchen im dritten Jahr nach einer neuen Gelegenheit.

• Ich arbeite in einem nichttechnischen Bereich für interne Kunden, und uns werden OKRs aufgezwungen. Produktmanager sitzen zwischen Entwicklern und Nutzern, und jedes Team schreibt seine eigenen OKRs, ohne Abstimmung mit anderen Teams.

  • Zum Beispiel versucht ein Team, 15 % weniger Beton zu verwenden, während ein anderes versucht, Gebäude 15 % höher zu machen. Das spiegelt die tatsächlichen Anforderungen der Kunden nicht wider.

• Ich beobachte gerne, wie Menschen, die schnelle Ergebnisse wollen, über Agile, OKRs und KPIs lesen und sich selbst in Schwierigkeiten bringen. Manager erzwingen das, und Leute, die keine Zeit haben, es wirklich zu verstehen, setzen es dann um.

  • Wenn ehrgeizige junge Leute das vorantreiben, wird das Team ineffizient, und das Produktteam versteift sich auf OKRs.

• Manager setzen OKRs ohne Feedback der technischen Mitarbeitenden fest, und einmal festgelegte OKRs werden nicht mehr geändert. Das zerstört die Teamdynamik und führt dazu, dass man das System ausspielt, um die Zielmetriken zu erreichen. Am Ende verlassen wichtige Talente das Unternehmen.

• Jede zusätzliche Kennzahl bringt eine Produktivitätssteuer mit sich:

  1. Zeit, die dafür aufgewendet wird, Kennzahlen auszunutzen
  2. Zeit, die dafür aufgewendet wird, Kennzahlen zu dokumentieren und sichtbar zu machen