De første 90 dagene som ny tech lead

Presset som velter starten for mange nye tech leads

Du har fått rollen. Kanskje i et nytt team, kanskje i ditt eget, forfremmet internt. Uansett kjenner du presset:

Forventningen om å vise noe. Raskt.

Det presset kan velte starten for en tech lead. De første 90 dagene handler nemlig ikke om å levere endring, men om å gjøre deg i stand til å levere den – senere, med teamet i ryggen.

Jeg har skrevet om prinsippene før, i Det tause ansvaret og Hvordan evaluere og modernisere en eksisterende kodebase. Dette er den praktiske utgaven. Fase for fase.

Dag 1–30: Observer

Din viktigste jobb den første måneden: forstå. Ikke forbedre.

Jobb som en vanlig utvikler. Plukk bugs fra backloggen. Løs dem slik teamet løser dem i dag, selv når du ser en «bedre» måte. Du lærer mer om et system av å fikse virkelige bugs enn av å lese dokumentasjonen alene.

Les pull requests. Ikke bare koden – samtalene. Hvem kommenterer, hvem blir hørt, hva diskuteres – og hva glir gjennom uten at noen sier noe? PR-historikken er teamets ærligste selvbiografi.

Ha én-til-én med alle. Ett spørsmål betyr mest: «Hva ville du endret hvis du kunne?» Svarene gir deg både kartet og alliansene.

Noter, men ikke del. Alt du reagerer på, skriv det ned. Ikke si det – ikke ennå. Mange av reaksjonene dine kommer til å vise seg å skyldes mangel på kontekst.

Dag 31–60: Kartlegg

Nå har du følelsen. Tid for struktur.

Teknisk: stack, versjoner, pipelines, testdekning, sikkerhetspraksis. Sikkerhetsfunn er unntaket fra alt annet i denne artikkelen: de eskaleres med en gang, uansett hvilken fase du står i.

Strukturelt: modulgrenser, avhengigheter, dataflyt, hvor standardene spriker.

Sosialt: hvem eier hva, hvor friksjonene bor, hvilke deler «ingen tør å røre» – og hvorfor.

For meg er sosial kartlegging kanskje det viktigste av de tre, og det team oftest gjør minst systematisk. Kodens tilstand er nesten alltid et avtrykk av teamets historie. Forstår du historien, forstår du koden.

Noen ganger var koden stygg etter alles målestokk, men ingen rørte den fordi den virket. Andre ganger syntes jeg noe var stygt, mens personen som eide det mente noe annet. I ett tilfelle hadde en utvikler en egen NotEquals-funksjon fordi ! ble ansett som lite synlig i C#. Først tenkte jeg: seriøst? Så fulgte mange diskusjoner om hva som faktisk gjør kode lesbar, og om lesbar er det samme som pen. Finn ut hvorfor koden ser slik ut, før du bestemmer at den er feil.

Test forståelsen din underveis. «Jeg har inntrykk av at X. Stemmer det?» Du bygger tillit ved å vise at du prøver å forstå, ikke ved å ha rett.

Dag 61–90: Presenter og forankre

Nå – og først nå – deler du.

Presenter observasjoner, ikke problemer. «Her er det jeg ser. Stemmer det?» Ikke: «Her er alt som er galt.» Samme funn, helt forskjellig mottakelse.

La teamet prioritere. Du har kartet, men teamet kjenner terrenget. Spør: «Hva av dette gjør mest vondt i hverdagen?» Det de peker på, er der du starter, ikke der du selv er mest ivrig.

Velg én synlig forbedring. Ikke ti. Én. Gjennomfør den sammen med teamet, vis den fram, og gi dem æren. Den første forbedringen setter malen for alle de neste, så la den være liten nok til å bli ferdig og synlig nok til at noen merker det.

Begynn å lukke spørsmål. Rundt dag 90 har du tillit nok til å ta den delen av rollen som handler om beslutninger som må tas. Ikke før.

De tre feilene nesten alle gjør

1. Den tidlige refaktoreringen. Du ser noe stygt i uke to og «fikser» det. Teknisk sett er det en forbedring. Relasjonelt er det en krigserklæring, for noen på teamet skrev den koden, og de vet hvorfor den er som den er. Spør før du rører den.

2. Å sammenligne med forrige sted. «Der jeg jobbet før, gjorde vi…» Én gang er et perspektiv. Tre ganger er en fornærmelse. Teamet hører ikke erfaring – de hører at de ikke er gode nok.

3. Å love oppover før du har forankret nedover. Ledelsen vil ha en plan i uke tre. Motstå fristelsen til å love konkrete endringer du ennå ikke har diskutert med teamet. En plan teamet ikke kjenner seg igjen i, er ikke en plan, men en fremtidig konflikt.

Du bygger bare én ting

De første 90 dagene bygger du én ting fremfor alt: tillit. Alt annet – standardene, retningen, forbedringene – kommer etterpå, og kommer lettere, fordi tilliten bærer det.

Det føles langsomt mens du står i det. Det er likevel den raskeste veien som finnes, og alle snarveiene er lengre.