Målkanvas: Et forsøk på å gjøre mål til noe som faktisk hjelper oss — og ikke bare kommer i veien
Har du og teamet ditt forsøkt å sette dere noen mål i det siste? Jobber du med utviklingen av digitale produkter og tjenester er sannsynligheten skyhøy for at svaret er “ja” — for alle er enige om at det er viktig å jobbe målstyrt. Men hvordan får vi det til på en bra måte, og ikke bare som en tvangstrøye alt arbeidet vårt må formuleres inn i?

Del 1: Hvorfor er det så vanskelig å snakke om mål?
For det er det. Har organisasjonen din begynt med OKR ennå? Har den holdt på med det en stund? Sannsynligvis er svaret ja, for OKR er blitt — og jeg vil si heldigvis — et rimelig fast inventar i de aller fleste store digitalmiljøer i løpet av de siste 5 årene. Men om jeg spør deg: «hvor godt synes du det sitter, og hvor lett opplever du at det er å få det til å fungere som et faktisk målstyrende og samkjørende verktøy?» Da er kanskje ikke svaret et like enkelt levert «jo, det går greit».
Mål er vanskelig, og bruken av OKR som en slags allmennmedisin for å bli mer måldrevet gjør det ikke nødvendigvis lettere.
Utfordringer mange organisasjoner kjenner på, er fort disse:
Hva er forskjellen på målene våre og det som er viktig å gjøre nå?
Særlig innføring av OKR, med fokus på effekt, gjør at mye av et teams arbeid er vanskelig å plassere i målstyringsverktøyet. Å ta tak i teknisk gjeld, som å skru av en gammel løsning, eller skrive om til nyere språk, lar seg ikke umiddelbart effektmåle — det er mer binære mål, men kan likefullt representere viktige forutsetninger for organisasjonens verdiskapning. Så er det mål, eller er det bare…arbeid? Organisasjoner savner fort et språk og modeller for å håndtere disse spørsmålene.
Abstraksjonsdistansen til selskapets mål blir fort veldig stor
Jeg tror alle team kan kjenne seg igjen i utfordringen som oppstår når de skal sette seg mål som «støtter oppunder virksomhetsmålene» i organisasjoner som er så store at ett lite team med ansvar for en digital løsning veldig fort opplever at de jobber med ting uten noen direkte lenker til de målene konserndirektøren kan si er viktige akkurat nå. Som Ida Aalen sier (fritt fra hukommelsen): «Vegvesenet vil skape tryggere veier — men det er ikke på nettsiden du kjører bil». Det kan ofte være veldig vanskelig for et team å kontekstualisere eget bidrag opp mot selskapets hovedmål, fordi avstanden til det som er grunnen til en organisasjons eksistens til hva et team har ansvar for blir for stor.
«Mener du OKR-mål, da?»
Adopsjonen av OKR i de mange organisasjoner har ført til et slags likhetstegn mellom «mål» og «OKR». Men det stemmer jo ikke. Vi vet jo at det eksisterer andre former for «mål» også — som vi snakker om, i ulike vendinger. Som selskapets visjon. Resultatmål. Krav vi skal etterfølge, som 99,5% oppetid. I mange digitalmiljøer og organisasjoner er det lett å være enige om viktigheten av å drive målstyrt utvikling (for alle er enige om at å bare drive med tilfeldig arbeid er bortkastet tid) — men det er dessverre også altfor lett å være diffus om hva vi mener når vi sier «mål». Vi vil ikke være planstyrte (for så gammeldagse er vi ikke, eller hva?) — men å få til en del av oppgavene vi hadde tenkt var viktige å få gjort, er jo også mål. Og mener du egentlig målet for teamet denne uken — ambisjonene teamet har satt seg i sine Monday commits, eller mener du den kongstanken digitaldirektøren har meldt om å bli «best i Norge på bruk av KI?» Mål er vanskelig å snakke om, fordi vi er utydelige på hva vi mener når vi sier «mål». Dette er kjernen i det som er vanskelig med “tight — loose — tight”-styring: å treffe på den første “tight’en” krever et bevisst forhold til nettopp hva slags type mål som gir mening å formidle nå — og å kunne formidle det slik at det gir mening.
…og det blir fort rapportering, eller?
Det er dessverre ofte sånn at om du alltid har spist med gaffel, og får utdelt et par spisepinner, så er det letteste for deg å spidde maten med pinnene heller enn å bruke dem slik de er ment. Mye målstyringsarbeid ender opp med å bli den nye drakta på rapporteringsregimet vi alle vil bort fra i jakten på autonome team som jobber tverrfaglig med produkter. Mange produktledere, og mellomledere, og ledere av mellomledere er vant til å utøve ledelsen sin gjennom å gi en konkret oppgave, og gjøre oppfølging av hvordan det går med den oppgaven — som gjør at de som har slike ledere er vant til å få en oppgave, og så fortelle om hvordan det går med den oppgaven på jevnlig basis. Aka rapportering. Aka… “loose — tight — loose”. Utydelig formulering av hvorfor noe bør gjøres, altfor tydelig beskrivelse av hva som skal gjøres, og dårlig oppfølging av hva resulatet av arbeidet ble, annet enn at det er “ferdig”. Selv om effektmål som OKR er tenkt å bidra til et teams indre motivasjon ved at de setter egne ambisjoner om hva de vil oppnå og hvordan, ender mange målstyringsprosesser med å bare være glorifiserte rapporteringsregimer. «Innen fredag neste uke skal alle ha lagt inn sine mål i dette verktøyet vi har valgt for alle. Husk å oppdatere målene hver uke — vi bruker dem til å følge med på progresjon». Noen som kjenner seg igjen? I stedet for at det å følge med på effektmålene for å vurdere om teamet vårt gjorde riktige valg i går, og hva som er riktig valg for hva vi skal gjøre i morgen, blir det å følge med på effektmålene viktig aller mest for å kunne oppdatere målstyringsverktøyet slik du har fått beskjed om.
Mål er mer enn OKR’er
Med andre ord: OKR gir oss ikke alt vi trenger av målformuleringer. Mål er mer enn det. Vi har flere ulike type mål, som er relevante for ulike kontekster. Å feste seg ved kun én målform som skal gjelde alle områder, på alle nivåer, er ikke nyttig som målstyringsverktøy, og er ofte et dårlig utgangspunkt for ordentlig god “tight — loose — tight”-styring. Hensikten til et team — grunnen til at det i det hele tatt eksisterer — er også en form for mål, og kanskje vel så vesentlig for et team å ha stålkontroll på. Uten å vite hva teamet vårt egentlig er, blir det vanskelig å sette seg gode mål for effekter vi har lyst til å oppnå.
En god inngang til målsetting er å snakke om hvilke(t) problem vi skal løse i teamet, for å bidra til resten av organisasjonens virksomhet. Når vi har det klart for oss, er vi allerede godt på vei mot å ha et verktøy vi kan styre etter — uavhengig hvilket rammeverk som akkurat nå er det mest populære.
Når mål funker, vet folk det. Et mål er svaret på spørsmålet «hvorfor gjør vi dette, akkurat nå?» — og når et mål er godt satt og fungerer som styringsverktøy, sitter det svaret helt foran i pannebrasken til alle i teamet — og også folk rundt teamet. Som en kollega sa her før jul, da vi diskuterte dette med mål i faggruppen for produktledelse i Bekk: «…det oser fra produkteieren vår, den der fordi’en…!». Det oser. Når mål fungerer, er de godt formulert og formidlet: de er lette å forstå, lette å huske. Og lette å melde til andre.
Så hva kjennetegner gode mål?
Dette er kravene vi må sette til mål, om de skal fungere som styringsverktøy:
- De må brukes aktivt — de må være en del av den daglige diskusjonen om hva vi skal jobbe med i teamet akkurat nå
- De må være opphavet til oppgavene vi gjør — når team begynner å fylle opp boardet sitt med oppgaver som ikke kan knyttes opp mot et mål, må vi ta en fot i bakken på hvorfor det er blitt sånn
- De må settes i relasjon til den kompetansen og forutsetningene teamet eksisterer under — mål som settes uten tanke om teknisk gjeld, avhengigheter eller faktiske ressurser tilgjengelige for teamet, blir bare tomme ord og demotiverende
- Vi kan ikke hoppe fra mål til mål hele tiden — mål er ikke oppgaver. Oppgaver skal kunne settes i gang og avsluttes i raskt tempo — men mål er langsiktige, og er de virkelige mål, tar de gjerne litt tid å oppnå. Å hele tiden bytte fokus, ved å stadig vekk bli bedt om å sette seg nye mål (f.eks gjennom kvartalsrytmer), gjør det vanskelig for produktteam å få til ekte verdiskapende resultater
- Team må kunne carve ut sin plass i måloppnåelsen: ta utgangspunkt i nøkkelkompetansen og ansvarsområdet i teamet, se til andre team og hvordan de passer inn, og hvilke forutsetninger vi har i teamet for hva vi kan påvirke og gjøre noe med
Hvordan kommer vi oss gjennom, og bort fra, disse utfordringene?
Vi må treffe på riktig type mål, for eksempel:
- Teamets hensikt
- OKR der du vil ha endring (et effektmål det gir mening å følge med på fra dag til dag)
- KPI’er (key performance indicators) der du vil opprettholde det du driver med (det som er viktig for oss å ha på stell — altså kvantifiserte suksesskriterier og nøkkeltall)
Vi må snakke om mål på riktig nivå og for riktig tidsrom:
- Virksomhet «NAV arbeid: Vi skal få flere ut i arbeid»
- Produktområde «PO Arbeidsgiver: vi må øke inkluderingen»
- Team «Vi støtter arbeidsgivere med å få til det praktiske rundt inkludering, vi ser det er det de sliter mest med akkurat nå»
Med dette som underlag, har vi forsøkt å lage et målkanvas for å hjelpe team å bedre sette gode målbilder.
Det finnes canvaser for teamdynamikk, for verdiforslag — men målkanvaser, som handler kun om det, og som tar høyde for nettopp at mål kommer i ulike typer, nivåer og tidsrom — det ser vi at vi savner. På en fagdag før jul satte vi oss derfor ned, en liten gjeng med folk over gjennomsnittet opptatt av produktutviklingsprosess, produktledelse og målstyring, og prøvde å lage et verktøy som fungerer bedre enn de rammeverkene vi til nå har sett i bruk.

Under forklarer vi hvordan vi har tenkt at det skal brukes og fylles ut!
Del 2: Målkanvas
Som en hjelp til å rydde opp i de ulike målformene som vil svirre rundt et team, har vi satt opp et kanvas for å både strukturere opp mål og forutsetninger, og for å fasilitere gode diskusjoner i et team rundt mål.
Kanvaset består av 7 deler, og vi har nummerert dem i rekkefølgen vi tror det er best å kjøre diskusjonene i:

1. Teamets hensikt
Her skriver man en kort setning om teamets “reason to be” — hvorfor eksisterer teamet? Hva er det som gjør at noen har budsjettert for teamet? Dette skulle man tro var ganske enkelt — alle vet vel hvilket team de er i? Og det gjør folk, men å presist kunne svare på hvorfor teamet eksisterer — hva det er ment å oppnå — det er ikke alltid like klart for alle i teamet.
2. Teamets ansvarsområder
Her skal man liste ut hva som faller på teamet å ta tak i. Denne listen peker på de forutsetningene teamet har for å oppnå ambisjoner og effekter. Mange team har ansvar og forpliktelser knyttet til eksisterende løsninger, som helt naturlig til en hver tid vil spise av teamets kapasitet. Dette ansvaret er oppgaver teamet ikke kan gå fra, uansett hvilke mål som blir prioritert for neste periode.
3. Teamkart
Her tegner man opp hva andre team rundt en har ansvar for. Hensikten med denne er å kunne sette mål som er riktige for teamets egen kontekst, og unngå å sette mål som mer naturlig faller til andre team. Øvelsen handler om å kartlegge hvilke team som faktisk er i nærheten, eksempelvis i samme produktområde, eller som en del av samme verdikjede, slik at teamet deres får tydeliggjort hva som er innenfor sitt eget scope og ansvarsområde, og vi unngår overlapp og duplisering av arbeid. Det kan også være med på å få frem om det er team som eventuelt mangler — enten synliggjort ved at noen team har ansvar for for mange ting, eller at det er ting som ingen av teamene har tydelig ansvar for.
4. Virksomhetens mål
Denne er delt inn i 3 deler:
- Virksomhetens hensikt — hva grunnen til at virksomheten er til
- Virksomhetens viktigste fokus fremover — hva prøver vi å oppnå nå?
- Målene til den divisjonen teamet tilhører (vi har kalt det forretningsområde her, men dette kan gjerne være “produktområde” eller “avdeling” dersom det er mer relevant for ditt team)
Dersom det er vanskelig for oss å fylle ut de tre øverste, er det et fint tegn på at vi er nødt til å gjøre oss bedre kjent med hva virksomheten har som kjerne, og hvilke mål som er satt over oss. Det er disse målene vi skal understøtte, og det får vi ikke til om vi ikke kjenner til dem.
Til hver del skal derfor teamet i tillegg ta stilling til to ting:
Hvor trygge kjenner vi oss på at disse formuleringene er sånn noenlunde riktige? Dette handler om kjennskap til de overordnede målene teamet er ment å understøtte. Dersom et team ikke forstår eller kjenner til hva virksomheten eller forretningsområdet/produktområdet de hører til fokuserer på eller prøver å oppnå, vil det ikke være mulig for dem å sette gode mål for eget arbeid — mål som er på linje med det resten av organisasjonen jobber mot.
Og så en dypere samtale: I hvilken grad blir vi motivert av disse målene og fokusområdene? Det er ikke det endelige svaret som er viktig her — men diskusjonen teamet har frem mot det svaret. Dersom vi opplever lav motivasjon rundt virksomhetens mål, hva kommer det av? Og enda viktigere: hva kan vi gjøre med det, for å øke motivasjonen vår? Handler det om at vi ikke forstår grunnen til målene? Eller er det at vi ikke tror vi vil greie å nå målene? I så fall: hva gjør at vi tviler? Hva kan vi gjøre for å styrke troen vår på å lykkes — hva må til? Sitter vi på informasjon om forutsetninger vi ser som vil hindre oss? Dette er nyttig å få verbalisert. Ikke bare for teamet — det kan også være utrolig nyttig som feedback-loop oppover i organisasjonen.
5. Kongstanken vår
Denne er vanskelig. Dersom teamets arbeid ikke har sprunget ut av et konseptløp eller lignende prosess nylig, eller savner en produktleder med tydelig visjon for arbeidet, vil det i de aller fleste tilfeller være vanskelig å formulere en konsis og tydelig kongstanke for teamets arbeid.
Noen hint som peker dere i retningen av en kongstankeformulering når dere tar tak i denne boksen:
- Det ligger noe i nærheten av det dere har formulert som “teamets hensikt”. Grunnen til at dere eksisterer som team bør være en spire til hva dere også bør ha som kongstanke
- Kongstanker og visjoner springer ofte ut i fra dype og ektefølte ønsker om å løse et viktig og verdifullt problem. Hvis du vet, på et dypt plan, hva du kunne ønske var bedre enn det er, eller annerledes, i den konteksten teamet ditt er ment å operere, er du i nærheten av å kunne si noe om hva kongstanken for teamet er
Det sagt — denne er kanskje ikke så kritisk å ha fylt ut. Om dere ikke har det, så har dere det ikke. Det er en workshop i seg selv å lage en kongstanke fra skratch. Så kommer den ikke naturlig, ikke press den igjennom og brenn opp all tiden deres på denne, men ta det med videre som et refleksjonspunkt at det mangler for teamet.
Kongstanken er en overordnet visjon — en som gjerne skal vare lenge og være gyldig for en lang periode. Men for å få fokus, trenger teamet også mer kortsiktige mål. Disse fyller vi ut i de to siste boksene — og tidsbegrenser dem til en gitt periode.
6. Kvalitative mål
Det er mye et team kan ønske å få til, som det ikke gir mening å kvantifisere. Som å få på plass støtte for en ny målgruppe, muliggjøre en helt ny arbeidsflyt, eller lignende. At det ikke kan kvantifiseres betyr ikke at det ikke bør målsettes. Å sette seg en ambisjon for hva vi kan få til innen en gitt tid er både fokuserende og motiverende.
Tidsperioden for disse målene bør være slik at de kan gi teamet en følelse av progresjon. Teamet bør kunne “huske” perioden og målene for gjennom hele perioden, og få til en internalisert opplevelse av om de kommer til å greie å nå målet i løpet av perioden. Om det betyr at det er en periode på to uker, tre måneder eller et halvt år, blir opp til dere og målene deres — bare husk at det å få fokus, slik at dere får flyt og fart, er det som er målet. Det er ikke noe poeng å sette opp et helt år, og så liste ut alt dere tenker dere skal få gjort i løpet av hele året. Det er bare en arbeidsplan — ikke en målsetning.
Det kan ofte være vanskelig å skille mellom det som er oppgaver og tiltak vi gjør for å nå målene, og mål i seg selv. Det er ofte sånn at det bare er et tynt lag semantikk som gjør forskjellen — men det gjør en forskjell. Å “bli ferdig med skjema A” er en oppgave på den måten at vi fort går inn i en modus av å holde oversikt over “to-do”-listen vår når vi snakker om den. Som formulering gir den oss ikke så mye mer dialog i teamet og med stakeholdere om hva som må til, eller hvorfor det er viktig. Formuleringen tar oss ganske fort i retning av “hvordan ligger du an” — altså rapportering på ferdigstillingsgrad. At “målgruppe A skal kunne fullføre job to be done X” derimot, åpner opp for at teamet tenker på hva som _egentlig_ skal til for å kunne si at vi har nådd det som mål, støtter utforsking av mulige mvp’er, og åpner opp for spørsmål om hvorfor akkurat målgruppe A, og akkurat job to be done X er prioritert nå, og ikke målgruppe B og jtbd Y. Å få laget skjema A kan godt være det som må gjøres innenfor rammen av begge formuleringene — men den siste er en bedre målformulering, der den første peker mer på en oppgave.
7. Kvantifiserbare mål
Kvantifiserbare mål kan både peke på effekter (endringer oppover eller nedover man ønsker å følge jevnt over tid), eller kpi’er (opprettholdelse av suksessfaktorer; “dersom vi ser disse tallene, gjør vi det bra). Dersom teamet har falt veldig fra et tidligere definert kpi-nivå, kan det være lurt å sette et effektmål for å komme opp på ønsket kpi igjen.
De kvantifiserbare målene kan være knyttet til de kvalitative — dette gir svært tydelig fokus — men de må ikke det. Vi kan både ha som mål å få på plass støtte for målgruppe A kvalitativt OG øke salget av tjeneste Y i samme periode — men vi må være klar over hvilket kapasitetpådrag samspillet av disse målene gir. Kvantifiserer vi mål ut i fra de kvalitative, spisser vi større grad teamets fokus for perioden, enn om vi legger til nye kvantitative mål til de kvalitative. Denne diskusjonen er selvsagt en viktig del av øvelsen med å fylle ut kanvaset — hva er det egentlig vi tror vi får til i løpet av perioden vi har satt oss — dersom vi strekker oss litt?
Puh! Det var det. Gjennomgangen av kanvaset. Er du klar for å prøve det ut?
Del 3: Prøv det — og prøv igjen
Dette er en oppfordring med dobbel bunn
Den første betydningen handler om at det å sette mål er en modningsprosess og noe man må øve seg på — både som leder og som team. Å treffe på formuleringer som gir mening for oss, for andre, og som motiverer — det krever øvelse. Å treffe på ambisjonsnivå — et som motiverer oss til å strekke oss lenger, og som ikke knekker oss fordi vi på ingen måte kan få det til — det krever også øving; det krever en form for selvinnsikt i oss selv som team, og en tro på oss selv som bygges opp gjennom felles mestring. Bruken av dette kanvaset må derfor sees på som en repeterende øvelse — noe vi gjør jevnlig, gjerne hver gang perioden vi har satt for de kvantitative og kvalitative målene er over, og vi skal gjøre opp en slags status for oss selv på hvordan vi har gjort det. Teoretisk sett skal teamets hensikt og kongstanke bli stående, selv om vi lager nye kvalitative og kvantitative mål.
Men sannsynligvis — og forhåpentligvis — har øvelsen med å formulere mål og prøve å nå dem i perioden som har gått, lært oss littegrann mer om hva det er vi egentlig skal og bør drive med som team, og hvordan vi enda bedre kan snakke om det. Forhåpentligvis er vi blitt enda litt mer bevisst hva kjernen i det vi gjør egentlig handler om, og har en bedre måte å si det på nå enn det vi hadde. Da er det veldig lov å endre det i kanvaset! Det er det gode team jo tross alt gjør: de itererer ikke bare på produktet de lager, men også på sin egen prosess og forsøker hele tiden å jobbe enda litt bedre.
Den andre betydningen og siste bunn i det å prøve og prøve igjen, er at dette kanvaset på alle måter i seg selv er et stykke “work in progress”. Det er ikke ferdig: det vi ønsker oss er at folk tester det ut, og jobber videre med det. Å sette gode mål er en modningsprosess. Du kan ikke regne med å bare kunne ta en «måloppskrift», følge den til punkt og prikke og ende opp med gode mål.
Last ned kanvaset, få plottet det ut i stort format, ta det med i teamet ditt og teste det! Og meld veldig gjerne tilbake med erfaringer og kommentarer på hva som funker bra og hva som ikke funker. Digitalisering er ikke lett — og det krever innsatsen til en hel landsby å få til. Vi må øve, prøve, vurdere hva som funker og ikke, og prøve igjen. Det er den eneste måten å bli skikkelig gode på noe på. Særlig noe så vanskelig som målstyring.
Del kunnskapen
Har du en kollega som også hadde dratt nytte av denne artikkelen?
Skrevet av
Relevant innhold
Her finner du innhold i samme gata om du vil lære mer.
Mer fra Fag i Bekk
Nå er du ved veis ende. Gå til forsiden hvis du vil ha mer faglig påfyll.
Til forsiden