Slutt å skrive kode: Hvorfor din viktigste PR er den du aldri åpner
En av de vanligste feilene ferske tech leads gjør, er å fortsette å være teamets beste utvikler. Hver time du bruker på å skrive kode selv, er en time du ikke bruker på det bare du kan gjøre: holde systemet og teamet samlet.
La meg provosere først
Du ble tech lead fordi du var god til å skrive kode.
Nå er det den ferdigheten som står i veien for deg.
Ikke fordi kode ikke er viktig. Men teamet ditt har mange som kan skrive kode, og bare én som kan gjøre jobben din. Hver gang du velger tastaturet, velger du bort noe annet: reviewen som ventet, spørsmålet som sto åpent, standarden som sprakk i det stille.
Regnestykket ingen viser deg
En god utvikler produserer verdi lineært: én time inn, én times arbeid ut.
En god tech lead produserer verdi multiplikativt: én time brukt på å lukke en beslutning kan spare utviklere for en uke med gjetting. Én time brukt på en TDR kan forhindre måneder med gjentatte diskusjoner. Én time brukt på å avverge divergens kan spare måneder med opprydding. Tenk på dette som en modell og ikke en formel – tech leadens påvirkning kommer fra å fjerne blokkeringer og skape forutsetninger for at andre kan bevege seg.
Som jeg skrev i Beslutningslatens: team bremses sjelden av manglende kode. De bremses av åpne spørsmål. Og åpne spørsmål lukkes ikke av at du sitter med hodetelefoner og skriver.
«Men jeg mister troverdigheten hvis jeg ikke koder!»
Innvendingen er reell – og den er halvveis riktig.
Du skal være i koden. Lese PR-er. Plukke en bug innimellom. Kjenne systemet i fingrene. En tech lead som ikke lenger forstår kodebasen, kan ikke sette rammer for den.
Men det er forskjell på å være i koden og å være flaskehalsen i den. Testen er enkel: hvis en kritisk oppgave bare kan løses av deg, har du ikke bevist din verdi. Du har avslørt en risiko.
Den viktigste PR-en
Så hva er den viktigste pull requesten din?
Det er den du ikke åpner, fordi du i stedet:
- lot en utvikler eie løsningen, med deg som sparringspartner
- brukte tiden på å gjøre kvalitetsforventningene tydelige
- skrev prinsippet ned, slik at spørsmålet aldri stilles igjen
Det føles mindre produktivt. Det er det motsatte.
Hva klarer teamet uten deg?
Du ble ikke tech lead for å være teamets beste utvikler. Du ble det for å gjøre teamet bedre enn sin beste utvikler.
Legg fra deg tastaturet. Litt. Det er den vanskeligste refaktoreringen du kommer til å gjøre.