Objectives and Key Results (OKRs) sind in aller Munde. Nach Scrum, Kanban und XP scheinen sie im Trend zu liegen.
In Coachings und Schulungen im evidenzbasierten Management arbeite ich regelmäßig mit Unternehmen, die auf OKRs setzen. Allerdings: Je häufiger etwas genutzt wird, desto mehr Fehler werden damit begangen – vor allem bei Teams, die für interne Kunden arbeiten.
Deshalb möchte ich dich heute vor den drei häufigsten Fehlern warnen.
Los geht’s:
Fehler #1: Das „Objective“ zahlt nicht auf den Kunden ein
Jeder hat einen Kunden.
Jetzt denkst du wahrscheinlich: „Ja, eigentlich schon. Aber in meiner speziellen Situation gibt es keinen Kunden.“
Natürlich mache ich dir keinen Vorwurf. Denn ich glaube: Je größer ein Unternehmen ist, desto weniger kennen die Teams ihre Kunden. Und deshalb ist es in vielen Unternehmen „normal“, seine Kunden nicht zu kennen.
Allerdings: Wenn du erfolgreich OKRs nutzen willst, solltest du das ändern. Alles andere wäre ein Fehler. Denn die „Objectives“ sollten ein qualitativer Ausdruck der Strategie eines Unternehmens sein – formuliert in spezifischen Zielen. Sie sollten Teams inspirieren und einen, indem sie ihnen ein starkes „Wozu“ für ihre Arbeit liefern.
Und dieses „Wozu“ sollte der Kunde sein. Kennst du ihn nicht, kannst du trotzdem am Erfolg des Unternehmens mitwirken.
Wie gehst du dabei vor?
Ich nehme mal an, du arbeitest für ein Unternehmen, das am Ende des Tages Gewinn erzielen muss, – also kein Non-Profit-Unternehmen. Gewinn wird von zwei Faktoren beeinflusst:
Einnahmen und Kosten.
Also: wie viel Geld in das Unternehmen fließt und wie viel Geld aus dem Unternehmen fließt.
Wenn du deine Kunden nicht kennst, stehen die Chancen gut, dass du nicht direkt an der Steigerung der Einnahmen mitwirkst. Also arbeitest du wahrscheinlich daran, Kosten zu reduzieren oder zu vermeiden – oder du trägst sehr indirekt zur Steigerung der Einnahmen bei.
Über die letzten zehn Jahre habe ich mit vielen solcher Teams gearbeitet. Hier die drei häufigsten Typen und deren Kunden:
- Interne Produkte: Diese Teams erstellen Produkte, die von anderen Teams oder Mitarbeitern innerhalb des Unternehmens verwendet werden. Ihre Kunden sind häufig Produktteams, HR, der Kundensupport oder Servicedienstleister.
- Indirekte Einnahmen: Diese Teams arbeiten an Produkten, die von den Kunden genutzt werden, mit denen aber nicht direkt Geld verdient wird. Ihre Kunden sind häufig der Vertrieb, der Support und das Marketing.
- Risikomanagement: Diese Teams entwickeln Produkte zur Überwachung oder Verringerung von Risiken, die dem Unternehmen helfen, Kosten zu vermeiden oder Einnahmen zu sichern. Ihre Kunden sind häufig das Controlling, die Rechtsabteilung, der Datenschutz, die Finanzabteilung oder die IT-Infrastruktur.
Alle diese Teams haben Kunden. Vielleicht keine, die direkt für die Leistung deines Teams bezahlen, aber dennoch wirkt sich die Arbeit dieser Teams auf die Kosten oder Einnahmen deines Unternehmens aus.
Verbessert dein Team seine Leistung, so verbessert dein Team den Gewinn des Unternehmens.
Hier ein Beispiel für ein „Objective“ eines Teams aus dem Bereich IT-Operations und IT-Infrastruktur:
„Erleichterung der Entwicklungs- und Deployment-Prozesse der Produktteams, um Releases schneller und zuverlässiger auszuliefern.“
Die fehlende Konzentration auf den Kunden bringt uns zum nächsten Fehler:
Fehler #2: Die „Key Results“ beschreiben Güter
Eine Tragik unserer modernen Arbeitskultur ist Burnout.
Neben den offensichtlichen Leidtragenden hat Burnout auch negative Konsequenzen für das Unternehmen: Die Produktivität der Mitarbeiter sinkt, Fehlzeiten und Krankmeldungen steigen. Und nicht zuletzt ist es wenig überraschend, dass Mitarbeiter nach einem Burnout den Arbeitsplatz wechseln wollen.
All das sind Gründe, warum Unternehmen versuchen, Burnout zu verhindern. Deshalb ist es vielen Unternehmen wichtig, dass die Mitarbeiter regelmäßig Urlaub nehmen, um sich zu erholen.
Zwei Beispiele, wie Unternehmen dies umsetzen:
Ende der 2000er Jahre haben einige Unternehmen in den USA erkannt, dass ihre Mitarbeiter nicht all ihre Urlaubstage nutzen. Deshalb gaben sie ihnen die Möglichkeit, unbegrenzt Urlaub zu nehmen – darunter Netflix, Zoom, LinkedIn und Twitter. Das Unternehmen Basecamp wählte einen anderen Ansatz:
„Die meiste Zeit im Jahr arbeiten wir vierzig Stunden pro Woche, im Sommer nur 32. Alle drei Jahre können unsere Mitarbeiter für mehrere Monate ein Sabbatical machen. Und sie bekommen nicht nur Urlaubsgeld – wir zahlen ihnen auch die Urlaubsreise.“
Welcher Ansatz führt dazu, dass sich die Mitarbeiter besser erholen und weniger an Burnout leiden?
Um ehrlich zu sein: Ich weiß es nicht. Aber darum geht es auch nicht. Es geht darum, dass unbegrenzter Urlaub oder bezahlte Urlaubsreisen eine Lösung darstellen. Sie sind ein Output.
Über Erfolg oder Misserfolg entscheidet aber nicht die Frage, ob wir etwas produzieren können. Entscheidend ist, ob es das Verhalten der Mitarbeiter verändert – und ob dieses Verhalten dann einen positiven Effekt auf das Unternehmen hat.
Mit anderen Worten:
Welcher Output führt zu einer Verhaltensänderung des Kunden, die das Unternehmen erfolgreich macht?
Um diese Verhaltensänderung zu beschreiben – dafür gibt es die „Key Results“. Sie definieren die Veränderungen im Kundenverhalten, die Teams als Ergebnis ihrer Arbeit sehen wollen.
Ein Fehler ist es, die Lösung oder das Feature, das das Team produziert, also den Output, als „Key Result“ zu nutzen. Diese Resultate verlieren den wirklichen Erfolg oder Misserfolg aus den Augen.
Ach, und ich spreche wieder von Kunden. Vielleicht ist es in deiner Situation „nur“ ein interner Kunde.
In unserem Beispiel könnte ein Key Result so lauten:
„Die Anzahl der erfolgreichen Deployments der Produktteams pro Woche hat sich um 20 % erhöht.“
Fehler #3: OKRs sind kein Prozess
OKRs sind keine Methode, um Ziele zu setzen.
Verwirrt? Okay, dann bleib bei mir. Was meine ich damit, dass OKRs keine Methode sind? OKRs zu nutzen, bedeutet eben nicht, sich nur einmal alle drei Monate neue Ziele zu setzen – und das war’s. Mit OKRs zu arbeiten, bedeutet auch nicht, dass es in Ordnung ist, wenn drei Monate zu knapp bemessen sind, um das Projekt zu schaffen, und wir deshalb erst in sechs Monaten neue Ziele definieren.
Es geht um weit mehr.
Die Nutzung von OKRs ist der Prozess, um die Arbeit zu lenken und sie auf die Erreichung von Zielen auszurichten. OKRs zu verwenden, ist eine Einstellung dazu, wie die Arbeit erledigt werden sollte.
Im Herzen sind OKRs sehr ähnlich zu Scrum.
Scrum ist ein Prozess, um das Risiko, das in der Entwicklung von Produkten besteht, zu minimieren. Dabei fußt Scrum auf empirischem Arbeiten.
Das Team setzt sich Ziele für das Produkt, überprüft bei der Entwicklung regelmäßig den Fortschritt dorthin und passt die Arbeit an, wenn es eine Abweichung erkennt. Der Scrum Guide beschreibt es so:
„Die Scrum-Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Um bei der Überprüfung zu helfen, bietet Scrum einen Rhythmus in Form seiner fünf Events.“
Unternehmen, die OKRs nutzen, gehen ähnlich vor:
- Teams setzen sich OKRs.
- Teams verrichten Arbeiten, die auf die Erreichung der OKRs einzahlen sollten.
- Teams führen regelmäßig Review-Meetings durch, um den Fortschritt zu bewerten.
Was allerdings erfolgreiche von erfolglosen Teams unterscheidet, ist der Rhythmus. In Scrum ist er fest vorgegeben – wir nennen diese Abschnitte Sprints und sie dauern 30 Tage.
Bei OKRs wird dies häufig übersehen. Und darin steckt der letzte Fehler für heute. Da der Rhythmus bei der Nutzung von OKRs nicht vorgegeben wird, haben Unternehmen und Teams hier Freiheit. Der Rhythmus zur Überprüfung bei OKRs auf Unternehmensniveau könnte etwa ein Jahr sein. Bei OKRs auf Teamniveau nur drei Monate.
Aber keinen Rhythmus zu definieren oder einen zu langen zu wählen, ist fatal für die Agilität.
Denn Agilität bedeutet gerade, sich davon abzuwenden, die Zukunft vorhersagen zu wollen und unsere Arbeit für Monate oder Jahre im Voraus zu planen. Erst, die Arbeit in Rhythmen zu strukturieren, erlaubt es, Ideen zu testen, Einsichten zu gewinnen und dann zu iterieren, um sie zu verbessern. Wenn wir auf der Grundlage von Erkenntnissen Kurskorrekturen vornehmen, verhalten wir uns agil.
Und darum geht es bei OKRs, Scrum und evidenzbasiertem Management doch am Ende.
Sucht du nach deinem Einstieg in diese moderne Art des Managements? Dann könnte der erste Schritt der Besuch meines „Professional Agile Leader – EBM“-Trainings sein.