Google hat OKRs nicht eingeführt, um Probleme zu lösen – sondern um Stärke zu bündeln

Es ist das Jahr 1999. Mountain View, Kalifornien. Google hat rund 40 Mitarbeitende, eine Suchmaschine, die besser ist als alles andere auf dem Markt, und ein Team voller brillanter Köpfe. Das Unternehmen funktioniert. Die Leute liefern. Die Kultur ist geprägt von Eigenverantwortung, technischer Exzellenz und einer fast schon radikalen Autonomie.

An einem Ping-Pong-Tisch, der gleichzeitig als Besprechungstisch dient, sitzen Larry Page, Sergey Brin, Marissa Mayer, Susan Wojcicki und Salar Kamangar. Vor ihnen steht John Doerr – Venture Capitalist bei Kleiner Perkins und frischer Investor bei Google – mit einer PowerPoint-Präsentation. Unter dem Arm hat er ein Framework, das er in den 1970ern von Andy Grove bei Intel gelernt hat. Grove, legendärer CEO und Management-Denker, hatte dort aufbauend auf Peter Druckers Management by Objectives ein eigenes System namens iMBOs (Intel Management by Objectives) entwickelt – eine disziplinierte Methode, um in einem komplexen Halbleiterunternehmen Klarheit über Ziele und messbaren Fortschritt zu schaffen. Doerr hat diesen Ansatz weiterentwickelt und gibt ihm einen neuen Namen: Objectives and Key Results. OKRs.

Ein Detail, das leicht übersehen wird: Auch Intel war zum Zeitpunkt der Einführung kein schwächelndes Unternehmen. Es war ein Marktführer. Hochfunktional. Leistungsstark. Grove hat OKRs nicht erfunden, um Intel auf Kurs zu bringen – sondern um einen bereits funktionierenden Konzern in einem sich schnell verändernden Markt fokussiert zu halten. Das Muster wiederholt sich bei Google.

Die Frage, die sich lohnt: Warum? Warum braucht ein Unternehmen, das offensichtlich funktioniert, ein neues System für Ziele?

Die Antwort auf diese Frage ist der Schlüssel dafür, ob OKRs in einem Unternehmen wirken – oder zur teuren Enttäuschung werden.

Das Problem, das Google wirklich hatte

Google hatte 1999 kein dominantes Delivery-Problem. Die Herausforderung lag nicht in instabilen Prozessen oder überlasteten Teams, die nicht wussten, was sie als Nächstes tun sollten. Die Engineering-Kultur war stark, die Umsetzungskraft im Vergleich zu den meisten Organisationen bemerkenswert hoch.

Was Google hatte, war ein Alignment-Problem – und es zeichnete sich ab, dass dieses Problem mit dem Wachstum explosionsartig zunehmen würde. Die zentrale Frage war nicht „Können wir liefern?", sondern: „Liefern wir das Richtige?"

Das Szenario ist typisch für schnell wachsende Organisationen: Dutzende hochautonomer Teams, jedes für sich brillant, jedes mit eigenen Ideen, eigenen Prioritäten, eigenen Überzeugungen davon, was gerade am wichtigsten ist. Die Folgen sind vorhersehbar:

• Teams arbeiten in unterschiedliche Richtungen, ohne es zu merken.
• Arbeit wird doppelt gemacht, weil niemand sieht, was die anderen tun.
• Lokale Optimierungen entstehen, die dem Gesamtergebnis nicht dienen.
• Es fehlt eine gemeinsame Antwort auf die Frage: Worauf arbeiten wir eigentlich hin – und wie hängt das zusammen?

Die Arbeit war da. Die Ergebnisse waren da. Aber niemand konnte mit Sicherheit sagen, ob diese Ergebnisse die richtigen waren – ob sie auf den Outcome einzahlten, der für Google als Ganzes zählte.

Das ist kein triviales Problem. Und es wird mit jedem neuen Team, jedem neuen Produkt, jeder neuen Initiative größer. Fragmentierung ist der natürliche Feind schnell wachsender Organisationen.

Was Google bewusst nicht wollte

An dieser Stelle wird es interessant. Denn die naheliegende Lösung für mangelnde Ausrichtung wäre ja: mehr Steuerung. Mehr Kontrolle. Mehr Top-down. Ein paar Führungskräfte setzen sich zusammen, definieren die Ziele, und alle anderen arbeiten sie ab.

Google hat sich bewusst dagegen entschieden. Larry Page und Sergey Brin wollten keine klassische Hierarchie, in der Ziele von oben diktiert werden. Keine bürokratischen Planungsprozesse. Keine zentrale Detailsteuerung.

Warum? Weil sie verstanden haben, dass genau diese Autonomie – die Freiheit der Teams, eigene Entscheidungen zu treffen – einer der größten Wettbewerbsvorteile von Google war. Wer Kontrolle einführt, um Alignment zu erzwingen, zerstört oft genau das, was das Unternehmen stark macht.

Die eigentliche Herausforderung war also vielschichtiger, als sie zunächst klingt:

Wie schafft man Ausrichtung in einem dezentralen, schnell wachsenden System – ohne zentrale Kontrolle?

Warum OKRs die Antwort waren

OKRs haben genau dieses Problem adressiert. Nicht mehr und nicht weniger. Ihr Kern ist radikal einfach: Objectives definieren, welches Ergebnis angestrebt wird – den gewünschten Outcome. Key Results messen, ob dieses Ergebnis tatsächlich eintritt. OKRs fokussieren damit nicht auf den Output (Was haben wir gebaut? Wie viel haben wir geliefert?), sondern auf den Impact (Hat das, was wir getan haben, die gewünschte Wirkung erzielt?).

Transparenz: Alle Ziele werden sichtbar gemacht. Jedes Team, jede Führungskraft kann sehen, woran die anderen arbeiten – und vor allem: worauf sie hinarbeiten. Keine Blackbox mehr, keine Silos.

Ausrichtung: Company-Level Objectives geben einen Rahmen vor. Teams leiten daraus ihre eigenen OKRs ab – sie werden nicht diktiert, sondern abgeleitet. Das ist ein entscheidender Unterschied: Der Rahmen kommt von oben, die Ausgestaltung von unten.

Autonomie: Teams definieren selbst, wie sie zu den übergeordneten Zielen beitragen. Sie wählen ihre eigenen Key Results, ihre eigenen Wege. Die Eigenverantwortung bleibt intakt.

Rhythmus ohne Bürokratie: Quartalsweise Zyklen schaffen regelmäßige Reflexion, ohne in starre Jahresplanung zu verfallen.

Und ein Detail, das oft übersehen wird: Google hat OKRs bewusst nicht direkt an Bonus- oder Zielvereinbarungssysteme gekoppelt. OKRs fließen zwar in den Gesamtkontext der Leistungsbetrachtung ein, aber das Erreichen oder Verfehlen einzelner Key Results bestimmt nicht über Gehalt oder Beförderung. Warum? Weil ambitionierte Ziele nur dann funktionieren, wenn das Verfehlen keine direkte Strafe nach sich zieht. Googles berühmte Erwartung, dass bei ambitionierten, sogenannten aspirational OKRs eine Zielerreichung von 60–70 % bereits als Erfolg gilt, funktioniert nur in einem System, das Ambition belohnt und nicht bestraft.

Das ist ein Punkt, an dem viele Unternehmen bei der Einführung von OKRs scheitern – aber dazu gleich mehr.

Was OKRs bei Google nicht lösen mussten

Mindestens genauso wichtig wie die Frage, was OKRs bei Google gelöst haben, ist die Frage, was sie nicht lösen mussten.

Google hatte bereits:

• Funktionierende Delivery. Die Teams lieferten. Produkte wurden gebaut, getestet, ausgerollt.
• Hohe Eigenverantwortung. Teams agierten selbstständig und übernahmen Ownership für ihre Ergebnisse.
• Hohe Umsetzungskraft. Die Organisation konnte Dinge umsetzen – und zwar schnell.
• Eine starke Engineering-Kultur. Qualität, technische Exzellenz und Handwerk waren tief verankert.

OKRs wurden nicht eingeführt, um Leistungsfähigkeit zu erzeugen. Sie wurden eingeführt, um vorhandene Leistungsfähigkeit auszurichten.

Oder noch schärfer formuliert: Google brauchte keine OKRs, um leistungsfähig zu werden. Sie brauchten OKRs, um ihre bereits vorhandene Leistungsfähigkeit zu bündeln.

Das ist der entscheidende Punkt. Und er wird fast überall übersehen.

Der Elefant im Raum: Warum OKRs in vielen Unternehmen nicht wirken

Jetzt machen wir den Sprung von 1999 ins Heute. In die Realität vieler Unternehmen, die OKRs einführen.

Zunächst eine wichtige Einordnung: Es geht hier nicht darum, Google zu kopieren. Die Rahmenbedingungen – Talentdichte, Kapital, Marktposition – sind in den meisten Organisationen fundamental andere. Aber das Muster, das hinter Googles OKR-Einführung steckt, ist universell: OKRs wirken dort, wo ein funktionierendes System Richtung braucht.

Und noch etwas: Wer als Geschäftsführerin oder Führungskraft OKRs einführen möchte, tut das selten aus Naivität. Die Suche nach einem System, das Fokus, Transparenz und Alignment schafft, ist absolut nachvollziehbar – gerade wenn man spürt, dass die Organisation an Schlagkraft verliert. Die Frage ist nur, ob OKRs das richtige Werkzeug für das tatsächliche Problem sind.

Ich erlebe regelmäßig Organisationen, die mit OKRs starten – nicht weil sie ein Alignment-Problem haben, sondern weil sie hoffen, dass OKRs ganz andere Probleme lösen:

• Überlastung. Teams arbeiten an zu vielen Dingen gleichzeitig. Die Hoffnung: OKRs erzwingen Fokus.
• Fehlende Priorisierung. Alles ist wichtig, nichts hat Vorrang. Die Hoffnung: OKRs schaffen Klarheit.
• Instabile Prozesse. Projekte werden nicht fertig, Releases sind unzuverlässig. Die Hoffnung: OKRs bringen Struktur.
• Unklare Verantwortlichkeiten. Niemand weiß, wer was entscheidet. Die Hoffnung: OKRs definieren Zuständigkeiten.

Das sind reale Probleme. Aber es sind keine Alignment-Probleme. Es sind Probleme der Lieferfähigkeit – also der Fähigkeit einer Organisation, Arbeit zuverlässig abzuschließen: priorisiert, mit begrenzter Parallelität und in stabilen Durchlaufzeiten. Und OKRs sind kein primäres Werkzeug für fehlende Lieferfähigkeit – sie können Defizite sichtbar machen, aber nicht die operative Grundlage schaffen, die es braucht, um Ziele auch tatsächlich zu erreichen.

Was passiert, wenn man OKRs auf ein fragiles System legt? Man bekommt wunderbar formulierte Objectives, die niemand erreicht. Man bekommt Key Results, die am Ende des Quartals rot sind – nicht weil das Ziel falsch war, sondern weil die Organisation nicht in der Lage war, darauf hinzuarbeiten. Man bekommt Frustration, OKR-Müdigkeit und am Ende die Aussage: „OKRs funktionieren bei uns nicht."

Aber die OKRs haben funktioniert. Sie haben genau das getan, wofür sie gemacht sind: sichtbar gemacht, dass die Organisation ein Problem hat. Nur eben nicht das Problem, das OKRs lösen können.

Der Kontrast, der alles erklärt

Der Unterschied zwischen Googles OKR-Einführung und dem, was in vielen Unternehmen heute passiert, lässt sich auf vier Dimensionen verdichten:

OKRs sind ein Verstärker. Sie verstärken das, was bereits da ist. In einem funktionierenden System verstärken sie Fokus, Transparenz und Ausrichtung. In einem dysfunktionalen System verstärken sie Sichtbarkeit – und zwar die Sichtbarkeit der Dysfunktion.

Das ist nicht schlecht. Aber es ist nicht das, was sich die meisten Unternehmen erhoffen, wenn sie OKRs einführen.

Was das für die Praxis bedeutet

Ich sage nicht, dass OKRs schlecht sind. Im Gegenteil – in der richtigen Situation sind sie ein hervorragendes Werkzeug. Aber die richtige Situation hat Voraussetzungen:

Erstens: Die Organisation muss liefern können. Wenn die Grundmechanik der Zusammenarbeit nicht funktioniert – wenn Projekte nicht abgeschlossen werden, wenn Releases instabil sind, wenn Teams im Dauerfeuerwehrmodus arbeiten – dann lösen OKRs das nicht. Dann braucht es erst andere Interventionen: WIP-Limits, um Überlastung sichtbar zu machen und zu reduzieren. Klare Entscheidungsrechte, damit Teams nicht in Abstimmungsschleifen versinken. Stabile Delivery-Zyklen, die Verlässlichkeit schaffen, bevor man ambitionierte Ziele draufsetzt. OKRs auf ein fragiles System zu legen ist, als würde man einem Marathon-Anfänger eine Pulsuhr kaufen – das Messgerät ist nicht das Problem.

Zweitens: OKRs dürfen nicht direkt an Vergütung oder Beförderung gekoppelt sein. Solange das Erreichen oder Verfehlen von OKRs direkte Konsequenzen für Gehalt oder Karriere hat, werden Teams konservative Ziele setzen. Dann verlieren OKRs genau das, was sie stark macht: die Ambition.

Drittens: Der Rahmen kommt von oben, die Ausgestaltung von unten. OKRs sind weder reines Top-down noch reines Bottom-up. Sie sind ein Gespräch zwischen Führung und Teams. Wer OKRs als reine Zielvorgabe einsetzt, hat Zielvereinbarungen in neuem Gewand. Wer sie rein Bottom-up laufen lässt, bekommt Alignment by Accident.

Wenn nicht OKRs – was dann?

Wenn die ehrliche Diagnose lautet, dass die Organisation ein Problem der Lieferfähigkeit hat, stellt sich die Folgefrage: Womit fangen wir an?

Hier lohnt sich der Blick auf zwei komplementäre Perspektiven: Lean Portfolio Management – die aktive Steuerung, welche Initiativen finanziert und gestartet werden – und die Orientierung am Flow of Work – die Frage, wie Arbeit tatsächlich durch die Organisation fließt.

OKRs beantworten: Liefern wir das Richtige? – die Outcome-Frage. Flow-Orientierung beantwortet die Frage davor: Können wir überhaupt zuverlässig liefern? – die Frage der Lieferfähigkeit. Beide Perspektiven ergänzen sich, aber die Reihenfolge ist entscheidend.

Überlastung sichtbar machen. Die meisten Organisationen haben kein Priorisierungsproblem – sie haben ein Depriorisierungsproblem. Alles wird angefangen, nichts wird konsequent fertig. WIP-Limits auf Portfolio-Ebene machen sichtbar, wie viele Initiativen tatsächlich gleichzeitig im System sind. Flow-Metriken wie Throughput und Cycle Time zeigen, dass mehr parallele Arbeit nicht zu mehr Ergebnissen führt – sondern zu längeren Durchlaufzeiten und mehr Kontextwechseln. OKRs können dieses Problem nicht lösen, weil sie Ziele setzen, aber nicht die Arbeitsmenge steuern.

Den Ressourcenfluss aktiv steuern. Lean Portfolio Management schafft eine Schicht zwischen strategischer Absicht und operativer Umsetzung. Welche Initiativen werden finanziert, welche nicht? Welche werden gestoppt, wenn sich Rahmenbedingungen ändern? Ein Unternehmen kann perfekte OKRs formulieren und trotzdem 15 strategische Initiativen parallel fahren, die sich gegenseitig die Kapazität nehmen. OKRs definieren Ziele – aber sie steuern nicht, wie viel Arbeit gleichzeitig ins System gedrückt wird.

Delivery stabilisieren, bevor man Richtung gibt. Wenn Arbeit in Queues feststeckt, wenn Übergaben zwischen Teams zu Wartezeiten führen, wenn es keine verlässlichen Delivery-Zyklen gibt, dann helfen auch die besten Objectives nicht. Flow-Metriken – Throughput, WIP, Cycle Time, Work Item Age – machen diese Engpässe sichtbar und steuerbar. Sie zeigen nicht was geliefert werden soll, sondern ob das System überhaupt in der Lage ist zu liefern.

Die Logik ist einfach: Zuerst die Lieferfähigkeit herstellen, dann die Richtung schärfen. Oder anders: Zuerst sicherstellen, dass das Schiff fahrtüchtig ist – dann den Kompass einstellen.

Die eigentliche Frage

Bevor ein Unternehmen über OKRs nachdenkt, lohnt sich eine ehrliche Bestandsaufnahme:

Haben wir ein Problem der Ausrichtung – oder ein Problem der Lieferfähigkeit?

Wenn Teams in unterschiedliche Richtungen arbeiten, obwohl jedes für sich gut funktioniert: OKRs können helfen.

Wenn Teams gar nicht in der Lage sind, ihre aktuelle Arbeit zuverlässig abzuschließen: OKRs werden das nicht lösen. Sie werden es nur sichtbarer machen.

Google hat OKRs eingeführt, um Richtung zu schaffen. Viele Unternehmen führen OKRs ein, um Probleme zu lösen, die nichts mit Richtung zu tun haben.

Der Unterschied klingt subtil. Aber er entscheidet darüber, ob OKRs zum Gamechanger werden – oder zum nächsten Framework, das nach zwei Quartalen in der Schublade landet.

Ein letzter Gedanke

Andy Grove hat bei Intel einmal sinngemäß gesagt, dass es keinen Sinn hat, den Kompass zu optimieren, wenn das Schiff ein Loch im Rumpf hat. OKRs sind ein hervorragender Kompass. Aber sie reparieren keine Rümpfe. Wer das erkannt hat, kann beides in die richtige Reihenfolge bringen – und genau dann werden OKRs zu dem mächtigen Werkzeug, als das sie gedacht sind.

Die Frage ist nicht, ob OKRs funktionieren. Die Frage ist, ob das System bereit ist, sie zu nutzen.