Google’s OKR-playbook

Niemand heeft meer collectieve ervaring met het implementeren van OKR’s dan Google.

Terwijl het bedrijf heeft geschaald (en geschaald), heeft het periodiek OKR-richtlijnen en sjablonen uitgebracht. De volgende uittreksels zijn grotendeels afkomstig uit interne bronnen en worden herdrukt met toestemming van Google. (Opmerking: dit is Google’s benadering van OKR’s. Uw aanpak kan en moet verschillen.)

Bij Google denken we graag groot. We gebruiken een proces genaamd doelstellingen en belangrijkste resultaten (OKR’s) om ons te helpen deze verheven doelen te communiceren, meten en bereiken.

Onze acties bepalen de toekomst van Google. Zoals we herhaaldelijk hebben gezien – in Search, in Chrome, in Android – kan een team bestaande uit een paar procent van het personeel van het bedrijf, dat samenwerkt aan een ambitieus gemeenschappelijk doel, in minder dan twee jaar een hele volwassen industrie veranderen. Daarom is het cruciaal dat we als medewerkers en managers van Google bewuste, zorgvuldige en weloverwogen keuzes maken over hoe we onze tijd en energie verdelen – als individu en als lid van een team. OKR’s zijn de manifestatie van die zorgvuldige keuzes, en het middel waarmee we de acties van individuen coördineren om grote collectieve doelen te bereiken.

We gebruiken OKR’s om te plannen wat mensen gaan produceren, hun voortgang bij te houden ten opzichte van het plan, en prioriteiten en mijlpalen te coördineren tussen mensen en teams. We gebruiken OKR’s ook om mensen te helpen zich te concentreren op de belangrijkste doelen, en hen te helpen zich niet te laten afleiden door dringende maar minder belangrijke doelen.

OKR’s zijn groot, niet incrementeel – we verwachten niet dat we ze allemaal halen. (Als we dat wel doen, stellen we ze niet agressief genoeg.) We beoordelen ze met een kleurenschaal om te meten hoe goed we het hebben gedaan:

0.0-0.3 is rood0.4-0.6 is geel0.7-1.0 is groen

Het schrijven van effectieve OKR’s

Slecht uitgevoerde/beheerde OKR’s zijn tijdverspilling, een loos managementgebaar. Goed uitgevoerde OKR’s zijn een motiverend managementinstrument dat teams helpt duidelijk te maken wat belangrijk is, wat ze moeten optimaliseren en welke afwegingen ze moeten maken tijdens hun dagelijkse werk.

Het schrijven van goede OKR’s is niet eenvoudig, maar ook niet onmogelijk. Besteed aandacht aan de volgende eenvoudige regels:

Objectives zijn de “Whats.” Zij:

• drukken doelen en bedoelingen;
• zijn agressief maar realistisch;
• moeten tastbaar, objectief en ondubbelzinnig zijn; moet duidelijk zijn voor een rationele waarnemer of een doelstelling is bereikt.
• De succesvolle verwezenlijking van een doelstelling moet duidelijke waarde voor Google opleveren.

Key Results zijn de “Hows.” Ze:

• uitdrukken meetbare mijlpalen die, indien bereikt, de doelstelling(en) op een nuttige manier voor hun kiezers zullen bevorderen;
• moeten uitkomsten beschrijven, geen activiteiten. Als uw KR’s woorden bevatten als “raadplegen”, “helpen”, “analyseren” of “deelnemen”, beschrijven ze activiteiten. Beschrijf in plaats daarvan de impact van deze activiteiten op het eindgebruik: “publiceer gemiddelde en staart latency metingen van zes Colossus cellen voor 7 maart,” in plaats van “beoordeel Colossus latency”;
• moet bewijs van voltooiing bevatten. Dit bewijs moet beschikbaar, geloofwaardig en gemakkelijk te vinden zijn. Voorbeelden van bewijs zijn wijzigingslijsten, links naar documenten, notities en gepubliceerde meetrapporten.

Teamoverstijgende OKR’s

Veel belangrijke projecten bij Google vereisen bijdragen van verschillende groepen. OKR’s zijn bij uitstek geschikt om zich in te zetten voor deze coördinatie. Teamoverstijgende OKR’s moeten alle groepen omvatten die een wezenlijke bijdrage aan de OKR moeten leveren, en OKR’s die de bijdrage van elke groep vastleggen, moeten expliciet in de OKR’s van elk van die groepen worden vermeld. Bijvoorbeeld, als Ads Development en Ads SRE en Network Deployment moeten leveren om een nieuwe ads service te ondersteunen, dan zouden alle drie de teams OKR’s moeten hebben die hun commitment beschrijven om hun deel van het project te leveren.

Committed vs. Aspirationele OKR’s

OKR’s hebben twee varianten, en het is belangrijk om ze te onderscheiden:

Commitments zijn OKR’s waarvan we het eens zijn dat ze zullen worden gehaald, en we zullen bereid zijn om schema’s en middelen aan te passen om ervoor te zorgen dat ze worden geleverd.

• De verwachte score voor een committed OKR is 1,0; een score van minder dan 1.0 vereist een verklaring voor de misser, aangezien dit wijst op fouten in de planning en/of uitvoering.

Aan de andere kant geven aspirationele OKR’s aan hoe we zouden willen dat de wereld eruitziet, ook al hebben we geen duidelijk idee hoe we daar moeten komen en/of welke middelen nodig zijn om de OKR te leveren.

• Aspirationele OKR’s hebben een verwachte gemiddelde score van 0,7, met een hoge variantie.

Klassieke OKR-schrijffouten en valkuilen

TRAP #1: Geen onderscheid maken tussen gecommitteerde en aspirationele OKR’s.

• Door een gecommitteerde OKR als aspirationeel te bestempelen, neemt de kans op mislukking toe. Teams zullen het misschien niet serieus nemen en hun andere prioriteiten niet aanpassen om zich te concentreren op het leveren van de OKR.
• Aan de andere kant creëert het markeren van een ambitieuze OKR als gecommitteerd defensiviteit bij teams die geen manier kunnen vinden om de OKR te leveren, en het nodigt uit tot prioriteitsinversie aangezien gecommitteerde OKR’s worden gedeconcentreerd om zich te concentreren op de ambitieuze OKR.

TRAP #2: Business-as-usual OKR’s.

• OKR’s worden vaak hoofdzakelijk geschreven op basis van wat het team denkt te kunnen bereiken zonder iets te veranderen aan wat het momenteel doet, in tegenstelling tot wat het team of zijn klanten werkelijk willen.

TRAP #3: Timide aspirationele OKR’s.

• Aspirationele OKR’s gaan heel vaak uit van de huidige situatie en vragen in feite: “Wat zouden we kunnen doen als we extra personeel hadden en een beetje geluk hadden?” Een alternatieve en betere benadering is om te beginnen met: “Hoe zou mijn wereld (of die van mijn klanten) er over een aantal jaren uit kunnen zien als we van de meeste beperkingen bevrijd zouden zijn?” Per definitie zult u niet weten hoe u deze toestand kunt bereiken wanneer de OKR voor het eerst wordt geformuleerd – daarom is het een aspirationele OKR. Maar zonder het begrijpen en articuleren van de gewenste eindtoestand, garandeert u dat u niet in staat gaat zijn om het te bereiken.
• De lakmoesproef: Als u uw klanten vraagt wat ze echt willen, voldoet of overtreft uw aspirationele doelstelling dan hun verzoek?

TRAP #4: Sandbagging

• De gecommitteerde OKR’s van een team zouden op geloofwaardige wijze de meeste, maar niet alle van hun beschikbare middelen moeten verbruiken. Hun gecommitteerde + aspirationele OKR’s moeten geloofwaardig iets meer dan hun beschikbare middelen verbruiken. (Anders zijn ze effectief commits.)
• Teams die aan al hun OKR’s kunnen voldoen zonder al hun headcount/kapitaal nodig te hebben … worden verondersteld ofwel resources op te potten ofwel hun teams niet te pushen, of beide. Dit is een hint voor het senior management om headcount en andere middelen toe te wijzen aan groepen die er effectiever gebruik van zullen maken.

TRAP #5: Low Value Objectives (ook bekend als de “Who cares? “OKR).

OKR’s moeten een duidelijke zakelijke waarde beloven – anders is er geen reden om middelen te besteden om ze te doen. Lage Waarde Doelstellingen (LVO’s) zijn doelstellingen waarvoor, zelfs als de Doelstelling met een 1.0 wordt voltooid, niemand het zal merken of erom geven.

• Een klassiek (en verleidelijk) LVO voorbeeld: “Verhoog taak CPU-gebruik met 3 procent.” Deze doelstelling op zichzelf helpt gebruikers of Google niet direct. Het (vermoedelijk verwante) doel: “Verminder het aantal cores dat nodig is om piekqueries te verwerken met 3 procent zonder verandering in kwaliteit/latency/ . . . en geef de overtollige cores terug aan de vrije pool” heeft echter een duidelijke economische waarde. Dat is een superieure doelstelling.
• Hier is een lakmoesproef: Kan de OKR onder redelijke omstandigheden een 1.0 krijgen zonder direct eindgebruiker of economisch voordeel te bieden? Zo ja, dan herformuleer de OKR om zich te concentreren op het tastbare voordeel. Een klassiek voorbeeld: “Lanceer X,” zonder criteria voor succes. Beter: “Verdubbel vlootbrede Y door X te lanceren op 90+ procent van de borg cellen.”

TRAP #6: Onvoldoende KR’s voor toegezegde O’s.

• OKR’s zijn verdeeld in het gewenste resultaat (de doelstelling) en de meetbare stappen die nodig zijn om dat resultaat te bereiken (de belangrijkste resultaten). Het is van cruciaal belang dat KR’s zodanig worden geschreven dat het scoren van 1,0 op alle belangrijke resultaten een 1,0 score voor de doelstelling genereert.
• Een veel voorkomende fout is het schrijven van belangrijke resultaten die noodzakelijk, maar niet voldoende zijn om de doelstelling collectief te voltooien.Deze fout is verleidelijk omdat het een team in staat stelt om de moeilijke (resource/prioriteit/risico) toezeggingen te vermijden die nodig zijn om “harde” sleutelresultaten te leveren.
• Deze valkuil is bijzonder verderfelijk omdat het zowel de ontdekking van de resourcevereisten voor de doelstelling vertraagt, als de ontdekking dat de doelstelling niet op schema zal worden voltooid.
• De lakmoesproef: Is het redelijkerwijs mogelijk om 1,0 te scoren op alle belangrijke resultaten, maar toch niet de bedoeling van de doelstelling te bereiken? Zo ja, voeg dan de belangrijkste resultaten toe of herwerk ze totdat hun succesvolle voltooiing garandeert dat de doelstelling ook met succes is voltooid.

Lezen, interpreteren, en handelen naar OKR’s

Voor gecommitteerde OKR’s

• Teams worden geacht hun andere prioriteiten te herschikken om een op schema zijnde 1.0 oplevering te verzekeren.
• Teams die niet op geloofwaardige wijze kunnen beloven een 1.0 op een gecommitteerde OKR op te leveren, moeten dit onmiddellijk escaleren. Dit is een belangrijk punt: Escaleren in deze (veel voorkomende) situatie is niet alleen OK, het is vereist. Of het probleem nu is ontstaan door onenigheid over de OKR, onenigheid over de prioriteit ervan, of onvermogen om voldoende tijd/mensen/middelen toe te wijzen, escalatie is goed. Het stelt het teammanagement in staat om opties te ontwikkelen en conflicten op te lossen.

Het gevolg is dat elke nieuwe OKR waarschijnlijk een zekere mate van escalatie met zich meebrengt, omdat het een wijziging van bestaande prioriteiten en verplichtingen vereist. Een OKR die geen veranderingen in de activiteiten van een groep vereist is een business-as-usual OKR, en die zijn waarschijnlijk niet nieuw-ook al zijn zij misschien niet eerder opgeschreven.

• Een toegezegde OKR die er niet in slaagt om een 1.0 te bereiken op zijn vervaldatum vereist een postmortem. Dit is niet bedoeld om teams te straffen. Het is bedoeld om te begrijpen wat er is gebeurd bij de planning en/of uitvoering van de OKR, zodat teams hun vermogen om betrouwbaar een 1,0 te halen op vastgelegde OKR’s kunnen verbeteren.
• Voorbeelden van klassen van gecommitteerde OKR’s zijn het verzekeren dat een dienst aan zijn SLA (service level agreement) voor het kwartaal voldoet; of het leveren van een gedefinieerde functie of verbetering aan een infrastructuursysteem tegen een vastgestelde datum; of het produceren en leveren van een hoeveelheid servers tegen een kostenpunt.

Voor Aspirationele OKR’s

• De reeks aspirationele OKR’s zal door ontwerp het vermogen van het team overschrijden om in een gegeven kwartaal uit te voeren. De prioriteit van de OKR’s zou de teamleden moeten informeren over waar de resterende tijd te besteden die zij hebben nadat de verplichtingen van de groep zijn voldaan. In het algemeen zouden OKR’s met een hogere prioriteit eerder moeten worden voltooid dan OKR’s met een lagere prioriteit.
• Aspirationele OKR’s en hun bijbehorende prioriteiten zouden op de OKR-lijst van een team moeten blijven staan totdat ze zijn voltooid, door ze van kwartaal naar kwartaal over te dragen als dat nodig is. Ze van de OKR-lijst laten vallen wegens gebrek aan vooruitgang is een vergissing, aangezien het aanhoudende problemen van prioriteitsstelling, beschikbaarheid van middelen, of een gebrek aan begrip van het probleem/de oplossing verhult.

Corollary: Het is goed om een aspirationele OKR naar de lijst van een ander team te verplaatsen als dat team zowel de expertise als de bandbreedte heeft om de OKR effectiever te verwezenlijken dan de huidige OKR-eigenaar.

• Teammanagers worden geacht de middelen te beoordelen die nodig zijn om hun aspirationele OKR’s te verwezenlijken en er elk kwartaal om te vragen, waarmee ze voldoen aan hun plicht om de bekende vraag aan de business kenbaar te maken. Managers mogen echter niet verwachten dat ze alle vereiste middelen krijgen, tenzij hun aspirationele OKR’s na de gecommitteerde OKR’s de doelstellingen met de hoogste prioriteit in het bedrijf zijn.

Meer lakmoesproeven

Een paar eenvoudige tests om te zien of uw OKR’s goed zijn:

• Als u ze in vijf minuten hebt opgeschreven, zijn ze waarschijnlijk niet goed. Denk na.
• Als uw doelstelling niet op één regel past, is deze waarschijnlijk niet scherp genoeg.
• Als uw KR’s worden uitgedrukt in team-interne termen (“Lanceer Foo 4.1”), zijn ze waarschijnlijk niet goed. Wat telt is niet de lancering, maar de impact ervan. Waarom is Foo 4.1 belangrijk? Beter: “Lanceer Foo 4.1 om de aanmeldingen met 25 procent te verbeteren.” Of gewoon: “Verbeter de aanmeldingen met 25 procent.”
• Gebruik echte data. Als elk belangrijk resultaat op de laatste dag van het kwartaal plaatsvindt, hebt u waarschijnlijk geen echt plan.
• Zorg ervoor dat uw belangrijkste resultaten meetbaar zijn: Het moet mogelijk zijn om objectief een cijfer toe te kennen aan het einde van het kwartaal. “Aanmeldingen verbeteren” is geen goed sleutelresultaat. Beter: “Verbeter dagelijkse sign-ups met 25 procent tegen 1 mei.”
• Zorg ervoor dat de metrieken ondubbelzinnig zijn. Als je zegt “1 miljoen gebruikers,” is dat dan all-time gebruikers of zeven-daagse actieven?
• Als er belangrijke activiteiten in je team zijn (of een aanzienlijk deel van de inspanning) die niet door OKR’s worden gedekt, voeg er dan meer toe.
• Voor grotere groepen, maak OKR’s hiërarchisch – heb er op hoog niveau voor het hele team, meer gedetailleerde voor subteams. Zorg ervoor dat de “horizontale” OKR’s (projecten waaraan meerdere teams moeten bijdragen) ondersteunende belangrijke resultaten in elk subteam hebben.

Als ik vragen heb, waar moet ik ze dan heensturen?

We horen graag van u!