Episode 21: Slik bygger du et autonomt team

Hvordan får du gjort ting på jobben? Hvem jobber du med? Hvordan jobber dere sammen? Og hvem har bestemt at det skal være slik?

Hei, Martin her, og du lytter til Fimbul!

Et team er en liten gjeng mennesker som jobber sammen. Enten i en liten bedrift, eller i en avdeling i en større. Hensikten med å gruppere folk i mindre enheter avhenger selvfølgelig av formålet til den som har ansvaret for organiseringen, men jeg tar neppe mye feil når jeg sier at hensikten er å samle mennesker som jobber mot samme mål. Vi samler oss for å nå et strategisk mål og tjenestene eller produktene vi lager er midlene for å nå målet.

Den vanskelige delen av slik organisering er å finne den rette sammensetningen av de rette menneskene: Hvor mange det skal være, hvilken kompetanse de må ha og hvordan de er som mennesker. Det finnes ingen fasit, det vil si fasiten er det du får til å fungere så optimalt som mulig. Og som du vil erfare underveis blir det aldri perfekt. Det er helt greit.

I en diskusjon om autonomi vil du oppleve at dem du snakker med gjerne har forskjellig forståelse for hva som ligger i begrepet autonomi. Noen elsker autonomi, fordi det gir dem fremdrift og eierskap til arbeidet, mens andre misliker det fordi begrepet har blitt fylt med feil innhold og gjennomføringen ikke har vært som den burde.

Autonomi er et teams ansvar for det de lager. Jeg pleier å snakke om at et autonomt team har ende-til-ende-ansvar i to dimensjoner.

Den ene dimensjonen er å følge et konsept teamet jobber med fra konseptet oppstår som en idé, til det løser problemer for ekte kunder. Fra ideen oppstår, enten internt i teamet eller det for eksempel kommer til teamet fra en kunde, skal teamet kunne følge ideen hele veien i gjennomføringen, uten overleveringer til eller fra andre team eller avdelinger. Da samler teamet alle erfaringer underveis og kan justere konseptet fortløpende og ikke minst etter at det er i bruk av kundene, når man samler de viktigste erfaringene. Konseptet skal altså ikke utarbeides av ett team og leveres i markedet av et annet.

Den andre dimensjonen er teknisk og handler om at teamet skal ha fullstendig ansvar for de tekniske løsningene og produktene som måtte lages. Dette avhenger litt av hva man skal levere til markedet, for noen bedrifter lager produkter som lages utenfor teamet, eller tjenester som utføres av andre enn teamet. Men i teknologiutvikling snakker vi om autonomi for tjenestene som lages, alt fra drift og det som skjer i back-end med databaser og nettverk og brannmurer og annen infrastruktur, til det som er synlig for kundene på web og i apper. Teamet skal ha full råderett og arbeide med alle løsningene som skal til for å få tjenesten levert. Et team skal aldri være avhengig av andre for å få laget løsningene sine. Det reduserer kvaliteten fordi dem som lager løsningene heller ikke har eierskapet til dem, og det forsinker fremdriften fordi overleveringer innebærer venting. Venting på at andre skal få tid til å gjøre akkurat din oppgave.

Som nevnt vil du ofte oppleve at noen snakker om autonomi som om det er noe negativt, og begrepet har da blitt fylt med feil innhold. Det finnes nemlig god og dårlig autonomi.

Dårlig autonomi er enten når et team har for lite eller for mye autonomi. For lite autonomi har et team når det ikke har det reelle ansvaret for det man skal lage, men i stedet har en slags skinnprosess der andre i realiteten bestemmer og teamet bare utfører. For lite autonomi har man også hvis man ikke har reelt ende-til-ende-ansvar både fra idé til konsept eller for de tekniske tjenestene og produktene man lager, slik jeg akkurat snakket om. I slike situasjoner har man det jeg kaller innbilt autonomi. Det vil si at man har blitt fortalt at man er et autonomt team og man innbiller seg selv at man er et autonomt team, mens man i praksis erfarer at autonomien ikke er reell. Et team med for lite autonomi ender ofte opp med å bli frustrerte fordi de opplever at det alltid er «noe» i anførselstegn som forhindrer dem fra å få fullstendig eierskap til det de arbeider med. Og frustrerte mennesker resulterer i høyere gjennomtrekk av folk og kompetansen forsvinner ut og den negative spiralen er i gang. Hvis du er leder og ønsker at et team skal være autonomt, betyr det også at du må gi fra deg en del av ansvaret til teamet. Du må akseptere at mennesker tar andre valg enn du selv ville gjort, og du må være innforstått med at det er greit. Og ofte vil du også oppleve at det strengt tatt også er bedre, for hvis du omgir deg med smarte folk vil du også se at løsningene de kommer opp med gjerne er bedre enn dem du selv kommer med.

Dårlig autonomi har man også dersom et team har for mye autonomi. Det er også mulig. For mye autonomi betyr at man har delegert for mange beslutninger helt ut til alle team-medlemmene. Autonomi betyr nemlig ikke demokrati, altså at alle på teamet skal være involvert i alle beslutninger. Et team har forskjellige roller og team-medlemmene har autonomi innen sitt eget fagområde. Det er for eksempel designeren som bestemmer hvordan det skal se ut. Det er utvikleren som bestemmer hvordan det teknisk skal lages. Det er forretningsutvikleren som bestemmer hvordan vi skal løse det konseptuelle problemet. Og det er produkteier som bestemmer hva som skal lages når. Videre har teamet også noen eksterne rammer å forholde seg til, som typisk springer ut av strategien gjennom OKR som du kan høre mer om i episode 11 av Fimbul. Enkelt forklart pleier jeg å si at det er bedriftens overordnede mål og forretningssiden som bestemmer HVA som skal lages og at det er teamet som bestemmer HVORDAN det skal lages.

Skal et team oppnå reell og riktig autonomi krever det aksept fra dem som bestemmer. I en liten bedrift er de ansatte kanskje omforent om dette allerede fra starten, mens man som leder i en større bedrift må gi et team eller en avdeling anledning til å ta selvstendige beslutninger for å nå de målene som er satt og for å løse problemet for kundene. Teamet vil aldri oppnå reell autonomi dersom ikke ledelsen gir dem det.

Gis teamet slik autonomi er det teamets oppgave å se hvilken kompetanse som er nødvendig for å kunne ta et konsept fra idé og ut i markedet, og hva som skal til for å lage det. Interaksjonsdesignere, utviklere, forretningsutviklere, analytikere, selgere og alle andre som måtte være involvert i arbeidet. Som oftest vet teamet dette selv, fordi de ser gjennom arbeidet hva de har behov for, og du som leder må bistå dem med å skaffe denne kompetansen. Samtidig er ikke dette en ønskebrønn av kompetanse det kunne vært kjekt å ha, men den faktiske kompetansen teamet trenger fra dag til dag. Det er for eksempel ikke sikkert det er nødvendig å ha en korrekturleser i teamet. Noen ting kan det være greit å gjøre eksternt, men igjen er det teamet som kjenner best hvilken kompetanse de trenger på daglig basis.

Når jeg bistår med å etablere autonome team, starter vi med de folkene vi trenger i starten og putter ikke på flere enn nødvendig. Det er ingen grunn til å putte på folk jeg tror vi kan trenge, men i stedet forstå at faktisk behov trumfer antatt behov. Behovet synliggjør seg raskt. Ofte vil du se at man kommer langt med 3-4 personer i starten, og ideell størrelse kanskje befinner seg en plass rundt 7 personer. Et lite team har overraskende høy fart og er svært produktive, men når teamet vokser vokser også behovet for administrasjon og orkestrering av arbeidet. Det er ikke et en-til-en-forhold mellom flere folk og gjennomstrømning av arbeid. Jeg pleier litt flåsete å si at det tar én kvinne ni måneder å føde et barn, men det tar ikke ni kvinner én måned å gjøre samme jobben. Flere folk er ingen garanti for bedre produktivitet. Det finnes ikke et korrekt svar på hva som er rett størrelse på et autonomt team. Det må du finne ut av selv, for det avhenger av hva du skal lage og hvem du har med deg.

Et teams autonomi avhenger også av kompetansen i teamet. Teamet må ha en slags avtale om arbeidsfordeling, og ikke minst om hvem som har siste ord i diskusjonen når det er uenighet i teamet. Uenighet er bra, for da får teamet flere løsninger på et problem, men noen må til sist ha det siste ordet. Ethvert team har en produkteier, fra smidig kjent som product owner. Og det er produkteier som eier backloggen og bestemmer hva som skal utvikles. Produkteier innhenter nødvendig kunnskap fra fagdisiplinene og fra kundene og tar det med til grooming. Grooming er et regelmessig møte der teamet tar en liten pause fra pågående arbeid og planlegger litt fremover, kanskje den neste uken. Alle må stille forberedt og være beredt til å legge frem egne behov. Sikkerhetsansvarlig har kanskje en sikkerhetsoppdatering som brenner på dass. Utviklerne har en kritisk bug. Designeren skulle gjerne forbedret noe i brukergrensesnittet. Selgeren har et behov fra en kunde. Og så videre. I grooming møtes uenigheter og det er produkteier som har siste ord på backloggens rekkefølge. Dette berører også kulturen i et team ved at alle sitter i samme båt. Alle i et team må ha forståelse for at andre fagdisipliner også har sine behov som skal løses. Det er vesentlig at alle i et team har gjensidig forståelse for hverandres behov, og aksepterer at det sjelden er egne behov som blir prioritert først. Som et individuelt team-medlem er det viktig å se på arbeidet som en helhet og ikke bare på egne behov. Hva er det som bringer teamet nærmere målet?

Hvordan et autonomt team skal jobbe kan i stor grad også overlates til teamet selv, men det er greit å være enige om at en smidig arbeidsprosess er å foretrekke. En prosess der man verdsetter validert læring og tar ny kunnskap inn i arbeidsprosessen for å kontinuerlig forbedre produktene og tjenestene man bygger. En prosess der man kontinuerlig leverer små biter av verdi, verdi i form av problemløsning for kundene og verdi til bedriften vi jobber i. Har man ikke erfaring med smidig er metodikken Scrum et fint sted å starte og man kan bruke Kanban for å visualisere arbeidet, for eksempel på Trello. Du finner flere detaljer som Scrum og Kanban og Trello i notatene til episoden på fimbul.tech. Har man derimot erfaring er det greit å selv sy sammen prosessen slik teamet mener den burde være. Det viktige er at teamet er omforent om prosessen og at alle forstår den og forholder seg til de spillereglene som blir satt. Et godt orkestrert team bruker lite tid på prosess og metode og mer tid på selve arbeidet.

I epsiode 18 av Fimbul snakker jeg om verdien av å ha nyutdannede på teamet. Sammen med erfarne seniorer får man en fin miks av ny kompetanse og erfaring.

Teamsammensetning handler ikke bare om kompetanse, det handler også om hvem vi er som mennesker. Det heter at kultur spiser prosess til frokost. Min erfaring er at det er reelt. Det hjelper ikke at teamet har skrevet på veggen med fete bokstaver hva som er arbeidsprosessen og arbeidsfordelingen, hvis det i realiteten i hverdagen ikke er slik. Jeg har i flere tidligere episoder snakket om verdien av å anerkjenne problemer, men se på dem som en mulighet til forbedring. I episode 13 av Fimbul om retro hører du mer om verdien av en løsningsorientert kultur hvor man allikevel kan ha god stemning selv om det er problemer. Noe av det viktigste jeg gjør for å bygge en robust kultur, er å bygge god stemning i et team. Og reell autonomi er én av mange verktøy for å bygge god stemning. Problemer vil det alltid være i et team og folk må bli fortalt at de skal anerkjenne problemene, komme med løsningsforslag og bistå til å løse dem. «Hei! Jeg ser dette problemet! Det kan løses slik og jeg kan bistå sånn!» Da bygger du god stemning og en robust kultur som tåler vanskeligheter og utfordringer.

Hvorvidt du ønsker å ansette folk selv eller leie inn konsulenter avhenger av mange ting, blant annet av hvor viktig du mener det er å ha kompetansen ansatt og ikke innleid. Gjort riktig mener jeg at det ikke er så viktig. Det som er viktig er at du behandler alle som om de er dine egne. Jeg pleier å si at det er ikke så viktig hvilket firmanavn du har trykket på visittkortet, alle behandles som ansatte. Det er ikke dem og oss, det er vi. Det er vi i teamet og det inkluderer alle.

Men 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!