Episode 28: Hva skaper fart?

Synes du arbeidet går tregt på jobben? Tenker du det kunne gått litt fortere?

Hei, Martin her, og du lytter til Fimbul!

Som konsulent har mange av mine oppdrag vært tett knyttet til det å skape fart og fremdrift. Ofte er inngangen til prosjektene mine knyttet til uttalelser fra kundene som for eksempel: «Vi har ikke god nok fremdrift!» «Vi kommer aldri i gang med de viktige oppgavene!» «Vi blir aldri enige om hvordan vi kommer i gang!» «Vi har så mye teknisk gjeld at vi ikke vet hvor vi skal begynne!» «Vi forstår ikke hva som skal til for å få denne oppgaven gjort!» «Vi får aldri avklart hvem som skal gjøre denne oppgaven!» «Vi vet egentlig ikke hva som er målet med produktet vårt!»

Som du kanskje hører er det en fellesnevner her. Man får ikke gjort det man trenger, fordi man ikke forstår hvordan man skal komme seg dit. Eller enda verre: Man vet ikke en gang hvor man skal. Så hvordan er det hos deg? Har dere god fart og fremdrift der du jobber, eller er det noe av dette som høres kjent ut?

Aller først må vi snakke om hva fart betyr. Hva legger vi i fart og fremdrift? Den enkle forklaringen er at man som selskap evner å gjennomføre de arbeidsoppgavene man trenger og ønsker. Raskt. På riktig måte. Med rett kvalitet. Det kan være et nytt produkt man ønsker å få raskt ut i markedet. Løst på en slik måte at det er lett å videreutvikle og vedlikeholde, med en slik kvalitet at det løser kundenes problemer og gir oss det ønskede resultatet, og som er et utgangspunkt for å jobbe videre med.

Fart er kort fortalt forretningsverdi. Høy fart gir høy verdiskaping. Lav fart gir lav verdiskaping. Forretningsverdi er tid brukt til å lage nye og spennende produkter og tjenester som gir ditt selskap nye inntekter, og som løser problemer for kundene eller dem som bruker det du har laget.

Hva som skaper fart og fremdrift i et selskap avhenger nok litt av hva man driver med og hvilke erfaringer man har. Min erfaring er at man må lykkes med minst fire områder for at man som et selskap skal kunne ha høy fart i arbeidet, og dermed også fleksibilitet nok til å kunne reagere raskt på nye og endrede muligheter i markedet. Å ha fart betyr at man evner å ta nye produkter og tjenester fra idé til ferdig løsning så raskt at du ikke risikerer at andre gjør det før deg. Eller at du gjør det så raskt at du ikke går tom for penger før du får ideen ut i markedet. Med fart følger også fleksibilitet og slack nok til å respondere på nye muligheter. Eller til å ta unna teknisk gjeld fortløpende.

De fire områdene jeg skal snakke om er at man må være riktig organisert, man må ha enkle og smidige arbeidsprosesser, man må ha et riktig nivå av teknisk gjeld og man må i selskapet ha en positiv kultur og holdning. La oss gå igjennom område for område.

Det første området er organisering. Det finnes ikke et entydig svar på hvordan man organiserer et selskap på best mulig måte, men det finnes mange erfaringer om hva som fungerer og hva som ikke gjør det.

Siden Fimbul er en podcast om teknologiledelse, er også rammen for organisering satt til å være hvordan man organiserer et teknologiselskap eller teknologiavdelinger i et selskap. Nå lurer du kanskje på hva jeg legger i begrepet teknologiselskap. Det finnes mange floskler om at «alle selskaper er teknologiselskaper», men for meg er et teknologiselskap et selskap som har teknologi som en kritisk faktor for sin leveranse til kundene. Det kan være et teknologiprodukt i seg selv — tenk for eksempel Amazon AWS —, eller det kan være teknologi som muliggjør andre leveranser — tenk for eksempel Oda.

Du hører gjerne om smidige team, autonome team, DevOps, DevSecOps og andre begreper som skal beskrive hvordan vi ønsker å organisere oss. Min erfaring er at det ikke er så viktig hva du kaller det, eller at du gjør det nøyaktig slik disse begrepene blir beskrevet i faglitteraturen, men at du organiserer deg på en måte som dekker de behovene for fagkompetanse som selskapet og teamet har.

For meg har dette med fart og organisering en tett sammenheng med autonomi. I episode 21 av Fimbul snakker jeg om hvordan du setter sammen et autonomt team, men du skal få en kortversjon også her. I denne sammenhengen snakker vi om et team og vi snakker om et teams autonomi. Et autonomt team består av en rekke mennesker som sammen besitter all kompetanse som teamet trenger for å ta et produkt fra idéstadiet og helt ut i markedet. Enten du trenger utviklere, driftere, designere, selgere, forretningsutviklere eller annen kompetanse, må teamet ha den nødvendige kompetansen internt i teamet. For noen typer kompetanse er det ikke sikkert at kompetansen trenger å være tilgjengelig for teamet 100 % av tiden, den kan være delt mellom flere team. Dersom du for eksempel lager et produkt som krever mye back-end-kompetanse, er det ikke sikkert at du trenger en designer på heltid i teamet. Men den vurderingen skal teamet få lov til å gjøre selv. Autonomien ligger i at teamet skal kunne arbeide med produkter og tilhørende oppgaver uten at de må gi fra seg en oppgave til et annet team og så få oppgaven i retur når det andre teamet er ferdige. Da blir det overleveringer mellom team og overleveringer tar tid. Jeg har selv målt fremdrift på oppgaver i flere team, og oppgaver som skal ut av teamet og så tilbake igjen, brukte etter mine målinger inntil 14 ganger så lang tid på å bli gjennomført, sammenliknet med dem som kunne gjøres ferdig internt i teamet.

Derfor er organisering viktig. Teamene må organiseres på en måte som gir dem slik autonomi. De må kunne håndtere de fleste oppgaver selv, og de må ha frihet innenfor visse rammer til å bestemme hvordan teamet best løser oppgaven de står overfor. Overleveringer mellom team er av og til også nødvendig. Leser du bøker som Team Topologies vil du huske begreper som value teams og enabling teams, og min erfaring er at det gjerne går oppgaver mellom disse, men at teamene har autonomi til å ta ansvar for slike overleveringer direkte mellom teamene. Ikke forsøk å lage noen omfattende og rigid prosess for overlevering. Team Topologies er for øvrig en bok nettopp om fart, og tar et ganske overlappende perspektiv på det jeg snakker om i denne episoden av Fimbul. Det finnes også misforståtte oppfatninger av hva autonomi betyr, men det skal bli en egen episode av Fimbul, så sørg for at du abonnerer på nye episoder!

Hvis jeg skal gi et konkret eksempel på hvordan man organiserer seg i større selskaper, har jeg selv god erfaring med matriser. Jeg har registrert at mange har blandede erfaringer med matriser, men jeg har samtidig sett at det mange beskriver som en matrise heller ikke har vært en godt oppsatt matrise. Min erfaring er at man i Y-aksen av matrisen har fagdimensjonene, slik som salg, produkt, teknologi og så videre. Fagdimensjonene ledes typisk av en C-nivå-leder og nedover i Y-aksen finner man de ansatte. X-dimensjonen i matrisen er teamene. Man setter sammen et produktteam basert på ansatte fra fagdimensjonen og slik finner man teamsammensetningen og matrisen blir tydelig. Synes du det er vanskelig å se for deg hvordan dette ser ut? Fortvil ikke, på fimbul.tech finner du i episodenotatene til episode 28 en illustrasjon som viser deg hva jeg mener.

Så, for å oppsummere området organisering, er det viktig at du finner en organisering som legger til rette for fart, fleksibilitet og autonomi. Ofte kommer ordet «omorganisering» opp, og de fleste jeg har vært borti har negative assosiasjoner knyttet til ordet. Omorganisering! Selvsagt, alle vet hva de har, men ikke hva de får i en omorganiseringsprosess. Det betyr imidlertid ikke at man må la være å anerkjenne omorganisering som en elefant i rommet, dersom det viser seg at man ikke er optimalt organisert. Organisering er et lederansvar og det må forankres hele veien ned i organisasjonen. Hvis organiseringen er utydelig eller feil, så blir det også uklart for folkene i organisasjonen hvor de hører hjemme og hvem det forventes at de jobber sammen med. «Skal jeg jobbe med sjefen min, eller skal jeg jobbe i et team?» Gjør det krystallklart hvordan matrisen er satt opp! Og er dere feil eller dårlig organisert, så MÅ du gjøre noe med det!

Det neste området vi skal snakke om er prosess. Det nytter ikke å være godt organisert dersom måten vi jobber på holder oss tilbake. Vi mennesker er rare. Vi har sterke kontrollbehov, og som en konsekvens av dette ønsker vi rapportering og porteføljestyring og estimater og strategi og business case og business review og OKR og alle mulig andre artefakter som vi håper vil hjelpe oss med å få oversikt og forstå hva som skjer i selskapet. Min erfaring er motsatt: Jo flere artefakter, jo vanskeligere er det å skille verdiskapende arbeid fra unødvendig arbeid.

Selvsagt skal vi ha kontroll, men hva er egentlig kontroll nok? Og hvem er det egentlig som trenger å ha kontroll? Ethvert autonomt team har en arbeidskapasitet som er bestemt ut i fra antall personer på teamet. Er man syv personer på et team har man en arbeidskapasitet på 280 timer i uken. Dette er teamets båndbredde. Enhver oppgave man tillegger et team spiser av teamets båndbredde. Hvordan skal man da skille mellom hva som er viktig å prioritere? Selv har jeg tre kategorier arbeid. Den første er verdiskapende oppgaver. Dette er oppgaver direkte knyttet til videreutvikling av produktet vi lager, og som bidrar til å øke verdiskapingen generert av teamet. Den andre er ikke-verdiskapende men nødvendige oppgaver. Dette er oppgaver som ikke direkte bidrar til videreutvikling og verdiskaping, men som allikevel er nødvendige for produktet. Å lage hjelpesider. Å yte kundesupport. Ta ned teknisk gjeld. Slike ting. Den tredje er ikke-verdiskapende oppgaver som strengt tatt heller ikke er nødvendige. Estimering av arbeidsoppgaver, trenger du egentlig å bruke tid på det? Hvorfor trenger selskapet egentlig porteføljestyring? Forstå meg rett, jeg sier ikke at det er uviktige oppgaver, poenget mitt er at når båndbredden er en begrenset ressurs, er det viktig å ha et bevisst forhold til hva man bruker tid på. Jo mer tid et team får bruke på verdiskapende oppgaver, jo mer får de gjort av det viktigste arbeidet, dessuten blir de også mer fornøyde. Har du noen gang sett en utvikler arbeide med innspill til porteføljestyret?

Videre trenger vi å drille litt ned i hvordan man finner ut hva som er verdiskapende aktiviteter og hva som ikke er det. Hvordan finner du egentlig ut hva du bør bruke tid på, og hva du bør legge til siden? En vesentlig del av et selskaps arbeidsprosess, er strategiarbeidet. Hvordan en strategi utarbeides, hvordan den implementeres hele veien fra daglig leder og ned i det enkelte team, hvor strategien kan gi teamet verdifull hjelp til å prioritere sine oppgaver fra dag til dag. Strategi er som nevnt en del av arbeidsprosessen, og den hjelper hele selskapet med å jobbe med Rett Ting, i anførselstegn. Hvorvidt en strategi ligger innenfor et teams autonomi, finnes det ikke noe entydig svar på. Egne produkter kan ha egne produktteam som har egen produktstrategi, men den skal være en del av selskapets strategi. Andre team har ingen egen strategi, men støtter seg på selskapets strategi. Men det er min erfaring at det IKKE er innenfor teamets autonomi å bestemme sin egen strategi. Strategi er et lederansvar, og det skal være tydelig for alle hvem som utarbeider den, hvordan den implementeres og hvem som skal mene noe om den.

Hvordan teamet jobber er derimot innenfor teamets autonomi å bestemme, men ofte trenger teamet litt hjelp. Jeg kaller det støttehjul. Det finnes massevis av erfaring å hente fra smidige arbeidsprosesser hvor man tar i bruk artefakter kjent fra OKR, fra Scrum eller Extreme Programming og setter dette sammen til en prosess som gir mening for akkurat ditt selskap og ditt team. Og så må alt arbeid visualiseres, slik at man ikke jobber med usynlig arbeid. Usynlig arbeid er arbeid vi gjør, men som ingen har prioritert og som ikke er synlig for andre enn den som jobber med det. «Jeg skal bare hjelpe Ola med noen småting!» Usynlig arbeid spiser av teamets båndbredde, og aksepten for usynlig arbeid øker hvis ikke du visualiserer det. Skaff deg et Kanban-board og sørg for at alle oppgaver har et kort på boardet. Da blir det veldig fort synlig for folk selv at «dette bør jeg egentlig ikke bruke tid på».

Dersom du har mange team i et selskap, eller jobber med vekst og skalering og skal etablere nye team, kan det være en idé å lage en slags «starter-kit» for nye team. Altså lage en mal for hvilke verktøy og metoder de kan jobbe etter. Noen selskaper har også egne Way of Working-team for å hjelpe nye og eksisterende team.

Så må vi snakke om teknisk gjeld. Hvis du lurer på hva teknisk gjeld er, så kan du forenklet sagt se på det som teknisk etterslep som burde vært utbedret i løsningene dine. En bug som burde vært fikset. Noe som er snålt med designet. En applikasjon som har dårlig ytelse. Et API som burde hatt et nytt endepunkt. Et bibliotek som burde vært oppgradert. Et sikkerhetshull som burde vært tettet. Slike ting. Alle har dem, tro ikke noe annet. Og alle SKAL ha dem. Alle skal ha teknisk gjeld. Har du ikke teknisk gjeld, så har du brukt ALT for mye tid på å fikse feil fremfor å jobbe med verdiskapende oppgaver. Kunsten, derimot, ligger i å balansere teknisk gjeld opp mot verdiskapende oppgaver. Noen vil sikkert være uenige med min definisjon når jeg sier at teknisk gjeld er ikke-verdiskapende men nødvendige oppgaver. Men teknisk gjeld må allikevel prioriteres og holdes på et akseptabelt nivå. En god produkteier skal aldri prioritere bare den ene eller den andre siden, men ha et holistisk syn på den totale kvaliteten på produktet. Det finnes nemlig også forretningsgjeld, altså etterslep man burde utbedret av hensyn til kundene.

Dersom man ikke har et bevisst forhold til teknisk gjeld, vil gjelden øke av seg selv. For hver gang man unnlater å oppgradere et operativsystem vil neste versjon alltid være bittelitt vanskeligere å oppgradere til. Gammel kode blir vanskeligere å forvalte når folk slutter og nye folk kommer til. Biblioteker blir utdatert. Det samme blir kompetansen. Den tekniske gjelden vokser og vokser og vokser. Som en gjærbakst.

Det finnes mange måter å måle nivået av teknisk gjeld, men jeg synes ikke man trenger å gjøre det vanskelig. En av de viktigste indikatorene jeg ser etter, er hvor vanskelig en utvikler eller en drifter synes det er å gjennomføre en endring. Hvis en endring er vanskelig og tar lang tid, og dette ikke skyldes at selve oppgaven er omfattende og komplisert, kan det være et tegn på at vi gjør det for sjelden og at vi har for mye teknisk gjeld.

I et prosjekt jeg jobbet tidligere tegnet jeg opp en skala på et A4-ark. I den ene enden tegnet jeg en kopp kaffe. I den andre enden en brennende dass. Hver uke fikk jeg teamet i fellesskap til å plassere en indikator for hva som var deres kollektive oppfattelse av den tekniske tilstanden på produktet de hadde ansvaret for. Da fikk teamet en diskusjon og kunne avstemme individuelle oppfatninger, og potensielt også bestemme tiltak de måtte jobbe med. Tiltakene ble så prioritert inn i backloggen opp mot andre oppgaver. For å sikre fart og fleksibilitet må du altså sørge for at løsningene som utgjør produktet ditt ikke er et hinder i seg selv. Du har full råderett over dem, så sørg for at de legger til rette for fart og ikke er til hinder for det.

Hvordan måler man kultur i et selskap? Vel, det første man kan gjøre er noe så enkelt som ta deg en kopp kaffe og reflektere over hvordan folk snakker om dem som ikke er til stede, når man er i små forsamlinger med et par-tre personer. Snakker man for det vesentligste godt om andre? Eller er det mye negativt? En annen indikator er å kjenne litt på magefølelsen når du sitter i bilen eller på sykkelen eller på kollektivtransporten på vei hjem. Tenker du «herregud, for en elendig dag» eller tenker du «her var det mye snerk, men det er godt vi har bra folk»? Forskjellen er stor. Vi lever godt med å ha mye snerk i løsningene våre, men det forutsetter at vi ikke har en dårlig kultur på toppen. Med en god kultur på toppen blir vi robuste, og vi evner å jobbe med problemer i fellesskap og med god stemning.

I et tidligere prosjekt jeg arbeidet gjorde jeg noen overraskende erfaringer. Tidlig i prosjektet kalte jeg inn folk fra flere forskjellige avdelinger i selskapet. Etter at innkallingen ble sendt, var det en person som trakk meg til side og sa at «Dersom den personen fra den andre avdelingen kommer, så blir ikke jeg med!» Jeg var sjokkert, for jeg erfarte gjennom prosjektet at samarbeidsklimaet var på et bunnivå, hvilket forsinket fremdriften og reduserte kvaliteten på arbeidet. I verste fall blir dårlig klima og kultur handlingslammende for et selskap.

Så hva gjør man når samarbeidsklimaet er så dårlig at det er til hinder for å gjennomføre nødvendig arbeid? Jeg skulle ønske jeg hadde et enkelt svar, men det har jeg dessverre ikke. Man kan ikke instruere mennesker til å like andre, eller til å være faglig enige. Folks forskjellige erfaringer er det som danner deres faglige kompetanse, og når erfaringene og kompetansen er ulik, har man også forskjellige utgangspunkt for å bli enige. Samtidig må du akseptere at folk ER forskjellige, MENER forskjellige ting og HAR forskjellig utgangspunkt. Man SKAL ha rom for forskjellige personligheter, men å være sin egen personlighet er ikke det samme som at man skal jobbe i strid med selskapets strategi. Som arbeidstaker er du ansatt for å utføre det arbeidet som arbeidsgiver betaler deg for. Dette er premisset for ditt arbeidsforhold, og liker du det ikke kan du bytte jobb.

I situasjoner hvor man har en kultur og holdning slik dem jeg eksemplifiserer over, trenger du hjelp og du trenger den fra noen andre enn dem som ikke samarbeider godt. Kanskje har du en HR-avdeling eller et Way-of-Working-team som du kan engasjere. Har du ikke slik kompetanse i eget selskap, kan du få ekstern hjelp. Du trenger en nøytral part som ikke er interessert i noen av partenes standpunkter, men som heller jobber med å få partene til å forstå hverandres motivasjon og faglige utgangspunkt, og hvorfor folk mener som de gjør. Slik kan du bringe folk sammen over en kaffe og i en mer sosial setting hvor inngangen til slike møter er at er nødt til å samarbeide og at alle ønsker å ha et trivelig arbeidsklima. Ingen liker et giftig arbeidsklima. Det er et godt utgangspunkt.

Nå har vi snakket om de fire områdene, og rekkefølgen var egentlig ganske tilfeldig. Hvis du nå tenker at det er rom for forbedring der du jobber, så kan du i samarbeid med teamet eller avdelingen eller ledergruppen forsøke å kvantifisere tilstanden på de forskjellige områdene hos deg. Det kan gjøres gjennom spørreundersøkelser eller intervjuer eller i fellesmøter. Eller rett og slett bare starte med magefølelsen i første omgang. Og resultatet kan du visualisere som et edderkoppdiagram, og så kan du knytte tiltak til det enkelte område om du ønsker det. Og trenger du hjelp, så kan du kontakte meg! Jeg har jobbet med disse problemstillingene mange, mange ganger før. Det er ikke enkelt, for da hadde du selvfølgelig løst dem selv. Jeg synes heller ikke det er enkelt. Men det er ofte nødvendig med nye friske øyne og et eksternt blikk på hva som faktisk er problemene og hva du kan gjøre med dem. Trenger du hjelp så kontakter du meg på e-post til martin@nivlheim.no eller telefon eller SMS til 93055510. Det koster deg absolutt ingenting å slå av en prat over en kopp kaffe! Det hadde vært hyggelig!

Og nå trenger jeg DIN hjelp! Jeg trenger hjelp til å dele erfaringene i Fimbul. Jeg trenger DIN hjelp til å dele Fimbul med minst én venn! Én venn hvor du tenker: «Dette tror jeg du vil ha nytte av!» Be dem om å besøke fimbul.tech.

Tusen takk for at du lytter til Fimbul, og for at du deler! Vi høres!