.avif){kind=logo}
...selv når du ikke koder
Som utvikler elsker jeg å kjenne på den deilige følelsen av flyt når jeg koder. Når løsningen på magisk vis faller på plass, og tiden bare flyr. I tillegg føles det veldig produktivt, og jeg føler meg verdifull. Men rett som det er kan det komme en irriterende liten notification nede i høyre hjørne av skjermen - en Slack-melding eller e-post fra en kunde eller kollega som trenger noe ASAP. Eller enda verre: teamlederen kaller inn til Jira-planlegging. Hvem trenger fiender når man har en teamleder? Neida, de er ikke så verst – tvert imot.
Forhåpentligvis kjenner du deg ikke helt igjen i dette. Kanskje er du en av dem som jobber i et team med ekte samarbeid, der man forstår verdien av å bygge sammen – ikke bare kode hver for seg.
I tillegg til å være utvikler, jobber jeg også som teamleder i tverrfaglige team, så jeg vet hvordan det er å være på begge sider av bordet. Jeg har selvfølgelig bare gode intensjoner når jeg kaller inn til workshops, planleggingsmøter, retrospektiver og andre teammøter, men jeg har forståelse for at jeg ikke alltid er den mest populære personen i rommet.
Ønsket mitt er ikke å forstyrre flytsonen til utviklere. Det er å skape rom for samarbeid i team eller mellom team, visualisere hva vi jobber med, og sørge for at vi har fokus på de viktigste problemene å løse. Av og til får jeg høre: «Anne, dette har jeg ikke tid til, vi må levere!» Og da kjenner jeg på følelsen av å ikke være så godt likt– og at jeg kanskje burde latt være?
Men komplekse problemer kan ikke løses av enkeltpersoner som sitter hver for seg og skriver perfekt kode. De krever at vi ser ting fra flere perspektiver samtidig – teknologisk, menneskelig og forretningsmessig. Det er først når vi jobber sammen at vi oppdager nyanser, sammenhenger og muligheter utenfor det kjente.
Når designer, utvikler og produktleder diskuterer samme problem, bygger vi en felles forståelse som ikke kan oppnås alene. Det er derfor vi trenger tverrfaglige team, og det er derfor samarbeid ikke bare er ønskelig, men nødvendig.
Vi trenger utviklere som ikke bare koder løsninger, men som også aktivt deltar i å utforske dem. Fordi når utviklere deltar tidlig i designprosessen, bidrar de med verdifull teknisk kunnskap som ofte fører til mer innovative og gjennomførbare løsninger. Samtidig får designerne verdifull tilbakemelding på om ideene deres er teknisk gjennomførbare. Denne samarbeidsprosessen er noe av det mest verdifulle vi gjør og sparer teamet for betydelige mengder unødvendig kode.
Hvis vi ikke validerer løsninger før vi bygger dem, risikerer vi å utvikle produkter som mangler verdi for brukerne våre og forretningen. Jo tidligere vi får denne tverrfaglige utvekslingen av perspektiver, desto mindre unødvendig arbeid må gjøres senere, og desto bedre blir sluttresultatet.
Jeg sier ikke at det er lett. Vi vil jo løse problemet. Helst så raskt som mulig. Og det å ikke forstå noe kan være svært ubehagelig hvis du ikke har kjent på det mange nok ganger. Det er lett å gå rett i løsningsmodus – spesielt når man har dyktige utviklere som er klare og ivrige etter å levere.
Uten å teste om det vi lager faktisk løser problemet vi tror det løser, risikerer vi å fylle produktene våre med funksjonalitet ingen bruker, ingen forstår, eller ingen finner. Ikke fordi utviklerne har gjort en dårlig jobb, men fordi vi hoppet over den viktigste delen: å sjekke om det faktisk var verdt å bygge. Koden fungerer, men verdien uteblir.
Over tid bygger det seg opp et produkt fullt av utydelige valg, overflødige funksjoner og komplekse avhengigheter – og plutselig sitter vi igjen med teknisk gjeld vi ikke forstår hvor kom fra. Å skrive kode uten å validere verdien først er i praksis å optimalisere for fart – ikke for verdi.
Og når teamet forstår det, endres hele tilnærmingen: vi begynner å stille bedre spørsmål, eksperimentere tidligere og måle det som faktisk betyr noe. Da begynner vi å bygge produkter som treffer – ikke bare teknisk, men også menneskelig.
Er du så heldig som meg, og har hatt gleden av å jobbe i et myndiggjort team der ansvaret for å skape faktisk verdi ligger hos oss som bygger produktet, så vet du også at vi må ha rammene og tilliten til å gjøre gode valg underveis. Det betyr ikke at vi vet alt på forhånd – nei, her er det masse usikkerhet. Men vi har en retning, og vi har kompetansen og innsikten som trengs for å utforske problemet, teste løsninger og bygge det som faktisk fungerer. Og noen ganger må vi innse at produktet ikke har livets rett, det skaper ingen verdi eller tjener ikke nok penger. Ja ja, så må vi svelge den kamelen og gå videre.
Du lurer kanskje på hva et myndiggjort team egentlig er? Et myndiggjort team kjennetegnes ved at det arbeider tverrfaglig som en samlet enhet, med produktleder, designer og teknisk leder i sentrum – ofte omtalt som en produkttrio. Sammen tar vi det fulle ansvaret for å løse reelle utfordringer på måter som både skaper verdi for brukerne og bidrar til å oppnå forretningsmålene.
Produktlederen spiller en nøkkelrolle i å tydeliggjøre hvilket problem vi skal løse, og hvordan det henger sammen med selskapets overordnede strategi. Det gir teamet den konteksten vi trenger for å sette retning, formulere mål som inspirerer, og ikke minst: vite hvorfor vi gjør det vi gjør. Vi jobber eksperimentdrevet, validerer hypoteser før vi bygger, og måler effekten av det vi lanserer. Det gir oss trygghet i at vi bygger noe som faktisk betyr noe – og reduserer risikoen for å lage produkter ingen trenger.
Fordi vi har all nødvendig kompetanse i teamet, kan vi ta eierskap til hele prosessen, fra vugge til grav. Det gjør oss både raskere og mer presise – og det gjør arbeidet vårt mer meningsfullt.
Til syvende og sist handler det om å forvandle kodelinjer og samarbeid til varig verdi for mennesker. Det handler om å skape genuine forbedringer i hverdagen til folk – på gata, i butikken, på trikken, eller på et sykehus. Der hvor selv små endringer kan gjøre stor forskjell. Når vi bygger produkter som faktisk løser reelle problemer, da vet vi at arbeidet vårt virkelig betyr noe.
Som utvikler og teamleder er jeg glad for å kunne bidra til denne verdiskapningen sammen med teamet mitt. Og er du heldig som meg, så er du eller har vært en del av flere velfungerende team. Det å kjenne at man overgår sine egne forventninger og strekker seg litt lenger fordi man er omgitt av kolleger som løfter hverandre fram og bidrar med ulike perspektiver. Og som teamleder blir jeg ekstra glad når jeg hører engasjerte diskusjoner på tvers av fagområder, hvor alle bringer sine unike innsikter til bordet. Disse øyeblikkene gir meg masse energi og mening.
Noen dager er krevende, men det er verdt det. Å bygge team som tar eierskap krever tid og utholdenhet – men gevinsten overgår hundre features levert på autopilot.
Og nå? Jeg får ikke lenger høre "Anne, dette har jeg ikke tid til, vi må levere!" når jeg kaller inn til teammøter. For vi har alle forstått at god utvikling handler om mer enn bare koding – det handler om å skape verdi sammen.
Trenger et myndiggjort team en teamleder? Det må bli en diskusjon for en annen bloggpost. Jeg har ikke alltid hatt en formell rolle som teamleder i teamene jeg refererer til her – jeg har vært utvikler, tech lead, Engineering Manager eller team coach. Likevel har ansvaret jeg har tatt for teamets samarbeid og dynamikk stort sett vært det samme, uavhengig av tittel.
Anne har over 20 års erfaring med teknologi og ledelse, og har de siste årene jobbet som teamleder og product discovery coach i blant annet Vipps og Ruter. Hun har ledet tverrfaglige team i komplekse miljøer, med fokus på smidige metoder, eksperimentdrevet utvikling og verdiskapning. Med bakgrunn som seniorutvikler og sertifiseringer innen coaching og Scrum, kombinerer hun teknisk tyngde med sterk forretningsforståelse og et stort engasjement for teamutvikling.
obr@capraconsulting.no
+47 971 20 556
