Gerade in größeren Organisationen ist es schwer mit mehreren Unternehmensteilen gemeinsam größere Vorhaben zu priorisieren und umzusetzen.
Die nötige Abstimmung ist aufwendig und ein gemeinsames Commitment zu erreichen schwierig, weil die einzelnen Bereiche oft eigene, lokale Prioritäten haben. Eine sehr beliebte Lösung für dieses Problem ist die Methodik von “Objectives and Key Results” (OKRs). Sie sorgen auch in komplexen Organisationen für abgestimmte, einheitliche Ziele.
So weit die Theorie. Praktisch habe ich OKRs in zwei Firmen im Einsatz erlebt und bin kein Freund von ihnen geworden.
Aus 3 Gründen halte ich OKRs in größeren Unternehmungen für nicht gut geeignet um Ziele und Richtung zu geben:
- Der OKR-Prozess ist zu aufwändig.
- OKRs sind nicht agil und behindern langfristiges Handeln.
- OKRs geben nicht die Orientierung, die sie geben sollen.
Bevor ich diese drei Schwierigkeiten erläutere, fasse ich kurz zusammen, wie ein OKR-Prozess funktioniert.
Wie funktionieren OKRs?
Zunächst zu den Begrifflichkeiten: Objectives beschreiben längerfristige Ziele, die ich erreichen möchte. Key Results sind Zwischenschritte oder Teilergebnisse auf dem Weg ein Objective zu erreichen.
Im OKR-Prozess werden beide in einem festen Rhythmus – typischerweise quartalsweise oder halbjährlich – festgelegt und zwar als eine Mischung aus Top-Down-Vorgaben seitens der Geschäftsführung und Bottom-Up-Initiativen aus den Unternehmensteilen. Idealerweise gibt es für das Gesamtunternehmen einen Satz von OKRs. Die darunter gefassten Unternehmensteile greifen diese in eigenen OKRs auf, indem diese auf die jeweils übergeordneten einzahlen. In der Theorie werden Gesamtziele so in die gesamte Organisation heruntergebrochen, bzw. tragen alle Teilorganisationen zu übergeordneten Zielen bei.
Sind die OKRs vereinbart, arbeiten alle Einheiten bis zum Ende der Periode daran sie zu erfüllen. Während der Umsetzung und am Ende wird das Erreichen der einzelnen Ziele bewertet. Danach beginnt ein neuer Planungs- und Umsetzungszyklus. Ein wichtiges Prinzip ist es, für eine Einheit die Zahl der Objectives und Key Results zu beschränken, um Fokus in der Organisation zu erreichen.
Der OKR-Prozess ist zu aufwändig
Womit wir beim ersten Kritikpunkt wären. Ein Schlüsselelement des gesamten Prozesses ist die Festlegung der Ziele für den kommenden Zyklus. Bei vorgegebenen Top-Level-Zielen müssen sich alle Einheiten einigen, welche Initiativen sie umsetzen wollen, die darauf einzahlen. In der Regel hat jede Einheit eigene Ideen, die oftmals auch die Unterstützung anderer Einheiten benötigen. Dies mag kontraintuitiv klingen, haben doch alle Einheiten die gleichen übergeordneten Ziele. Diese sind jedoch oft sehr allgemein, da sie für die ganze Firma gelten sollen, z. B. “Wir erweitern unser Geschäftsmodell um eine neue Produktkategorie” oder “Wir erschließen eine neue Kundengruppe”. Dadurch kann sich jede Unternehmenseinheit dann leicht viele eigene Initiativen ausdenken, die darauf einzahlen und potenziell der eigenen Einheit zusätzlich nützen, z. B. indem dabei ein ohnehin lang gewünschtes Feature endlich umgesetzt wird.
Aus diesem Grund beginnen die einzelnen Unternehmensteile vor einem OKR-Zyklus hektisch ihre Ideen vorzubereiten, indem sie sie beschreiben, Business Cases aufstellen, die Abstimmung mit anderen Einheiten beginnen, die für die Umsetzung nötig sind, und so weiter. Dieser Aufwand wird oft über alle Einheiten multipliziert, so dass ich schon erlebt habe, dass die halbe Unternehmung nur mit dem Vorbereiten der nächsten OKRs beschäftigt war.
All das wäre durchaus produktiv, wenn denn all die Ideen auch als Ziele vereinbart werden könnten. Dies ist aber genau nicht der Fall, da die OKR-Methodik – völlig zu Recht – vorsieht, dass nicht zu viele Ziele gleichzeitig verfolgt werden. Zu den schon aufwändigen Vorbereitungen kommen also noch harte Verhandlungen hinzu, an deren Ende aber so oder so ein großer Teil der vorbereiteten OKRs nicht aufgenommen wird. Diese Verschwendung von Arbeitszeit findet zu Beginn jedes OKR-Zyklus wieder statt (was nebenbei typischerweise auch viel Frust in der Organisation erzeugt).
Manchmal war die halbe Unternehmung nur mit dem Vorbereiten der nächsten OKRs beschäftigt.
OKRs sind nicht agil und behindern langfristige Produktentwicklung
Damit sind wir beim zweiten Kritikpunkt. Ähnlich wie das SAFe Framework zwingen OKRs Unternehmungen in einen festen Rhythmus. Die Dauer des Zyklus bestimmt, wie viel Zeit für die einzelnen Initiativen zur Verfügung steht, also zwischen 3 und 6 Monaten. In den Umgebungen, in denen ich OKRs erlebt habe, führte das dazu, dass am Ende des Zyklus die Initiativen oft fallen gelassen wurden. Die nächsten Ziele standen an und nur deren Erfolg wurde im nächsten Zyklus gemessen – insofern gab es wenig Anreiz “alte Ziele” weiter zu verfolgen.
Digitale Produktentwicklung ist aber nicht innerhalb von 6 Monaten abgeschlossen. Gerade bei innovativen Produkten ist dann vielleicht erst der Punkt erreicht, an dem man genug gelernt hat um sie wirklich erfolgreich zu machen. Dann fehlt aber die Bereitschaft noch einmal andere Initiativen dafür zurückzustellen und so endet die Entwicklung des Produktes, bevor es fliegen konnte. Langfristige Innovation wird so erschwert, kurzfristiges Denken gefördert.
Oft kann man in OKR-gesteuerten Unternehmungen auch eine Tendenz der einzelnen Einheiten beobachten eigene Ziele möglichst lokal, d. h. mit so wenig Abhängigkeiten wie möglich zu planen. Das ist eine nachvollziehbare Reaktion angesichts der oben beschriebenen Abstimmungsprobleme, führt aber ebenso dazu, dass tendenziell lokal optimierende Vorhaben durchgeführt werden anstatt globale und innovative. Diese vielzitierte Schwerfälligkeit der “großen Tanker” kann in einem innovativen Umfeld den Untergang bedeuten.
Durch die feste Taktung von OKRs wird langfristige Innovation erschwert und kurzfristiges Denken gefördert.
Auch beraubt sich eine Unternehmung mit dem festen Zyklus selbst der Flexibilität. In OKR-gesteuerten Organisationen ist es nahezu unmöglich ein größeres Vorhaben während eines laufenden Zyklus zu starten, selbst wenn sich abrupt ändernde Marktbedingungen das erfordern.
OKRs geben nicht die Orientierung, die sie geben sollen
Mein letzter Kritikpunkt richtet sich erstaunlicherweise gegen genau das, was OKRs eigentlich versprechen: Ich habe mehrfach erlebt, dass sie nicht für die Orientierung sorgen, derentwegen sie typischerweise eingeführt werden.
In größeren Unternehmungen ab ungefähr zehn Einheiten entstehen trotz zentral vorgegebenen OKRs plötzlich so viele konkurrierende OKRs, dass es für die einzelnen Einheiten dennoch unübersichtlich wird. Eine Einheit, die sich eigene OKRs gesetzt hat, die auf die Unternehmens-OKRs einzahlen, bekommt plötzlich viele Anfragen von anderen Einheiten, die das selbe tun und für ihre OKRs die Unterstützung der ersten Einheit benötigen. Auch sonst kommen Unterstützungsanfragen unabhängig von OKRs regelmäßig herein, allerdings werden sie nun mit der Dringlichkeit herangetragen, dass sie der Erreichung wichtiger OKRs dienen und deshalb doch bitte priorisiert eingeplant werden sollten.
In Unternehmungen ab etwa zehn Einheiten entstehen so viele konkurrierende OKRs, dass es für die einzelnen Einheiten unübersichtlich wird.
Je größer Unternehmungen sind, desto mehr Abhängigkeiten zwischen Einheiten gibt es und desto mehr Anfragen sollen einzelne Einheiten bei ihrer Planung berücksichtigen. Im günstigen Fall werden solche Abhängigkeiten schon in der Planungsphase identifiziert und zwischen den Einheiten besprochen. Da OKRs jedoch Ziele und nicht den Weg vorgeben, werden Abhängigkeiten zu anderen Einheiten manchmal erst während der Umsetzung entdeckt, nachdem die angestrebte Lösung konzipiert wurde. In der Folge werden einzelne Einheiten, die eigentlich ihre eigenen OKRs planen und umsetzen wollen, plötzlich mit unzähligen, konkurrierenden Anfragen überladen, die auch alle wichtig sind. Einerseits ruiniert das die Planbarkeit, andererseits findet sich solch eine Einheit schnell im Priorisierungsdilemma wieder, aus dem OKRs eigentlich der Ausweg sein sollten.
Fazit
Die geschilderten drei Kritikpunkte an OKRs habe ich mehrfach erlebt. Vielleicht war dabei die Methodik jeweils falsch umgesetzt – das wäre möglich:
- Vielleicht haben wir tatsächlich zu viel Aufwand in die Vorbereitung und Abstimmung von bottom-up-geplanten OKRs investiert. Vielleicht hätte der Prozess stärker top-down vorgegeben werden müssen. Aber hemmt das nicht auch Innovation?
- Mangelnde Agilität durch die fixen Zyklen ließe sich abmildern durch die Verkürzung des Zyklus. Das wiederum würde jedoch noch häufiger zu dem beschriebenen Vorbereitungsirrsinn und zu noch kurzfristigerem Denken führen. Wäre das ein erfolgversprechender Ansatz?
- Das kurzfristige Denken und Handeln ließe sich abmildern, wenn denn Objectives über mehrere Zyklen bestehen blieben, wie es die Methodik eigentlich vorsieht. Erlebt habe ich das oft anders.
- Vielleicht kann man die Anzahl an vereinbarten OKRs auch noch strikter begrenzen um tatsächlich Orientierung zu schaffen anstatt Verwirrung.
Ich glaube in kleineren Firmen können OKRs durchaus gut funktionieren, da sich diese Probleme dort einfacher vermeiden lassen.
Dennoch glaube ich, dass es insgesamt bessere Methoden gibt um Vorhabenplanung und Priorisierung für eine Unternehmung so zu gestalten, dass sie innovativ, agil und mit Fokus arbeitet. Eine Alternative ist die rollierende Vorhabenplanung, die ich in diesem Artikel beschreibe.
Wie siehst du das? Teilst du meine Erfahrungen mit OKRs oder hast du andere gemacht? Lass es mich in den Kommentaren wissen und auch gerne, ob du Interesse an weiteren Artikeln zu agiler Planung und Priorisierung hast.
Hi Jan,
ich bin nach wie vor Fan von OKRs und ich habe erlebt, dass es stark davon abhängt, wie das Framework eingesetzt wird. Bei Visual Meta haben wir das Framework gut an unseren Kontext angepasst, und in mehreren Iterationen optimiert. Wir nutzen mittlerweile z.B. 4-monatige „OKR-Seasons“ und langfristige Objectives, die von der Strategie abgeleitet werden.
Wir sind „nur“ 250 Mitarbeiter allerdings mit deutlich über 10 Einheiten / Teams. Für sehr wichtig halte ich teamübergreifend an den Objectives und Unternehmens-KRs orientiert ins Alignment zu gehen anstatt mit teaminternem Alignment zu starten.
Die Planning-Phasen bedeuten viel Aufwand, funktionieren aber mit jeder Iteration besser, vor allem wenn fortlaufend und nicht erst im OKR Planning an Konzepten gearbeitet wird. Deren Umsetzung kann dann im OKR Framework eingetaktet werden und viele Abhängigkeiten sind frühzeitig bekannt.
Wenn du Tipps zu anderen Methoden / Frameworks hast, freue ich mich auf Inspiration.
Schöne Grüße
Philipp
Hi Philipp,
das freut mich sehr zu hören, denn anscheinend habt ihr das ganz gut im Griff.
Die langfristigen und vorgegebenen Objectives finde ich sehr wichtig und auch den Ansatz nicht alles zu festen Zeitpunkten abzustimmen, sondern fortlaufend die Themen vorzubereiten. Vielen Dank für die Einblicke!
Ich glaube ich werde demnächst mal einen Folgeartikel schreiben.
Viele Grüße!
Jan
Hallo Jan,
danke für den interessanten Artikel (Franzi Grunwald hat ihn mir weitergeleitet) und die Einblicke zu deinen Erfahrungen mit OKRs. Deinen Beobachtungen kann ich größtenteils folgen – ein paar Erlebnisse hatten wir ja sogar gemeinsam dazu 😉
Ich habe allerdings die Vermutung, dass Ursache und Wirkung bei Problemen mit dem OKR-Framework oft vertauscht werden. Natürlich ist es ein Leichtes, stets zu behaupten, die Methode sei gut, aber die Ausführung schlecht; dennoch glaube ich, dass OKR besser sind als ihr Ruf in vielen Unternehmen, die möglicherweise bereits in einer post-OKR-Phase sind. Zwei Gedanken dazu, die mich zu dieser Annahme führen:
1. OKRs sind ein Zielframework, werden aber meist zur Ordnung und Priorisierung von Projekt(-inkremt)en verwendet.
Dann können sie ja gar nicht wirksam funktionieren. J. Doerr schlägt vor, OKR nach dem Muster „I will ___ (Objective) as measured by ___ (Key Result) zu formulieren. Diesem Muster folgen die wenigsten OKR, die ich bislang gesehen habe; vielmehr finden sich viele Projektmeilensteine neben einigen messbaren Key Results. Da beides grundverschiedene Elemente in einem Zielframework sind, kann es gar nicht funktionieren, mit diesen Bausteinen sinnvoll zu planen – Abstimmungskonflikte entstehen, Ressourcen werden verschachert und Deadlines werden auf einmal existenziell bedrohlich oder geflissentlich ignoriert. Quel Malheur!
2. Mit einer partizipativen bottom-up-Planung ist es wie mit einer Demokratie.
Da jeder (an der Planung Beteiligter/Wähler) unterschiedliche Interessen hegt (qua Rolle), individuelle Ziele verfolgt (qua Individuum) und zusätzlich nur über einen Ausschnitt aus allen verfügbaren und möglicherweise zur Entscheidungsfindung benötigten Informationen verfügt, ergibt sich ein heterogenes Gesamtbild; dieses aufzulösen erfordert Zeit und Arbeit und gelingt meist nicht ohne den von dir erwähnten Frust. Konflikte werden oft nicht fachlich gelöst, sondern als Minimalkompromiss beigelegt, der als kleinstes gemeinsames Vielfaches eigentlich für keine Seite gut ist. Nach einer Wahl nennt man das dann „Koalitionsvertrag“…
Was ich zum Ausdruck bringen möchte, ist, dass OKR in einer perfekten Welt mit absolut altruistischen Beteiligten, die über gleichverteilte, vollständige & valide Informationen verfügen und nur zum höheren Ruhme Got… äh, des Arbeitgebers entscheiden, vermutlich hervorragend funktionieren würden.
Leider leben wir nicht in einer perfekten Welt. Seufz.
Daher, um diesen Monsterkommentar auch endlich mal abzuschließen, würde ich mich sehr über einen Folgeartikel über deine Erfahrungen mit OKR-Alternativen freuen 🙂
Schöne Grüße,
Fabi
Hey Fabi,
vielen Dank auch für deine Gedanken – in vielen davon finde ich mich gut wieder. Die Frage, die du implizit als Letztes aufwirfst, finde ich sehr interessant: wie gut denn ein Framework ist, das anscheinend sehr viele falsch anwenden – was dann regelmäßig als Begründung für das Nicht-Funktionieren herangezogen wird. Liegt das dann an den Menschen oder am Framework?
Den Folgeartikel habe ich mir vorgenommen, wird aber sicherlich ein bisschen dauern. 🙂
Vielen Dank für dein Feedback und viele Grüße!
Jan
Hey Jan,
ich erkenne die Muster, die du beschreibst. Für mich stellt sich zunächst die Frage, was zu diesen Mustern führt. Ist es tatsächlich das konkrete framework, das hier nicht funktioniert, oder liegt dem etwas anderes zu Grunde? Meine Befürchtung ist, dass in Organisationen, die deine Geschichte wiederspiegeln, auch der Einsatz anderer Lösungen nicht wirklich viel verändert. Vielleicht können frameworks, die stärker auf zentrale Projektsteuerung setzen, uns den Eindruck der Beherrschbarkeit vermitteln, ggf. auch über zentrale Entscheidungen, kurzfristig optimieren. Wie haben dann den Eindruck von Planbarkeit.
Was aber geschieht, wenn man an einem anderen Punkt ansetzt? Ziele setzen ohne von Planung zu sprechen, also vor allem die Ausrichtung des Unternehmens ins Auge zu fassen wäre ein Weg. Wenn es gelingt Unternehmensziele zu etablierten, die von allen Mitarbeitenden getragen werden, könnten strukturelle Grenzen zwischen Einheiten durchlässig sein. Wenn in einem Bereich die eigenen Vorhaben gut voran gehen, ist die Unterstützung der Vorhaben anderer Bereiche kein Verlust mehr, sondern die Arbeit an der gemeinsamen Zielsetzung. Harte Verhandlungen in der Planungsphase werden vielleicht ersetzt durch kollektive Betrachtung des Potentials. Natürlich gilt es noch andere Fallstricke zu eliminieren, Konkurrenz durch etwaige Belohnungssysteme zu vermeiden und die Unabhängigkeit der Einheiten zu stärken etwa. Auch Reduktion des WIP beziehungsweise hier „Goals in Progress“ ist ein Klassiker.
Auf jeden Fall halte ich ein Plädoyer mehr über das Selbstverständnis der Organisation und weniger über das tooling zu sprechen, wenn wir wirklich agile und erfolgreiche Unternehmungen gestalten wollen.
Hey Sven,
vielen Dank für deinen Beitrag!
In der Tat beginnt alles viel früher als beim Framework für Zielsetzungen. Ich habe im Artikel auch nicht hervorgehoben, dass OKRs eigentlich immer eine Strategie voraussetzen, aus der Ziele abgeleitet werden sollen. Oftmals fehlt ja schon diese.
Die Idee, die du beschreibst, klingt spannend und würde ich sehr gerne mal erleben.
Die meisten der von dir genannten Voraussetzungen sehe ich auch als notwendig an- mit Ausnahme von einer: „Unabhängigkeit der Einheiten stärken“. Hier bin ich mir überhaupt nicht sicher.
Wenn wir eine kollektive Ausrichtung auf Ziele hätten, fände ich sogar eine weniger strikte Trennung zwischen Einheiten erstrebenswert. Dann könnte man idealerweise sogar nachdenken, dass Mitarbeiter an den übergeordneten Themen arbeiten, unabhängig von ihrer organisatorischen Heimat, sondern wirklich fokussiert auf den Gesamterfolg der Unternehmung. In solch einem Szenario nähme die Bedeutung von Organisationseinheiten eher ab und es gäbe keine Notwendigkeit mehr sie stark und unabhängig zu machen. Die Organisation würde eher fluide.
Viele Grüße!
Jan
Hallo Jan,
wir experimentieren derzeit auch mit OKRs.
Unsere Rahmenbedingungen sind aber gänzlich anders als bei Dir:
– 70 Mitarbeoter*innen
– wir haben eine Strategie, die jedes Jahr aufs neue justiert wird und allen MA auch ohne OKR klar ist
– wir arbeiten schon vor den OKRs sehr dezentral organisiert, d.h. die „Abteilungen“ bei uns haben viel mehr Freiräume – vermute ich mal
– Unser Geschäftsmodell ist die Durchführung von Projekten im Auftrag des Kunden und unsere Strategie ist quasi orthogonal dazu aufgestellt.
Warum wir OKRs ausprobieren?
Wir arbeiten sowieso schon strategisch an Themen. Die Abteilungen für sich und auch zusammen also übergreifend. Es gibt keine top-down-Vorgabe. Wir hatten das Problem, das uns hier eine Transparenz fehlte, die dann auch zu Reibungsverlusten führten.
Die OKRs helfen uns aktuell dabei zielgerichteter und transparenter an unseren strategischen Themen zu arbeiten (die eben anders sind, siehe unser Geschäftsmodell) und „Langläufer“ zu erkennen und zu vermeiden.
Das soweit von uns – der akquinet tech@spree
Tassilo
Hallo Tassilo,
vielen Dank für deinen Erfahrungsbericht. Das klingt in der Tat nach einem aussichtsreichen Ansatz – weiterhin viel Erfolg dabei!
Einen deiner Punkte finde ich besonders wichtig: Generell setzen OKRs eine übergreifende und klare (das heißt so konkret, dass sie umsetzbar ist) Strategie voraus.
Da ihr ein Dienstleister bzw. eine Beratung seid, interessiert mich sehr, was ihr mittels OKRs abbildet: Sind das dann Maßnahmen zum Ausbau eures Leistungsangebotes, zur Kundenakquise oder Maßnahmen zur Mitarbeiterentwicklung oder was kann ich mir darunter vorstellen?
Vielen Dank und viele Grüße!
Jan
Hallo Jan,
ja genau diese Aspekte sind es. Also die !Querschnittsthemen“ die wichtig sind, um das Fundament für unser Geschäftsmodell zu „optimieren“.
Das sind z.B. Projekte zur Verbesserung des Projektlernens, der Angebotserstellung, der Selbstorganisation von Teams. Aber auch interne Forschungen bzgl. brandneuer Technologien, die wir gerne einsetzen wollen.
Mit OKRs klappt das echt gut – sind auch ausreichend entkoppelt und folgende dennoch eindeutig unseren strategischen Zielen.
Alles Gute
Tassilo
Sehr schön – vielen Dank fürs Teilen!
Dear Jan & readers, please excuse my lack of German language skills to articulate thoughts on this topic, and that I may miss some nuances of the article in my use of translation.
I coincidentally became interested in these ideas recently, but have not experienced OKRs myself as a non-management contributor so I suppose you can consider this a theoretical perspective. I read this article and its comments, then ‚Measure What Matters'(MWM), then both again. I think a lot of what you observed in practice may have come down to a naively implemented structure for the OKRs and insufficient quality of execution to make them successful. On your points:
1.The OKR process is too complex.
I agree in your example and assumed method (highly bottom-up driven OKRs), when you have many teams, it will cause mass confusion and wasted time preparing and negotiating which OKRs to pursue. I think the solution must be some top-down directional guidance on objectives, as long as it is understood teams have the capacity to challenge that if they think they have a better initiative. This you also concluded.
2.OKRs are not agile and hinder long-term action.
I also agree that in the characterisation you made – fixed cycles of 3, 6 months and dropping the OKR afterwards. This is not a good or optimal way to implement OKRs, and certainly would fail to enable long term value creation and agile thinking (customers needs do not appear and dissolve in a fixed cadence). However I would argue this characterisation is a naive implementation – in MWM there were a few examples I can think of where they were implemented differently. Firstly about cadence; JD explicitly says that at Intel, they considered rolling-over OKRs if not achieved. Similarly, at Google, they had an idea that in advance it should be planned if the OKR is ‚committed‘ or not – meaning must be achieved. And that any missed committed OKR must trigger an investigation. These processes guard against a „pick up and drop immediately“ type problem you describe.
Secondly about long term; there is again an example in the book of a multi-year OKR for YouTube to hit 1bn hours watch time. Again it was aligned and agreed to at management level – this informed my conclusion above about necessity for top-down input, especially in a large organisation.
In the conclusion you noted the possible solution to roll-over OKRs and I agree with you on that.
3. It’s my opinion that OKRs don’t give the orientation they are supposed to give.
I think this follows from assumptions about the organisation of the company (many small units) and what I referred to already addressing point 2. I think again this can be solved by top-down input, this you also anticipated writing „Perhaps the process should have been given more top-down. But doesn’t that also inhibit innovation?“. I think this is an interesting discussion to take forward but outside the scope of this comment 😉 – I think the answer to this question can be „no“ under the right conditions.
To conclude I think you anticipated most of the solutions to the situations you write about from your own experience.
Personally, I see the kernel of this system being getting the balance of long-term, directional input from management vs bottom-up agile thinking, to ensure that value is created but innovation is not strangled. I think this is difficult to do, but achievable with good and agile-experienced leaders, and I am confident that if agile companies continue to survive and thrive in their respective markets that we will have more such leaders.
Another note, which you also alluded to in your conclusion with a comment that „it’s much easier for smaller companies“ – I also agree. I think the trouble you see with OKR implementation is that they have been introduced fairly recently, and the companies they have been introduced to are large and the existing culture (which is sometimes anathema to the OKR) is already ingrained. I predict that if Google did not start early with this OKR idea, that given their size, they would suffer very similar growing pains and perhaps even abandon the project. Then, it is no surprise that you and others also experienced pains upon their introduction when working at large companies who introduce it „late“ in their maturity.
Those are some thoughts, hope they were useful. I can imagine we could also find some more specific points to discuss on this topic relating to our common interests, I would happily take those up separately, if you would be interested.
Any case, thank you for writing the thought-provoking article.
Best,
Ceri
Hi Ceri,
Thanks a lot for your deep thoughts! And there really is no need to apologize for a lack of German skills. I’ve thought already multiple times about writing in English, but so far shied away from it because of the effort to make the website multilingual. But maybe in the future… 🙂
To the topic of OKRs. I think you summarized it very precisely: A lot of the challenges of OKRs is finding a good balance between top-down and bottom-up approaches.
The thought of „growing with OKRs as a company“ is very interesting. I did not think about it this way so far, but it makes perfect sense to me how you describe it.
For sure I am interested in deepening our conversation around OKRs. Looking forward to that!
But until then: Thanks a lot again for sharing your thoughts here – they have been a great addition to the discussion!
Best,
Jan
Lieber Jan,
Ich denke ich kann deine Argumente gut nachvollziehen und habe diese auch schon selbst in einigen Unternehmen beobachten können.
Meiner Meinung nach ist die Ursache jedoch in dem Fehler begründet dass die Objectives nicht genug strategisch definiert werden. Was ich sagen will ist, wenn die Objectives als Mittel zur Implementierung der Vision einer Unternehmung definiert werden würden, wären sie der Leuchtturm den die Unternehmensbereiche nutzen könnten ihrerseits ihren Beitrag zur Umsetzung der Vision zu definieren. Dann wären die vergleichsweise langen Zyklen auch nicht störend und tragen dazu bei die einzelnen Bereiche nach der Vision und Strategie auszurichten….
Je weiter die Key Results dann nach unten breche je agiler muss ich werden.
Das führt mich zu der Schlussfolgerung, dass die OKRs eher ein Mittel der strategischen Unternehmensplanung sind und als solche auch nicht viel mit Agilität zu tun haben. Die Produkte der verschiedenen Domänen und Bereiche, die mit ihren Key results letzten Endes zur Erreichung der Objectives zur Erreichung der Vision einzahlen, können dann mit Hilfe der Vorhabenplanung in kürzeren Zyklen im Sinne der Agilität an deren Umsetzung arbeiten.
Ohne eine effektive Kommunikation der Strategie und Vision und dem Versuch sein Tun und Handeln danach auszurichten ist eine Erreichung der Ziele um so schwerer je größer dax Unternehmen ist…..
Liebe Grüße
Holger
Hallo Holger,
deine Beobachtung ist völlig valide. Wenn Objectives zu taktisch eingesetzt werden, so sind sie häufig nicht hilfreich und erzeugen die geschilderten Probleme. Das ist auch gar nicht im Sinne der OKR-Methodik. Eigentlich sollten die Objectives immer die strategischen Ziele darstellen und Key Results die Schritte auf dem Weg dorthin – häufig Vorhaben.
Mit „nicht agil“ meine ich vor allem die starren Planungszyklen, die in erster Linie eben die Key Results betreffen, da Objectives idealerweise sowieso längerfristig gelten sollten. Die letztlich willkürliche, feste Dauer dieser Zyklen finde ich wenig agil, da sie sich nicht an den realen Dauern der laufenden Vorhaben orientiert.
Liebe Grüße!
Jan