Alv Logo
Del

6 tips for å lykkes som Techlead

...og typiske feil mange gjør i rollen.

Rollen som Techlead er ganske ullen, og det virker ofte tilfeldig hvilket ansvar som hører til stillingen. Mange tenker på Techlead kun som en flink utvikler, mens Techleadene selv ofte tenker på seg selv som et teknisk orakel som bør bestemme det meste. Begge disse ytterpunktene står i veien for god verdiskaping. 

Det som trengs i Techleadrollen er en person som tar ansvar, har kontroll på kvalitet og prosess, forstår interessenters ønsker og dermed får ting gjort! 

Litt lenger ned i dette innlegget vil jeg liste opp 6 punkter jeg mener alle Techleads bør prioritere i utviklingsprosjekter for å gjøre en god jobb. Først må vi imidlertid snakke litt mer om Techleadrollen.

Som Techlead er det ikke hvor mye du selv klarer å produsere som teller, men heller hvor god du er til å fjerne blokkeringer og få resten av teamet til å levere godt. Derfor er det viktig å velge en Techlead som er god til å spille på lag med andre og som kan litt om mye. Techlead er ikke hovedansvarlig for verken interessenter, overordnet prosjekt, eller arkitektur, men er heller det tekniske bindeleddet mellom alle disse.

I perioder må du kjempe mot utvikleres evige ønske om den perfekte koden.

Som Techlead er det din jobb å passe på at teamet holder en god balanse mellom smidige, raske leveranser og pleiing av teknisk gjeld. Dette er lettere sagt enn gjort, og krever både erfaring og innsikt. I perioder må du kjempe mot utvikleres evige ønske om den perfekte koden. Andre ganger er kampen helt motsatt og du må fokusere på teknisk gjeld og feilretting. Her er det viktig å kjempe mot interessenter for å få tiden du trenger til å stabilisere og automatisere, i stedet for å komme opp med enda mer ny funksjonalitet.

Når du ikke kjemper for saker, skal du også være prosjektleder sitt tekniske alibi inn i viktige møter. Disse møtene kan ofte føles unødvendige, der du sitter som eneste tekniske person og som regel bare lytter. Men gjort riktig, er dette utrolig viktig bruk av tid. Gjennom alle disse møtene, får du god innsikt i hva som kreves og hva som beveger seg i organisasjonen og rundt prosjektet. Denne innsikten tar du med deg tilbake til teamet, slik at de også holdes oppdaterte.

For å si det enda strengere, kan jeg garantere at du kommer til å bli flaskehalsen (..)

Når du skal gjøre alle disse oppgavene, er det fort gjort å ende opp som teamets største flaskehals, i stedet for den ressursen du skal være. For å si det enda strengere, kan jeg garantere at du kommer til å bli flaskehalsen, dersom du ikke aktivt jobber for å ikke bli det! Tro meg, fordi jeg har ofte prioritert feil. 

Dette bør du prioritere

Med bakgrunn i min erfaring og mine feil, har jeg derfor seks tips til hva du bør prioritere som Techlead i utviklingsprosjekter. 

1. Sett av minst 40% til å jobbe med utviklingsoppgaver. 

40% er en hårfin balanse. Blir det særlig mindre enn det, blir det fort ingenting, og blir det mer enn det, blir det ikke tid igjen til alle andre nødvendige oppgaver. I perioder hvor alt går på skinner vil du selvsagt kunne kode mer, men det er spesielt i perioder med mye å gjøre, at det er viktig å ha dette tipset i bakhodet. 

2. Dokumenter og del de viktigste prinsippene du ønsker teamet skal jobbe etter. 

Din oppgave som Techlead er å sørge for at teamet og interessenter, vet hva teamet ønsker å oppnå teknisk. Gjennom å dokumentere de tekniske prinsippene teamet jobber etter, trenger ikke du personlig å være til stede, når alle valg tas.

3. Be andre om å lage førsteutkast av løsninger, så kan du heller komme med erfaring og kompetanse for å optimalisere løsningenvidere. 

Som Techlead er en av dine viktigste oppgaver å skape eierskap og engasjement i teamet. Ved å la alle bidra til de tekniske løsningene, vil hver enkelt få et mye større eierskap til løsningene. Det er heller ingen tvil om at mange hoder tenker bedre enn ett, så ved å åpne for gode løsninger fra den enkelte, og heller se på deg selv som en dørvakt som skal sørge for at alt henger bra sammen, vil flere gode løsninger vil se dagens lys.  

4. Bli enig med prosjektleder om hvilke møter du må være med på, og hvilke møter som er rop-navnet-mitt-hvis-du-trenger-meg. 

En av de største farene for en Techlead er å drukne i møter. Når det skjer, blir alle punkter i denne lista nedprioritert og dermed gjennomført dårlig. Samtidig er møter viktig for en Techlead. Sørg derfor for å rigge deg slik at du både kan være tilgjengelig i møter når det er nødvendig, og kan jobbe med annet når det er mulig. Godt samarbeid mellom deg og prosjektleder er avgjørende her. 

5. Sett av tid til å par-programmere med teammedlemmer 

Du må finne tid til å sette deg ned med teammedlemmene og kode med dem. Særlig yngre utviklere. Hvis du ønsker å oppnå en helhetlig teknisk løsning som henger godt sammen, må du sørge for at alle i teamet har en felles forståelse og en felles tilnærming. 

6. Del på hvem som styrer retro, demo, drift og annet, fra sprint til sprint, slik at både kunnskap og arbeidsmengde fordeles i teamet. 

En viktig jobb som Techlead er å gjøre de andre i teamet bedre. Ved å fordele ansvar, i stedet for å ta alle oppgaver selv, oppnår du ikke bare å frigi litt mer av din egen tid. Du gir også andre muligheten til å lære, vokse og å engasjere seg. 

Oppsummering

Å være Techlead passer ikke alle. Samtidig finnes det mange utrolig flinke utviklere der ute som trigges av å effektivisere team og er villige til å kjempe for det! Hvis du er en slik person håper jeg denne bloggposten ga deg noen tips til hvordan du kan bli en god Techlead.

Hvis du ønsker å diskutere noe omkring Techlead-rollen eller annet innen utvikling, må du gjerne kontakte meg på lars@alv.no.

Lurer du på relatert til Techleadrollen eller utvikling generelt?

Ta kontakt med Lars Espen

Del
Les også
Les mer

Hvordan briljere på teknisk intervju

I denne bloggposter skriver jeg litt om hva som skiller en GOD og en OK utvikler og hvordan vi tester kandidater i Alv for å finne de riktige folkene.

Hvordan briljere på teknisk intervju

Systemutvikling
Lars Espen Nordhus - 11/12/2021
Les mer

Ytelse og kode: Fra 48 timer kjøretid ned til 10 minutter!

I første del av denne artikkelserien gikk vi gjennom minneproblemer og hvordan å håndtere det å gå tom for tråder eller sockets. Del to så på hvordan CPU- og I/O-begrensinger...

Ytelse og kode: Fra 48 timer kjøretid ned til 10 minutter!

Systemutvikling
Lars Espen Nordhus - 11/3/2020
Les mer

Ytelse og kode: Hvordan CPU- og I/O- begrensinger påvirker ytelsen

Dette er del to i en artikkelserie på tre deler om ytelse. Del en finner du her. Det er 15 år siden man gikk over til flerkjerneprosessorer i konsumentmarkedet. På tross...

Ytelse og kode: Hvordan CPU- og I/O- begrensinger påvirker ytelsen

Systemutvikling
Lars Espen Nordhus - 8/5/2020