👩🏼‍💻 Slik knekker du utviklerkoden som leder – med Henrik Byremo fra Team Agile

Dette er en podcast fra Execu. Vi hjelper organisasjonene å utvikle enda bedre ledere og ledergrupper. Lær mer på execu.no. Velkommen til Lederpodden. Mitt navn er Thor Åge Eikrapen. Jeg jobber som organisasjonspsykolog med leder og ledergrupputvikling i XEQ. Og dette her er en podcast om ledelse. Er du leder i vår digitale tid, så må du før eller senere deale med utviklere. Og da bør du vite at utviklere eller programmerere, som vi kalte dem før, de er ikke skrudd sammen sånn som du, kjære leder. De har noen helt andre behov og preferanse for oss som skal til for å få jobben gjort. Og hvis ikke du er klar over dette her, så kan du fort stå i veien og ødelegge for fantastisk flinke folk. Henrik Byremo er en av grunnerne, og han er chief enabling officer i Team Agile. Han er lidenskapelig opptatt av at ledere bør lære mer om hva utviklere trenger for å få til god samhandling. Velkommen til lederpodden, Henrik. Tusen takk, Roger, og takk for den glimrende oppspillen. Hva er det som er din faglige lidenskap? Hvis jeg skal si det kort, så er min faglige lidenskap det jeg vil kalle tverrfaglige produktteam. Altså team som er satt sammen av mennesker med ulike kompetanser, ulike håndverkere, som har ansvar for et helt eller del av et digitalt produkt som vi bruker til å skabe verdier for kundene og for selskapet selv. Og som du sa i introduksjonen, vi er veldig tett på digitaliseringen her. Man sa jo allerede for 10-15 år siden, programvare spiser verden. Og det er den delen av virkeligheten jeg jobber med. Og jeg tenker, det som kan være greit å si, for man snakker mye om teknologi, men digitalisering handler egentlig minst alt om teknologi. Den handler om mennesker. For det er mennesker som laver, og det er mennesker som bruker teknologien. Og den teknologien der er jo først verdifull, når han gjør noen forskjell i andre menneskers liv. Og det er dette menneskelige samarbeidet her, på begge sider av teknologien, som det å gjøre noe godt for andre, som jeg synes er veldig spennende. På dypest sett så handler dette om å lære seg til suksess. Når det kommer til programvare, når det kommer til mennesker, så er det sjeldent sånn at vi kan planlegge oss til suksess. For vi vet ofte ikke hvordan ting fungerer før vi har prøvd. Og da må vi jo organisere oss, og vi må samarbeide, og vi må jobbe på en måte som gjør at vi kan lære oss til suksess. For veldig mange, og mye av de jeg jobber med, handler dette om dynamisk teamorganisering som er fokusert mot kunder og fokusert mot verdiskapninger. Og de er liksom midt i kjernen av mitt interesseområde, og det driver meg. Og du sa det jo innleggsvis, Den titelen min er litt sånn fluffy, men altså Chief Enabling Officer, og det er da enabler, eller det er liksom setter i stand eller forbedrer. Det handler veldig mye om mennesker og verdiskapning. I denne agile tradisjonen, og nå er det mange som definerer det på ulikt vis, men i de mest radikale eller fundamentalistiske fortolkningene, så er det jo slik at lederne byttes ut med agile coachet. Vekk med ledere, mest mulig autonomi, minst mulig kontroll. Jeg setter det litt på spissen her. Men hva er det du ser? Hva er det som er endre seg med lederes rolle når en begynner å gå inn i det agile landskapet? Jeg tenker, først og fremst så tror jeg at vi trenger ledere, men vi trenger absolutt ledere, uansett om man jobber og kaller det etter plandreve eller mer en smidig tilnærming, men vi trenger en annen type ledelse. For For å kalle det den gamle verden, eller den mer tradisjonelle måten å organisere seg på, så handler jo ledelse veldig mye om at du har ansvar for en del av en leveranse. Da handler ledelse om å planlegge den leveransen, og sørge for at den leveres i henhold til de kravene som er stilt, og koordinere denne overføringen mellom en fagavdeling og over til den andre. Mens når du treffer disse tverrfaglige teamene, som er kjernen og hjertet i den smidige måten å jobbe på, så treffer du jo team som er satt sammen på tvers av de gamle skillelinjene, og som er satt sammen for å kunne levere uten større avhengigheter til noen andre. Men når jeg sier at vi da trenger ledelse, så er det jo særlig to ting jeg tenker på. Det første handler om å sette retning, altså å stake ut kursen og si vi skal gå til høyre og ikke til venstre. Det er viktig for kundene og det er viktig for virksomheten. Og når det er gjort, så handler det om å mobilisere og kraftsamle selskap og teamene i den retningen. Og når retningen er pekt ut, så handler ledelse mye om å sørge for at teamene har retning. optimale arbeidsforhold at alt ligger så godt til rette som overhodet mulig for at teamene kan gjøre jobben og rett og slett produsere den verdien og ta selskapet i den strategiske retningen og skape verdier for kundene. Hva er det som er slitsomt ofte? For du er jo ganske godt inn i organisasjoner som du har gjenge fra kanskje en mer prosjektmatris type organisasjon til noe mer agilt og er det du ser de sliter med når det kommer til ledelse? Hei, jeg tenkte i dag kunne vi godt snakke litt om disse mødene her. Fordi utviklingsmiljøen, de jobber jo med såkalt komplekst arbeid. Komplekst arbeid som krever langvarig, uforstyrret konsentrasjon for å komme inn i oppgaveløsninger og bli produktiv. Vi snakket om utviklerne, og utviklerne er et klassisk eksempel på dette. Det gjelder jo for så vidt de aller fleste der hvor Hvor arbeid krever dyp konsentrasjon, om det er kunstnere eller designer, eller liksom, og jeg har fått tilbakemelding fra lærere og saksutviklere og mange forskjellige mennesker dette dreier seg om da. Men særlig da så er dette utviklere. Og dette er jo de folkene som jobber med den teknologien som vi bruker til å skape verdi for målgruppa vår. Men som vi vet da, så består jo virksomheden ikke bare av utviklere. Det er jo masse andre folk i virksomheten som løser masse andre oppgaver. Og disse oppgavene her, de er annerledes. De har en annen natur, og de ser litt annerledes ut, og de løses på en annen måte. Og her treffer vi da disse møtene, som for mange er grunnsteinen, eller kjernen i hvordan vi samarbeider og hvordan vi jobber sammen. Og disse møtene, de er også et enda hardt objekt. Og det går igjen, de har jeg møtt på i hele mitt arbeidsliv, og jeg leste det senest nå, rett før jul. Da har Microsoft og Mural, dette digitale samarbeidsverktøyet, de har noe som heter Global Collaboration Report, eller noe sånt. Og der kommer det igjen, største hindre som de mener er globalt mot effektivt verdiskapning og samarbeid er uproduktive nøter. Og hva er det ledere må forstå som er annerledes når det kommer til utviklere og møte og hvordan de strukturerer et samarbeid? Det som jeg tenker er liksom, når vi tar utgangspunkt i det spørsmålet, så tenker jeg vi må snakke litt om, altså vi må se på verdiskapninger, for det er jo liksom det grunnen til at virksomheten eksisterer, og det gjelder jo uansett om man er privat eller offentlig, så er man til for noen andre. Og så må vi si, ok, hvis vi legger dette grunnen da, så ser vi inn, hvordan er det vi løser den oppgaven vår, hvordan er det vi skaper verdi, og Og da går det litt sånn grovt sett, så kan vi skille på egentlig to ulike måter å jobbe på, basert på hvordan så enkelt som kalenderen din ser ut. Og vi skiller da ofte mellom det jeg kaller lederkalender og en utviklerkalender. Og denne lederkalenderen da, som gjelder de aller fleste ledere, den er typisk smekkfull av møter. Og det er fordi ledere skaper verdi gjennom koordinering, gjennom sparring, gjennom forankring, gjennom beslutninger, facilitering, coaching, og så videre, og så videre. Da er møtet et veldig hensiktsmessig format, for du stykker dagen opp i mange entimespolker som ikke trenger å henge sammen med hverandre, fordi du kan gjøre ulike ting og dele stykket dagen din opp, hvor ny aktivitet følger for ny time. Og det henger jo sammen med at lederrollen primært da skaper liksom verdiene sine ansikt til ansikt, og møter et veldig effektivt format for den jobben ledere ofte gjør. Men som jeg sa, så er jo ikke en organisasjon hverken bare utviklere eller bare ledere. Ofte så har du jo da en masse andre folk som kaller det skaper noe. Og for disse menneskene her, så er dagen da nesten blåtta for møter. Og da har du det jeg kaller en typisk utviklerkalender. Den ser typisk ut som ingen møter før lunsj, lunsj, ingen møter etter lunsj. Og det reflekteres i at for å gjøre den jobben du da skal gjøre, for å gjøre den jobben utviklerne gjør, så trenger du langvarig, uforstyrret konsentrasjon, og du trenger tid for å bli produktiv. Du trenger tid for å sette deg inn i oppgaven og liksom komme i flytsona. Og her treffer vi jo liksom disse møtene da, for de har en tendens da til å ødelegge flyten nettopp i dette arbeidet her. Og liksom det å avbryte, selv om det er bare fem minutter, så avbryter du egentlig liksom hele flyten i arbeidet, og resultatet blir liksom ødeleggende. Jeg kan gi et veldig godt eksempel, for dette har vi jobbet med en del, og det er ikke så lenge siden jeg målte det også. Så jeg hadde en diskusjon med en som var leder for veldig mange team, og hun hadde særlig ett team da. Hun sa det jo ikke så veldig direkte, men jeg tror noen synes de var himmel og trege, og synes kanskje at her burde noe gjøres, de kunne stramme seg litt opp og programmere litt fortere. Og så hadde vi en diskusjon, og for å gjøre en litt lang historie kort, så ble vi enige om å flytte litt om på mødene. Vi skulle ikke ha færre møder, vi skulle ha like mange møder, men vi skulle flytte litt på dem, sånn at vi tok utgangspunkt i hva teamet selv mente om langvarige arbeidsperioder uten avbrytelser, hvordan det kunne se ut da. Og alt annet ble forsøkt holdt i ro, og så ble vi rett og slett enige om hvordan måler vi da produktivitet, og Så satt vi i et eksperiment, vi tenkte at ok, dette her tar kanskje tre, kanskje fire uker for at vi kan få noe effekt av dette. Vi må jo, skal jo tross alt endre noe på praksis og sånn. Og så satt vi i gang. Og resultatet da, etter knapt fire uker, var altså det vi kalte pull request cycle time, som egentlig bare er et mål på hvor lang tid du bruker på å fullføre en oppgave. den ble redusert med tett på 80% på under fire uker. Så for å si det på en litt annen måte da, det som før tok en uke å fullføre, kunne de samme folkene ha gjort på en dag. Det er ganske bra, jeg må si, jeg var faktisk overrasket selv. Hvis jeg skulle gjette på forhånd, så hadde jeg kanskje, jeg tror jeg må si, jeg hadde håpet på at man skulle liksom få til en dobling da, eller at noen skulle gå dobbelt så fort. Så jeg synes dette her var egentlig over all forventning, men det bygger opp om det poenget her, at avbrydelser i seg selv, og enda være uproduktive møter, men avbrydelser i seg selv, det koster mye mer enn tida bare mødet tar, for det ødelegger flyten i utvikleren sitt arbeid. Og en utvikler på det teamet sa at bare liksom tanken på en kjapp statusoppdatering, det ødelegger hele formiddagen min, fordi jeg vet at i det jeg begynner å komme og være produktiv, så må jeg avbryte arbeid, gjøre noe annet og sette meg inn i det, og så er det lunsj og så er liksom hele formiddagen ødelagt, som enn hvor spisformulert det er, så synes jeg at det illustrerer poenget veldig, veldig godt Og hvordan ser en en sånn uke ut da, som er tilpasset denne utviklermåten å jobbe på? Ja, det er for så vidt et godt spørsmål, fordi på et team da, så vil du ofte finne, et team som er satt sammen for å kunne levere selvstendig uten så veldig store avhengigheter, er jo ofte satt sammen av ulike roller. Du har normalt en produktleder, og kanskje en designer, kanskje noen som jobber med data, og en del som jobber med teknologien. Og da finner du jo internt også, så finner du jo kalenderkollisjoner, fordi programmering og design og dataanalyse, det er et typisk jobb som skjer på utviklerkalenderen, mens bruk og testing og prototyping og det å workshoppe samskap, innsikter og forankring og sånn, typisk det skjer på lederkalenderen. Men Men det handler liksom om å finne en balanse som fungerer. Og så må vi liksom si at tverrfaglig samarbeid, det er mer enn bare møter, men det krever tross alt også at folk møtes. Og av og til mer enn kanskje man skulle ønske, men det er dette med balanse da, sant? Å finne en balanse som fungerer for teamet og for lederen. Og det enkleste, som du skjønner, så er jeg veldig opptatt av verdiskapning og hvorfor vi egentlig da er til, og det enkleste er jo egentlig å ta utgangspunkt i verdiskapning og si hvem er det som gjør den jobben som skaper verdier for oss? Og i disse produktteamene da, så vil jo det normalt være teamene og utviklerne som står for liksom sammen da, det tørrfaglige teamet som sammen står for det produktet. Og Da er det egentlig sånn at vi må ta utgangspunkt i de som er minst fleksible, fordi det er deres arbeidshverdag som blir ødelagt mest. Hvis du som leder har 6-9 ulike møter i løpet av en dag, så er det ikke så nøye om møtet kommer halv 11 eller om det kommer rett etter lunsj. Så de som er vant til flere møter om dagen, de påvirkes mindre av møteflytting, og motsatt av de som ikke bruker møter så mye for å kunne gjøre jobben sin. Ja, og så tenker jeg, for de teammedlemmerne, og det gjelder for så vidt for ledere utenfor også, som jobber på begge kalenderene, det vil typisk være en produktleder, eller kanskje det vi kaller en tech-lead, eller en designer og sånn, så handler det, rent som praktisk, så handler det ofte om å dele dagen i to, tenker jeg. For eksempel morgen, jobb fire timer, uforstyrret, Få deg selv konsentrert arbeid, spis og lunsj, og så tåler du kanskje to-tre timer med møter etter det, hvor du gjør unna det praktiske, altså det å bolke det opp, slik at du får disse lange, gode arbeidsperiodene. Det høres deilig ut. Ja, det er veldig effektivt. Det er et veldig godt tips, Henrik. Er det noen som fyller en dag i uka som er bare møte, og så er resten deep work? Ja, veldig mange ledere har det jo sånn da. Jeg tror, men dette har jo noe med litt sånn, hvilke møter er det du har behov for da på dette tverrfaglige teamet ditt, og noen har nok Det er ikke så mange som har hele dager, men mange har nok deler av dagen som er avsatt til møter, og da er det typisk før eller etter lunsj som er det avbrekket. Fordi lunsj er et naturlig avbrek. De fleste blir sultne, og mange blir jo hverken mer produktive eller mer godt humør av å være sultne, og dermed er det et naturlig avbrek hvor du tar hodet ut av domen og konteksten. og prater litt sånn. Og da, uansett om det er stand-ups, eller demo, eller retrospektiv, eller planlegging, eller hva enn du gjør, er et godt tidspunkt å bryte opp dagen, og bytte kontekst fra utviklerkalender til lederkalenderen. Nå gikk du jo inn i det store repertoaret av ulike møter som finnes i Agilmetodik og andre steder, men Henrik, du har vært inn og ut av ulike organisasjoner, du har sett folk som gjør ting på en god måte, på en dårlig måte. Hva er det som kjennetegner de beste møtene, hvis vi skal dykke inn i selve møtet? Ja, jeg tenker de beste møtene, og dette høres nesten litt overraskende ut, men de beste møtene er der hvor folk er enige om hvorfor de skal møtes. Du snakker mye om sånne smidige seremonier og sånn, men jeg tenker at Det at noe står i Scrumguiden, eller det at alle andre gjør det, det er overhovedet ingen grunn til å møtes i det hele tatt. Det er en oppskrift på å gjøre det andre har gjort, og du aner ikke om det fungerer for deg. Så man må bli enig om hvorfor vi trenger dette møtet. For det første kan dette møtet være en e-post eller en statusoppdatering på nett, men også hvorfor er dette møtet til? Hvorfor trenger vi det? Ja. Jeg tenker litt forenklet, men for meg handler møtet om at vi skal beslutte noe, vi trenger å være flere rundt bordet for å ta en beslutning, eller vi skal lære noe, vi har fått noen ny innsikt eller fått noen ny data, og vi trenger å belyse den fra ulike perspektiver for å skjønne hva dette betyr for oss. Ellers så handler det om å gjøre noe, altså vi skal samskape noe, vi skal jobbe rundt en prototype, eller vi skal gjøre et eller annet som er tett rundt målet vårt. Det var liksom å beslutte, lære, gjøre, og så er det det menneskelige der, altså knytte sosiale bånd. I det hele tatt så vil jo de mødene være en kombinasjon, altså både av det sosiale og av arbeidsoppgavene. Men det viktigste, uansett hva man dytter inn i de mødene, er å bli enig om hvorfor dette mødet skal finnes til i det hele tatt. Henrik, er det noe som du har lyst til å melde ut til lederne som hører på lederpodden som ikke har spurt deg om? Ja, jeg tenker det beste er alltid å starte med seg selv. Det er veldig greit å mene noe med andre, men det beste er alltid å starte med seg selv. Og særlig for ledere, særlig når vi snakker om teamorganisasjoner og innenfor det digitale domenet, så er det jo sånn at teamene står for de står for verdiskapninga, de står for den jobben og liksom de tunge løftene og håndverksarbeidet som organisasjonen har, og da tenker jeg start med teamet. Teamet er fabrikklinja, og du stopper jo ikke i fabrikklinja for å lure på hvordan det går med fabrikklinja, du finner en måte å løse det på. Det samme gjelder team. Så i stedet for å da få spisformulert litt, tenke og si sånn, at det hele er en leder som kan gjøre som jeg vil, jeg kaller bare inn til møter akkurat når det passer meg, så må Så må du spørre teamene, eller hvis det er enkeltpersoner eller teamene leder, så må man si «Hei, dette er mitt behov som leder. Dette er behovet for å kunne gjøre jobben min. Hvordan kan vi tilpasse dette deres hverdag, slik at dere kan jobbe mest mulig effektivt?» Og så reelt sett tilpasse seg deretter da. Dette kaller jeg å ta samling rundt verdiskapninga, og ta samling rundt og hele tiden reflektere over spørsmålet, hvorfor er vi til? Hvem er vi som virksomhet til for? Og hvordan må vi jobbe sammen og organisere oss for å skape mest mulige verdier for den målgruppen der? Veldig bra, Henrik. Tusen hjertelig takk for at du kom til Lederpodden. Jo, så hyggelig. Tusen takk. Til deg som hører på, hvis du er nysgjerrig på alt som skjer i vårt lederunivers, kom deg inn på lederpodden.no, trykk på den rette knappen og legg igjen din e-post, og du vil få vårt ferske nyhetsbrev i din inbox hver eneste fredag. Takk igjen for at du hører på Lederpodden. Vi høres igjen om en uke. Lederpodden er gitt til deg av Execu.