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.