Mange virksomheter står nå midt oppe i en transformasjon hvor de beveger seg fra mer tradisjonelle modeller og måter å jobbe på, til det vi kaller for produktmodellen (Marty Cagan — Transformed 2024).
Min kollega Jarle forklarer godt essensen av dette i et annet blogginnlegg, men kort fortalt handler det om at IT ikke lenger er noe som skal levere på forretning sine bestillinger om funksjonalitet. Produktmodellen anerkjenner at IT er en del av kjernevirksomheten din, og at potensialet ditt for verdiskaping ligger i å skape høytpresterende tverrfaglige team.
En verden hvor team får delegert problemer som skal løses i stedet for oppgaver, stiller mye høyere krav til god ledelse. Ledelse handler ikke lengre om å få levert oppgaver innenfor fastsatt tid for så å rapportere på oppgaveprogresjon oppover. Det handler om å skape motiverte folk som ønsker å få til gode ting, og tar eierskap og ansvar for det de gjør.
Dette er ikke bare produktlederen sitt ansvar, men også ditt, tech lead! Produktledelse som fag handler om å lykkes med digital produktutvikling, og det krever tverrfaglighet i håndverket og tverrfaglig ledelse.
Det ansvaret jeg snakker om videre her nå kan like gjerne tas av en hvilken som helst utvikler på teamet. Det er ikke nødvendig å ha tech lead-rollen. Det uformelle mandatet, og hva man faktisk gjør, vil alltid være viktigere enn tittelen din. Dog, det er enklere å ta mer ansvar utover kjernehåndverket ditt om man har litt erfaring. For enkelhets skyld bruker jeg bare tech lead videre i innlegget.
5 ting du må ta ansvaret for som moderne tech lead
- Du må ta aktiv del i produktutforsking, og vise de andre utviklerne at dette er like viktig i produktutviklingen, som det å kode.
- Du må bidra til å skape en kultur for ekte tverrfaglig samarbeid i teamet.
- Du må sørge for de tekniske rammene og bidra til en kultur for kontinuerlige leveranser.
- Du må forstå, og coache de andre utviklerne i, at det handler om å levere effekt, ikke oppgaver.
- Du må kontinuerlig drive med talentutvikling og myndiggjøre folka rundt deg for å unlocke innovasjon.
Hovedsakelig så jobber et tverrfaglig team kontinuerlig i to moduser. Produktutforskning og kontinuerlige leveranser. Produktutforsking er alt man gjør for å komme frem til hva som er verdt å bygge. Kontinuerlige leveranser er måten man bygger selve produktet på.
Team som bare jobber med produktutforsking får aldri levert noe. Team som bare leverer kontinuerlig, risikerer å bruke masse penger på å lage et produkt brukerne ikke vil ha. Ida Aalen kaller dette for henholdsvis analysefella og byggefella. Poenget er at man må gjøre begge deler — kontinuerlig.
«Du som tech lead har også et unikt perspektiv for det tekniske mulighetsrommet som ingen andre enn utviklere har.»
Produktutforsking er et tverrfaglig samarbeid
Du som tech lead er hovedansvarlig for å håndtere risikoen om gjennomførbarhet i produktutforskningsfasen. Det betyr i praksis at når teamet sitter sammen og lager forslag på hvordan noe kan løses, så bør du mene noe om hvor vanskelig eller lett noe er å implementere. Det er tross alt du og utviklerne som må realisere og bygge løsningen.
Du som tech lead har også et unikt perspektiv for det tekniske mulighetsrommet som ingen andre enn utviklere har. Designeren har på sin side ansvaret for at løsningen er brukervennlig, mens produktlederen må ta hovedansvaret for at produktet er levedyktig i konteksten av virksomheten, samt gir verdi til de som bruker det. Det betyr ikke at du som tech lead ikke skal bidra til at produktet er brukervennlig. Det burde du absolutt gjøre, men det er designerens hovedansvar. Kraften i et tverrfaglig team utnyttes først til det fulle når man kommer frem til en løsning sammen.
At designeren lager en skisse som utviklerne implementerer er hverken produktutforsking eller tverrfaglighet. Det er vannfall. Design som fagfelt er nesten alltid i mindretall i et team, og ofte er det bare en designer.
Du som tech lead burde bidra til å skape en kultur som fordrer tett og kontinuerlig samarbeid med designeren. Det betyr å koble designeren tett på det dere leverer av funksjonalitet i produksjon, slik at videre iterasjoner av produktet skjer på det som er levert og ikke gamle skisser.
Alle tech leads eller design leads som utøver produktledelse burde ha reell interesse og god kjennskap til forretningsmodellen til virksomheten og lønnsomheten til produktet de lager. Det å forstå fundamentalt sett at grunnen til at en virksomhet investerer millioner hvert år i et produktteam er for å få en form for avkastning, er viktig. Det hjelper oss å styre produktet og prioriteringene våre, og det er noe du som tech lead tar del i.
«Produkteieren er død, lenge leve produktlederen!»
Ryggraden i smidig er kontinuerlige leveranser
Har man ikke en teknisk rigg som gjør at man kan levere små inkrementer av kode, blir jobben med å drive digital produktutvikling i team vanskelig. Store leveranser gir lengre feedbacksløyfer og øker risiko for tekniske feil. Du som tech lead er ansvarlig for at dette er på plass og velfungerende i ditt team. Det kan være lurt å måle over tid hvor gode man er på kontinuerlige leveranser med f.eks. DORA-metrikker.
Du som tech lead må klare å balansere risikoen teamet tar på seg i form av f.eks. retningslinjer for automatisert testing versus konsekvensen av at det faktisk skjer feil. Skal man bruke mye tid og penger på å vedlikeholde tester, eller er ledetiden på å fikse noe såpass lav at vi tåler den lille tiden det tar å lansere en fiks?
Teknikker som funksjonsbrytere for å kunne produksjonssette kode som er avskrudd for brukeren er også risikodempende, og jeg vil si avgjørende, for å kunne levere ofte nok. Du bør også dyrke psykologisk trygghet i form av at alle utviklerne tør å si ifra hvis de gjør eller oppdager feil uten at enkeltindivider får skylda. For å øke det kollektive eierskapet til koden, samt få ned risiko for feil, er fagfellevurderinger og parprogrammering gode verktøy. Jobber man mer sammen er det også mer naturlig å eie feil som skjer sammen som team.
Flytt fokuset fra å levere oppgaver til effekt
Et poeng med en transformasjon til produktmodellen er det å gå fra å levere “output” til “outcome”, altså fra å fokusere på leveransen i seg selv til det å oppnå reell effekt. Når funksjonalitet går i produksjon er det fortsatt bare en antagelse om at dette er noe som gir verdi.
Derfor trenger vi effektmåling. Vi må vite at det vi leverer har en effekt. Hvis ikke må vi enten iterere på det, eller tørre å ta det bort. Kode som ingen bruker eller ikke gir verdi er en ren forvaltningskostnad og kognitiv last for utviklerne.
En av de viktigste tingene en tech lead kan gjøre er å coache utviklerne i å slutte å bry seg om “output”, og begynne å bry seg om “outcome”. Det er effekten vi skaper i teamet som er viktig, ikke teknologien eller kode i seg selv. Erfaringsmessig er dette en utfordring fordi mange av oss rett og slett er veldig glad i å kode!
– Møter er en trussel mot effektivitet
Hvordan måler vi effekt?
I praksis så betyr dette at teamet ditt trenger både kvantitativ måling og kvalitativ innsikt i hvordan produktet brukes. Hva gjør brukerne og hvorfor gjør de det de gjør?
Når man først slipper et produkt til omverdenen er risikoen størst for at produktet ikke treffer, men du er også i en god posisjon for å raskt validere dette fordi brukergruppen din er liten og teamet kan, forhåpentligvis, snakke direkte med denne. Etterhvert som produktet skalerer er ikke denne form for kvalitativ innsikt nok alene. Du må fortsatt ha kontinuerlige kvalitative kanaler for å vite hvorfor brukerne gjør som de gjør, men du trenger hjelp til oversikt over hvordan produktet ditt brukes.
Du trenger et verktøy for kvantitativ måling. Eksempler på dette er Mixpanel og PostHog. Dette er litt omfattende å få satt opp, men hovedutfordringen ligger i å få dette til å bli en integrert del av utviklingsløpet.
Måling er helt essensielt for å vite hvordan produktet brukes, og kan ikke være kakepynt man strør oppå senere. Måling må være en del av Pull Request-en sammen med resten av funksjonaliteten, og burde påpekes i fagfellevurderinger på lik linje med sikkerhet eller universell utforming.
Klarer man å få til denne holdningsendringen vil du se gevinster i form av måten man angriper nye løsninger. “Hvordan kan vi isolert sett måle at denne endringen vi foreslår nå har en effekt?” Når vi begynner å stille oss dette spørsmålet blir det plutselig mye enklere å sette omfang på det vi tenker å lage. Da er effektmåling sentral i både produktutforskningen og leveransen, og man vil kjenne seg mye tryggere i videre prioriteringer når de er drevet av data og ikke magefølelse.
Verktøy som gir innsikt i hvordan produktet brukes øker også interessen for hva som skjer etter noe har gått i produksjon. Det muliggjør at man kan validere at funksjonalitet hadde den effekten som man antok før man bygget den, og samtidig kan man da koble disse effektene teamet skaper og effektene virksomheten er opptatt av.
Eksperimenter — hvor er neste klump med verdi?
Digitaliseringen har kommet dit at de umiddelbare gevinstene allerede er hentet ut, og det blir mer og mer usikkert hvor nye gevinster ligger. De tingene vi nå gjør med teknologi er vanskeligere og mange nivå over å “sette strøm på papir” som vi gjorde i begynnelsen.
Den gode nyheten er at måten vi jobber på i produktmodellen setter oss i en mye bedre posisjon for å faktisk finne neste klump med verdi. Her er eksperimenter en sentral teknikk.
Eksperimenter muliggjør at vi kan prøve om noe gir effekt eller ikke, men dette fordrer at man har effektmåling på plass. Har du måling på plass i form av et verktøy, så har du typisk dashboard og ulike rapporter som gjør at du vet “baseline” på produktet ditt, og dermed kan bruke eksperimenter for å flytte ulike metrikker mot det du ønsker å oppnå. A/B-testing er f.eks. en slik teknikk.
«Så, kjære tech lead: Jeg håper du innser at du er essensiell i transformasjonen til produktmodellen.»
Produktmodellen er nøkkelen til innovasjon
Du som utvikler og tech lead sitter nærmest fagfeltet teknologi som tross alt er premisset for hva som er mulig å få til. Dermed er du også en nøkkelperson i å drive innovasjonen for ditt produkt. Dette er det viktig at du både dyrker hos de andre utviklerne, og skaper rom til deg selv og dem, slik at de kan utvikle seg faglig. Flinke folk motiveres av å bli bedre!
Det å ha motiverte utviklere er noe av det lureste du investerer i som tech lead og leder, fordi det indirekte er nøkkelen til at produktet ditt lykkes i fremtiden. Det krever at du prioriterer aktiviteter som gjør at teamet ditt jobber med produktutvikling på en god måte, som f.eks. å introdusere et måleverktøy, eller introdusere en teknisk rigg for eksperimenter. Dette er sjelden noe produktlederen din kommer til å prioritere inn i teamet, og dermed faller ansvaret på deg.
Så, kjære tech lead: Jeg håper du innser at du er essensiell i transformasjonen til produktmodellen. Du er en leder. Teamet ditt trenger deg, produktlederen din trenger deg, designeren din trenger deg, og utviklerne dine trenger deg.
Bruk tid på å løfte og motivere utviklerne dine ved å ansvarliggjøre dem for effekten av det de gjør. Ta de med på problemløsningen og ikke bare gi de oppgaver. Vis at god produktutvikling er mer enn å kode, det handler om å skape verdi og effekt for ekte brukere.
