Episode 29: Grenser for autonomi

Åkei, du har etablert noen autonome, kryssfunksjonelle og smidige team. Går alt som du håpet, eller oppleves det mer som hjemme-alene-fest?

Hei, Martin her, og du lytter til Fimbul — en podcast om teknologiledelse!

I episode 21 av Fimbul snakker jeg om hvordan du etablerer et autonomt team, hva som er fordelene og hvordan du får teamet i gang. Og kanskje har du gjort akkurat det. Du har etablert ett eller flere autonome team. De har den kompetansen som trengs i teamet. De arbeider smidig og leverer raskt og effektivt forretningsverdi. Allikevel er det noe som skurrer. Flere feil i produksjon. Dårlig samarbeid på tvers av teamene. Dårlig koordinering av utviklingsaktiviteter sett opp mot bedriftens mål. Økt kompleksitet i infrastrukturen og arkitekturen som følger av nye teknologier som teamene har tatt i bruk. Flere leverandører å følge opp som følger av nye tjenester som teamene har tatt i bruk. Fragmenterte tjenester som utvikles suboptimalt i det enkelte team. Misnøye i teamene som følger av «overstyring fra ledelsen». Listen er lang og den inneholder ekte eksempler jeg har sett hos flere av mine kunder. Derfor må vi snakke litt om hva som er autonomiens grenser. Hva skal teamene få lov til å mene noe om selv, og hva skal de ikke få lov til å mene noe om?

Før vi går videre må vi starte med å forstå hva ordet autonomi betyr og hva vi legger i begrepet i konteksten av å drive digital produktutvikling. Ordet autonomi kommer fra gresk: auto, som betyr selv, og nomos, som betyr lov. Enkelt oversatt betyr det selvstyre. Tatt inn i vår verden, der vi utvikler digitale produkter, og snakker om autonome team, snakker vi om små enheter med mennesker, typisk fem til syv personer, som besitter all kompetanse for å levere sine produkter fra idé til ferdig produkt i markedet, innenfor sitt domene. Med sitt domene mener jeg at det i en bedrift ofte er flere autonome team, og de har hvert sitt forretningsområde, altså domene, for hva de skal arbeide med. I en slik sammenheng betyr autonomi at teamene har selvråderett over så mange beslutninger som mulig — men ikke over alle. Det er det viktig å være innforstått med! Fordelen med selvråderett er mange. Man tar beslutninger som angår teamets domene internt i teamet, som gir sterkt eierskap til beslutningene blant team-medlemmene, man slipper å gå ut av teamet for en beslutning som er tidkrevende og neppe ender slik teamet ønsker, og man tar beslutninger der kompetansen om det som besluttes gjerne er størst. Ofte sier man om et autonomt team at det er produkteier, typisk team-leder, som forteller HVA som skal bygges, så er det teamet som forteller HVORDAN de vil bygge det. Enkelt å si, vanskelig i praksis. For hvis man titter nærmere på HVORDAN det skal bygges, hva bør være innenfor teamets selvråderett? Hvor stor frihet skal de få ha i sine valg?

La meg stille noen ledende spørsmål:

Skal teamet få lov til å bestemme hvorvidt de skal gjøre en risiko- og sårbarhetsanalyse av eget produkt?

Skal teamet få lov til å bestemme hvilken skyleverandør de skal benytte, for eksempel Azure eller AWS eller GCP?

Skal teamet få lov til å bestemme hvilket kodespråk de skal benytte, for eksempel Java eller .NET?

Skal teamet få lov til å bestemme sin egen test-metodikk?

Og skal de i det hele tatt ha noe å si på spørsmålet om HVA som skal bygges?

Jeg sitter ikke på svarene for din bedrift, men jeg er sikker på at du nå har klare meninger om alt dette. Ta eksempelet om valg av skyleverandør. Hvis bedriften har en avtale om bruk av AWS, er det uheldig på mange måter hvis et team tar i bruk Azure. Nok en leverandøravtale, ikke god utnyttelse av den eksisterende avtalen, nok en risiko- og sårbarhetsanalyse av den nye leverandøren, nok et oppsett av infrastruktur i ny plattform. Slike ting. Eller ta eksempelet om valg av kodespråk. Skal teamet få lov til å ta i bruk .NET hvis bedriften har standardisert på Java? Hvordan påvirker det rekrutteringen av nye utviklere? Hva gjør det med kompleksiteten i arkitekturen? Og hva gjør du hvis du har lyst til å flytte utviklere mellom team med forskjellig kodespråk?

Alt dette er eksempler på ting du må ha med i din definisjon av hva autonomi i din bedrift betyr. Listen er på ingen måte uttømmende, men eksemplene jeg trekker frem er viktige å få avklart tidlig, for det er her jeg har sett det har gått galt. Den ultimate manifestasjonen av feil autonomi er feil i produksjonsversjonen av produktet ditt, med nedetid, feil og sikkerhetsfeil og misfornøyde kunder. I tillegg har du kanskje fått et team som er misfornøyd med at utviklerne ikke blir invitert inn i strategiarbeidet, de er jo autonome og skal bestemme HVA de skal lage selv. Høres det kjent ut? Hjemme-alene-fest, kaller jeg det. Og hjemme-alene-fest går stort sett greit helt til noen finner ut at det er en god idé å trekke frem hjemmebrenten.

Nå har jeg problematisert autonomi nok, men det betyr ikke at autonomi er negativt. Autonomi er bra! Autonome team er noe du vil ha! Derfor skal jeg berolige deg med at det å finne rett nivå av autonomi er en iterativ prosess som til slutt tar deg til det nivået både bedriften din trenger og teamet er fornøyd med. Du kommer ikke dit på første forsøk, du må påregne at det går litt tid før du finner en struktur som fungerer hos dere. Og du må også være forberedt på at forskjellige team kan ha forskjellig grad av autonomi. Det er helt greit.

Dermed skal vi litt tilbake til utgangspunktet, om hvordan du etablerer et autonomt team og hva du må tenke på når du etablerer det. I det du etablerer et autonomt team skal teamets rammer settes samtidig. Dersom du har slike rammer fra før, skal de kommuniseres tydelig til teamet. Alternativt kan rammene utarbeides sammen med teamet, da får de godt eierskap og en mulighet til å påvirke deres eget arbeid. Dette er rammer som krever arbeid og involvering av ledelsen. Ledelsen eier malen for autonomi i selskapet, og setter også eksempler på hvor teamet kan avvike fra malen. Eksempelvis har CTO ansvaret for teknologivalgene. COO har ansvaret for organisering og prosess. CISO har ansvaret for informasjonssikkerheten. CFO har ansvaret for leverandørstyring. CPO har ansvar for strategi og produkt. CSO har ansvaret for go-to-market-modellen. Beklager alle C-forkortelsene. Alt dette er eksempler på mennesker som må ta kvalifiserte valg knyttet til teamets autonomi. Hvis ikke kan du være HELT sikker på at teamet arrangerer hjemme-alene-fest ved første anledning!

Som konsulent har jeg hjulpet mine kunder med å etablere autonome team. Jeg har hjulpet dem med å sette rett nivå av autonomi. Og jeg har hjulpet dem med å komme ut av et negativt mønster uten tydelig løsning, altså det jeg kaller hjemme-alene-fester. Resultatet er mer motiverte medarbeidere, som leverer forretningsverdi raskt og effektivt og med høy kvalitet. Jeg har også holdt mange foredrag om teamet, og jeg kommer gjerne og snakker for deg!

Sitter du nå og grubler litt over tilstanden hos dere? Er det hjemme-alene-fest, er det noe som skurrer? Ikke nøl med å be om hjelp! Her er tre ting du kan gjøre som er gratis og uforpliktende:

Det første er å abonnere på mitt nyhetsbrev for regelmessig påfyll av kunnskap og innsikt om teknologiledelse. Du finner link til nyhetsbrevet i episodenotatene til denne podcasten, eller ved å besøke nivlheim.no. Der finner du også gratis veiledere for nedlasting.

Det andre er å være sikker på at du abonnerer eller følger Fimbul, podcasten du nå lytter til. Åpne podcastspilleren din og trykk følg eller abonner.

Det tredje er å sende meg en mail til martin@nivlheim.no og invitere deg selv til en kopp kaffe for å snakke uformelt om de problemene du opplever hos dere. Eller du kan sende en melding til 93055510 eller ringe på samme nummer. Gjør det som passer deg best!

Men nå trenger jeg DIN hjelp! Jeg trenger hjelp til å dele erfaringene i Fimbul. Jeg trenger DIN hjelp til å dele Fimbul med minst én kollega! Én kollega 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!