Vad är skillnaden mellan ett key result och en uppgift?

Ett key result mäter en effekt, till exempel minskad svarstid eller färre incidenter. En uppgift är något man gör, som att lansera en funktion eller migrera en databas. Team som mäter uppgifter optimerar för att bli klara, medan team som mäter effekter optimerar för att faktiskt åstadkomma något.

Hur många OKR bör ett tech-team ha per kvartal?

Få. Ett team med tio OKR har i praktiken inga, eftersom allt blir prioriterat och därmed inget. Begränsa er till ett fåtal mål som verkligen betyder något. Det tvingar fram de obekväma prioriteringsbesluten i förväg i stället för mitt i kvartalet.

Ska man straffa team som inte når sina OKR?

Nej. OKR ska vara ambitiösa, vilket betyder att man inte alltid ska nå hundra procent. Straffar man missade mål lär sig teamen snabbt att sätta mål de vet att de klarar, och poängen med ambition går förlorad. Ett team som alltid når alla mål har troligen satt dem för lågt.

OKR-implementering för tech-team: Mätbara mål som faktiskt driver leverans

OKR har blivit nästan obligatoriskt i växande bolag, och därmed också ofta missförstått och illa infört. Jag möter team som hatar sina OKR, inte för att idén är dålig, utan för att de förvandlats till en kvartalsvis pappersövning som ingen tror på. Rätt använda är OKR ett kraftfullt sätt att skapa fokus och autonomi i ett tekniskt team. Fel använda blir de ett mätspel som styr fel beteende. Den här artikeln handlar om hur OKR faktiskt kan fungera för ett tech-team, och om de fällor som gör att de oftast inte gör det.

Vad OKR egentligen är till för

OKR står för objectives and key results: ett kvalitativt mål och ett par mätbara resultat som visar att ni nått dit. Poängen är inte mätningen i sig, utan att skapa fokus och låta teamet själva avgöra hur de når målet. Ett bra objective svarar på vart vi ska och varför det spelar roll; ett bra key result svarar på hur vi vet att vi kommit fram. Den som förstår det undviker den vanligaste fällan, att förväxla OKR med en uppgiftslista.

Den vanligaste fällan: aktiviteter förklädda till mål

Det överlägset vanligaste misstaget i tekniska team är att skriva key results som egentligen är aktiviteter. Att lansera en funktion eller migrera en databas är saker man gör, inte resultat man uppnår. Ett äkta key result mäter en effekt, inte en handling. Skillnaden låter subtil men är avgörande: ett team som mäter aktiviteter optimerar för att bli klara med saker, medan ett team som mäter effekter optimerar för att åstadkomma något. Det förra leder till att man bygger features ingen behöver, det senare till att man löser problem.

Mätbarhet utan att mäta fel sak

Tekniska team brottas särskilt med att vissa viktiga saker är svåra att mäta. Det leder ofta till att man mäter det som är lätt att räkna i stället för det som betyder något, och då börjar OKR styra fel. Om ni belönar antal levererade features får ni fler features av sämre kvalitet. Om ni belönar minskad svarstid eller färre incidenter får ni det i stället. Konsten är att välja mått som faktiskt speglar värde, även när det är obekvämt, och att vara vaksam på när ett mått börjar gamas i stället för uppfyllas.

Att införa OKR på ett sätt som driver rätt beteende är en del av det organisatoriska arbete jag gör inom CTO as a Service.

Ambition utan att straffa misslyckande

OKR ska vara ambitiösa, vilket betyder att man inte alltid ska nå hundra procent. Men det fungerar bara om kulturen tål det. Om team straffas för att inte fullt ut nå sina OKR lär de sig snabbt att sätta mål de vet att de klarar, och hela poängen med ambition går förlorad. Ett team som konsekvent når alla sina mål har förmodligen satt dem för lågt. Den balansen, att sträcka sig men inte straffas, är den svåraste och viktigaste delen av en OKR-kultur.

Färre och tydligare slår fler

Ett team med tio OKR har i praktiken inga, eftersom allt blir prioriterat och därmed inget. Den disciplin som gör OKR användbara är att begränsa sig till ett fåtal mål per kvartal som verkligen betyder något. Det tvingar fram de obekväma prioriteringsbesluten i förväg i stället för i stridens hetta. Ett fokuserat team som gör tre rätt saker slår ett splittrat team som påbörjar tio. Att koppla OKR till en längre teknisk riktning, som jag beskriver i teknisk roadmap för scale-ups, gör dem dessutom mer meningsfulla.

Uppföljning som håller dem levande

OKR som sätts i början av kvartalet och granskas först i slutet är värdelösa. Det som gör dem levande är en lätt återkommande uppföljning, där teamet stämmer av hur det går och justerar fokus medan det fortfarande är möjligt att påverka utfallet. Uppföljningen ska vara ett verktyg för teamet att styra med, inte en rapport uppåt. När den känns som kontroll dör engagemanget; när den känns som hjälp lever målen.

Relaterat

Exempel på hur mål kopplats till leverans finns i kundcase.

Vill du ta det vidare?

Vill ni införa OKR i ert tech-team, eller rädda en uppsättning som blivit en pappersövning, hjälper jag gärna till. Boka ett samtal så går vi igenom hur ni kan göra dem styrande igen.