Når man jobber målstyrt etter ambisjoner med måltall, slik som i OKR, kvantifiserer vi det vi ønsker å oppnå. Måltall, eller “Key results”, sier noe om vi kommer oss nærmere ambisjonen vår eller ikke. Problemet oppstår når man tenker at OKR er en prosess som omfatter alt et produktteam gjør og begynner å kvantifisere aktiviteter og oppgaver, heller enn effekten du ønsker å oppnå av aktivitetene og oppgavene.

I sin enkleste form:

• Bruk OKR når du vil løfte noe som kan kvantifiseres
• Ikke bruk OKR på aktiviteter du allerede vet du skal gjøre

La oss se nærmere på hvorfor.

Key Results bør være “stretch goals”

Det å kvantifisere mål er et ekstremt kraftfullt verktøy for å få mest mulig effekt ut av et produktteam der løsningen ikke er kjent på forhånd. Det er derfor Christina Wodtke i boken “Radical Focus” sier at måltallene dine bør være “stretch goals”. Men for å vite hvor du kan strekke deg, må du også vite hva utgangspunktet er. Du må ha en “baseline” før du kan si noe om hvor langt du ønsker å strekke deg. Målene bør settes slik at du har en fair, men ikke for høy sjans for å nå dem. Det er da du får mest mulig effekt ut av arbeidet til teamet.

Setter du ambisjonsnivået for lavt, gir vi oss før vi når potensialet. Setter vi det for høyt, blir det urealistisk og demotiverende. Det beste ligger et sted i mellom, fordi det er umulig å på forhånd si nøyaktig noe om effekten et team klarer å oppnå.

Hvor går det galt?

Feilen, som jeg selv har gjort, kommer når du bruker OKR på ting du allerede vet du må gjøre. Det kan være å flytte applikasjoner til skyen, eller skrive om noe legacy. Du får ikke noe mer effekt ut av teamet ditt, eller kommer raskere til mål ved å komplisere disse aktivitetene med OKR. Effekten blir nærmest motsatt da team kan føle at de ikke får til å jobbe med OKR, eller at det føles som et demotiverende lag med prosess i stedet for å være gøy og motiverende.

Eksempel på OKR som kvantifiserer aktiviteter og i praksis bare er en komplisert oppgaveliste:

O: Flytte tjenester fra on-prem til sky
KR: 3 tjenester er flyttet

Hva bør jeg gjøre i stedet?

Alle team har oppgaver og aktiviteter de må og bør gjøre. Ha de som oppgaver og prioriter de inn i det daglige arbeidet. Bruk OKR til å sette fokus på hvilke områder du ønsker å løfte fra en “baseline”. Hva er en “baseline”? For å vite noe om hvor vi skal må du da også allerede måle nåsituasjonen. Et produktteam bør ha kontroll på sine kjernemetrikker, eller KPIer om du vil, som sier noe om hvordan du gjør det på de viktigste tingene for ditt produkt.

Eksempel: Et kundeservice-team har svartid på sine kunder på snitt 1 minutt. Dette er en kjernemetrikk/KPI for produktet kundeservice. Ønsker du at fokuset for kundeservice-teamet skal være å forbedre svartiden til kundene den neste perioden? Da kan du lage en OKR!

O: Reduser svartiden til kundeservice for våre kunder
KR: Fra 1 min til 30 sekunder

Det er ikke sikkert at kundeservice-teamet finner tiltak som reduserer tiden med hele 30 sekunder, men det er heller ikke poenget. Poenget er at teamet jobber fokusert og målrettet for å finne tiltak som reduserer svartiden i hele tidsperioden hvor det er satt som et mål. Effekten av tiltakene er dermed det viktigste, og ikke tiltakene som aktiviteter i seg selv.

Du kan fint ha KPIer som er viktige, men ikke alltid har OKRer knyttet til seg. Det er faktisk lurt å være selektiv på hva du ønsker å løfte, og hva som er greit som det er akkurat nå. Det skaper fokus.

Husk: Hvis alt er viktig, er ingenting viktig!