Articles /

Google’s OKR playbook

Ingen har mere kollektiv erfaring med implementering af OKR’er end Google.

I takt med at virksomheden er vokset (og vokset), har den med jævne mellemrum udsendt OKR-retningslinjer og skabeloner. De følgende uddrag er for det meste hentet fra interne kilder og genoptrykt med Googles tilladelse. (Bemærk: Dette er Googles tilgang til OKR’er. Din tilgang kan – og bør – være anderledes.)

Og hos Google kan vi godt lide at tænke stort. Vi bruger en proces, der kaldes mål og centrale resultater (OKR’er), til at hjælpe os med at kommunikere, måle og nå disse høje mål.

Vores handlinger bestemmer Googles fremtid. Som vi har set gentagne gange – i Search, i Chrome, i Android – kan et team bestående af nogle få procent af virksomhedens arbejdsstyrke, der handler i fællesskab mod et ambitiøst fælles mål, ændre en hel moden industri på mindre end to år. Derfor er det afgørende, at vi som Google-medarbejdere og ledere træffer bevidste, omhyggelige og informerede valg om, hvordan vi fordeler vores tid og energi – som enkeltpersoner og som medlemmer af teams. OKR’er er et udtryk for disse omhyggelige valg og det middel, hvormed vi koordinerer enkeltpersoners handlinger for at nå store kollektive mål.

Vi bruger OKR’er til at planlægge, hvad folk skal producere, følge deres fremskridt i forhold til planen og koordinere prioriteter og milepæle mellem folk og teams. Vi bruger også OKR’er til at hjælpe folk med at holde fokus på de vigtigste mål og hjælpe dem med at undgå at blive distraheret af presserende, men mindre vigtige mål.

OKR’er er store, ikke trinvise – vi forventer ikke at nå dem alle. (Hvis vi gør det, sætter vi dem ikke aggressivt nok.) Vi klassificerer dem med en farveskala for at måle, hvor godt vi klarede os:

0,0-0,3 er rødt0,4-0,6 er gult0,7-1,0 er grønt

Skrivning af effektive OKR’er

Svagt udførte/forvaltede OKR’er er spild af tid, en tom ledelsesgestus. Godt udførte OKR’er er et motiverende ledelsesværktøj, der hjælper med at gøre det klart for teams, hvad der er vigtigt, hvad der skal optimeres, og hvilke afvejninger de skal foretage i deres daglige arbejde.

Det er ikke let at skrive gode OKR’er, men det er heller ikke umuligt. Vær opmærksom på følgende enkle regler:

Objektiver er “hvad”. De:

  • udtrykker mål og hensigter;
  • er aggressive, men alligevel realistiske;
  • skal være håndgribelige, objektive og utvetydige; det skal være indlysende for en rationel observatør, om et mål er nået.
  • Den vellykkede opfyldelse af et mål skal give klar værdi for Google.

Nøgleresultater er “hvordan”. De:

  • udtrykker målbare milepæle, som, hvis de nås, vil fremme målet/målene på en nyttig måde for deres vælgere;
  • skal beskrive resultater, ikke aktiviteter. Hvis dine KR’er indeholder ord som “konsultere”, “hjælpe”, “analysere” eller “deltage”, beskriver de aktiviteter. Beskriv i stedet den endelige virkning af disse aktiviteter: “offentliggøre målinger af gennemsnits- og halelatency fra seks Colossus-celler senest den 7. marts” i stedet for “vurdere Colossus-latency”;
  • skal indeholde dokumentation for færdiggørelse. Disse beviser skal være tilgængelige, troværdige og lette at finde frem til. Eksempler på beviser omfatter ændringslister, links til dokumenter, noter og offentliggjorte metrikrapporter.

OKR’er på tværs af teams

Mange vigtige projekter hos Google kræver bidrag fra forskellige grupper. OKR’er er ideelt egnet til at forpligte sig til denne koordinering. OKR’er på tværs af teams bør omfatte alle de grupper, der skal deltage materielt i OKR’en, og OKR’er, der forpligter sig til hver enkelt gruppes bidrag, bør fremgå eksplicit af hver enkelt gruppes OKR’er. Hvis f.eks. Ads Development og Ads SRE og Network Deployment skal levere for at understøtte en ny annonceringstjeneste, bør alle tre grupper have OKR’er, der beskriver deres forpligtelse til at levere deres del af projektet.

Committed vs. Aspiratoriske OKR’er

OKR’er har to varianter, og det er vigtigt at skelne mellem dem:

Forpligtelser er OKR’er, som vi er enige om vil blive opfyldt, og vi vil være villige til at justere tidsplaner og ressourcer for at sikre, at de bliver leveret.

  • Den forventede score for en forpligtet OKR er 1,0; en score på mindre end 1.0 kræver en forklaring på den manglende score, da det viser fejl i planlægningen og/eller udførelsen.

Men i modsætning hertil udtrykker aspirationelle OKR’er, hvordan vi gerne vil have verden til at se ud, selv om vi ikke har nogen klar idé om, hvordan vi skal nå dertil og/eller de ressourcer, der er nødvendige for at levere OKR’en.

  • Aspirationelle OKR’er har en forventet gennemsnitsscore på 0,7 med stor varians.

Klassiske OKR-skrivefejl og fælder

TRAP #1: Undlader at skelne mellem engagerede og aspirationelle OKR’er.

  • Mærkning af en engageret OKR som aspirationel øger risikoen for fiasko. Teams tager det måske ikke alvorligt og ændrer måske ikke deres andre prioriteter for at fokusere på at levere OKR’en.
  • På den anden side skaber mærkning af en ønsket OKR som forpligtet defensivitet i teams, der ikke kan finde en måde at levere OKR’en på, og det inviterer til omvendt prioritering, da forpligtede OKR’er nedlægges for at fokusere på den ønskelige OKR.

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

  • OKR’er skrives ofte hovedsageligt baseret på, hvad teamet tror, det kan opnå uden at ændre noget af det, de gør i øjeblikket, i modsætning til, hvad teamet eller dets kunder virkelig ønsker.

TRAP #3: Tøvende aspirationelle OKR’er.

  • Aspirationelle OKR’er tager meget ofte udgangspunkt i den nuværende tilstand og spørger effektivt: “Hvad kunne vi gøre, hvis vi havde ekstra personale og var lidt heldige?”. En alternativ og bedre tilgang er at starte med: “Hvordan kunne min (eller mine kunders) verden se ud om flere år, hvis vi blev frigjort fra de fleste begrænsninger?” Du vil pr. definition ikke vide, hvordan du kan opnå denne tilstand, når OKR’en først er formuleret – det er derfor, det er en aspirationel OKR. Men uden at forstå og formulere den ønskede sluttilstand garanterer du, at du ikke vil være i stand til at opnå den.
  • Litmusprøven: Hvis du spørger dine kunder, hvad de virkelig ønsker, opfylder eller overgår dit ambitiøse mål så deres ønske?

TRAP #4: Sandbagging

  • Et teams engagerede OKR’er bør på troværdig vis forbruge de fleste, men ikke alle deres tilgængelige ressourcer. Deres engagerede + ambitiøse OKR’er bør troværdigt forbruge noget mere end deres tilgængelige ressourcer. (Ellers er de reelt set forpligtelser.)
  • Teams, der kan opfylde alle deres OKR’er uden at have brug for hele deres teamets personale/kapital … antages enten at hamstre ressourcer eller ikke at presse deres team, eller begge dele. Dette er et signal til den øverste ledelse om at omfordele personale og andre ressourcer til grupper, der vil gøre mere effektiv brug af dem.

TRAP #5: Mål med lav værdi (også kendt som “Who cares? “OKR).

OKR’er skal love en klar forretningsmæssig værdi – ellers er der ingen grund til at bruge ressourcer på dem. Low Value Objectives (LVO’er) er de mål, som ingen vil lægge mærke til eller bekymre sig om, selv om målet gennemføres med et 1,0.

  • Et klassisk (og forførende) LVO-eksempel: “Forøg opgavens CPU-udnyttelse med 3 procent”. Dette mål i sig selv hjælper ikke brugerne eller Google direkte. Men det (formodentlig beslægtede) mål: “Reducer mængden af kerner, der kræves for at betjene spidsbelastningsforespørgsler, med 3 procent uden ændring af kvalitet/latency/ . . . og returner de overskydende kerner til den frie pulje” har en klar økonomisk værdi. Det er et bedre mål.
  • Her er en lakmusprøve: Kunne OKR få en 1,0 under rimelige omstændigheder uden at give direkte slutbruger eller økonomisk fordel? Hvis ja, så omformulér OKR’en, så den fokuserer på den håndgribelige fordel. Et klassisk eksempel: Et klassisk eksempel: “Lancering af X”, uden kriterier for succes. Bedre: “Fordoble Y i hele flåden ved at lancere X til 90+ procent af borgcellerne.”

TRAP nr. 6: Utilstrækkelige KR’er til forpligtede O’er.

  • OKR’er er opdelt i det ønskede resultat (målet) og de målbare skridt, der kræves for at opnå dette resultat (de vigtigste resultater). Det er afgørende, at KR’erne er skrevet således, at en score på 1,0 for alle nøgleresultater giver en score på 1,0 for målet.
  • En almindelig fejl er at skrive nøgleresultater, der er nødvendige, men ikke tilstrækkelige til at fuldføre målet samlet set.Fejlen er fristende, fordi den gør det muligt for et team at undgå de vanskelige (ressource-/prioritets-/risiko-) forpligtelser, der er nødvendige for at levere “hårde” nøgleresultater.
  • Denne fælde er særlig skadelig, fordi den forsinker både opdagelsen af ressourcebehovet for målet og opdagelsen af, at målet ikke vil blive afsluttet til tiden.
  • Litmusprøven: Er det rimeligt muligt at score 1,0 på alle nøgleresultater, men stadig ikke at nå målets hensigt? Hvis det er tilfældet, skal man tilføje eller omarbejde de centrale resultater, indtil deres vellykkede gennemførelse garanterer, at målet også gennemføres med succes.

Læse, fortolke og handle på OKR’er

For forpligtede OKR’er

  • Teams forventes at omlægge deres andre prioriteter for at sikre en levering af 1,0 til tiden.
  • Teams, der ikke på troværdig vis kan love at levere en 1,0 på en forpligtet OKR, skal straks eskalere sagen. Dette er et vigtigt punkt: Det er ikke kun OK at eskalere i denne (almindelige) situation, det er også et krav. Uanset om problemet er opstået på grund af uenighed om OKR’en, uenighed om dens prioritet eller manglende evne til at afsætte tilstrækkelig tid/personer/ressourcer, er det godt at eskalere. Det giver teamets ledelse mulighed for at udvikle muligheder og løse konflikter.

Den logiske konsekvens er, at ethvert nyt OKR sandsynligvis vil indebære en vis grad af eskalering, da det kræver en ændring af eksisterende prioriteter og forpligtelser. En OKR, der ikke kræver nogen ændringer i nogen gruppes aktiviteter, er en OKR, der ikke kræver nogen ændringer i nogen gruppes aktiviteter, er en business-as-usual OKR, og disse er sandsynligvis ikke nye – selv om de måske ikke tidligere er blevet nedskrevet.

  • En forpligtet OKR, der ikke opnår en 1,0 inden forfaldsdatoen, kræver en postmortem. Dette har ikke til formål at straffe teams. Formålet er at forstå, hvad der skete i forbindelse med planlægningen og/eller udførelsen af OKR’en, så holdene kan forbedre deres evne til pålideligt at opnå 1,0 på forpligtede OKR’er.
  • Eksempler på klasser af forpligtede OKR’er er at sikre, at en tjeneste opfylder sin SLA (service level agreement) for kvartalet; eller at levere en defineret funktion eller forbedring af et infrastruktursystem inden en fastsat dato; eller at fremstille og levere en mængde servere til et omkostningspunkt.

For Aspirational OKR’er

  • Sættet af aspirational OKR’er vil efter hensigten overstige teamets evne til at udføre i et givet kvartal. OKR’ernes prioritet bør informere teammedlemmernes beslutninger om, hvor de skal bruge den resterende tid, de har, efter at gruppens forpligtelser er opfyldt. Generelt bør OKR’er med højere prioritet gennemføres før OKR’er med lavere prioritet.
  • Aspirationelle OKR’er og deres tilhørende prioriteter bør forblive på teamets OKR-liste, indtil de er gennemført, og om nødvendigt overføres de fra kvartal til kvartal. Det er en fejl at fjerne dem fra OKR-listen på grund af manglende fremskridt, da det skjuler vedvarende problemer med prioritering, ressourcetilgængelighed eller manglende forståelse af problemet/løsningen.

Korollarium: Det er godt at flytte en ønsket OKR til et andet teams liste, hvis dette team har både ekspertise og båndbredde til at udføre OKR’en mere effektivt end den nuværende OKR-ejer.

  • Teamledere forventes at vurdere de ressourcer, der er nødvendige for at udføre deres ønsket OKR’er og bede om dem hvert kvartal, hvilket opfylder deres pligt til at udtrykke kendt efterspørgsel over for forretningen. Lederne bør dog ikke forvente at få alle de nødvendige ressourcer, medmindre deres aspirationelle OKR’er er de højest prioriterede mål i virksomheden efter de forpligtede OKR’er.

Mere lakmusprøver

Nogle enkle prøver til at se, om dine OKR’er er gode:

  • Hvis du har skrevet dem ned på fem minutter, er de sandsynligvis ikke gode. Tænk dig om.
  • Hvis dit mål ikke passer på én linje, er det sandsynligvis ikke skarpt nok.
  • Hvis dine KR’er er udtrykt i team-interne termer (“Launch Foo 4.1”), er de sandsynligvis ikke gode. Det, der betyder noget, er ikke lanceringen, men dens virkning. Hvorfor er Foo 4.1 vigtig? Bedre: “Lancér Foo 4.1 for at forbedre antallet af tilmeldinger med 25 procent.” Eller blot: “Forbedre antallet af tilmeldinger med 25 procent.”
  • Brug rigtige datoer. Hvis alle nøgleresultater sker på kvartalets sidste dag, har du sandsynligvis ikke en rigtig plan.
  • Sørg for, at dine nøgleresultater er målbare: Det skal være muligt objektivt at tildele en karakter ved udgangen af kvartalet. “Forbedre antallet af tilmeldinger” er ikke et godt nøgleresultat. Det er bedre: “Forbedre de daglige tilmeldinger med 25 procent inden den 1. maj.”
  • Sørg for, at målingerne er entydige. Hvis du siger “1 million brugere”, er det så alle brugere på alle dage eller aktive på syv dage?
  • Hvis der er vigtige aktiviteter på dit team (eller en betydelig del af dets indsats), som ikke er dækket af OKR’er, så tilføj flere.
  • For større grupper bør du gøre OKR’er hierarkiske – hav nogle på højt niveau for hele teamet og mere detaljerede for underteams. Sørg for, at de “horisontale” OKR’er (projekter, hvor flere teams skal bidrage) har understøttende nøgleresultater i hvert enkelt underteam.

Hvis jeg har spørgsmål, hvor skal jeg så sende dem hen?

Vi vil gerne høre fra dig!

Leave a Reply