Det tause ansvaret: Å holde standardene samlet som tech lead

Innledning

I programvareutvikling bærer enhver tech lead på et ansvar som sjelden står tydelig i stillingsbeskrivelsen. Å sikre at tekniske standarder er konsistente, forstått og fulgt. På papiret høres det enkelt ut. Du skal definere teknologistakken, dokumentere mønstrene og lede teamet. Men enten du går inn i et nytt prosjekt eller arver en eldre løsning, vet du at virkeligheten er langt mer krevende.

Denne artikkelen ser på utfordringene med å etablere og bevare gode standarder, og hvordan den virkelige jobben som tech lead handler mindre om å bestemme og mer om å fasilitere, lytte og utvikle seg sammen med teamet.

Når alt er nytt eller ser sånn ut

Nye prosjekter gir ofte inntrykk av at man kan gjøre alt riktig fra start. Alt skal etableres – teknologistakk, arkitektur og beste praksis. Alt kan dokumenteres, og teamet kan følge en klar sti. Høres ideelt ut, ikke sant?

Men i praksis er det sjelden så enkelt.

Nye prosjekter betyr som regel også nye team. Ofte med en miks av juniorutviklere fra kunden og noen innleide konsulenter med varierende erfaring. Alle tar med seg egne preferanser og sterke meninger om hva som er «best practice». Det er her utfordringene starter.

Plutselig har alle på seg rockstar-modus. Noen vil ha Clean Architecture, andre foretrekker noe enklere. Noen foreslår å bruke MediatR for intern kommunikasjon mellom komponenter, andre foretrekker direkte tjenestekall. Refit, et verktøy for å lage API-klienter automatisk, eller bruke HttpClient manuelt? Åpen kildekode eller kommersielle løsninger? Nytt og spennende, eller stabilt og velprøvd?

Plattformen som skulle være tom, blir et minefelt. Det er her tech lead virkelig må trå til.

Fasilitér, ikke diktér

Det kan være fristende å bare bestemme og si: «Slik gjør vi det». Er ikke det derfor man er lead? I teorien kanskje. I praksis, den raskeste veien til motstand.

En god tech lead kommer ikke inn som en diktator med en «one true stack». Du er der for å hjelpe teamet med å bli produktivt, levere med kvalitet og føle eierskap. Du skal ikke preke – du skal samarbeide.

Det viktigste du kan gjøre i starten av et prosjekt er enkelt: Lytt.

Definer rammene – hva er fleksibelt, og hva er ikke. La teamet diskutere og velge innenfor det rommet. La dem prøve. Vær med i samtalen, men ikke dominer den. Når retningen begynner å ta form, dokumentér og stabiliser. Da får du eierskap, ikke bare etterlevelse.

Eldre prosjekter: Evolusjon, ikke revolusjon

Bildet er helt annerledes i etablerte prosjekter. Her er det ikke du som legger første stein – du trer inn i en struktur bygget over år, av mange forskjellige folk. Noen team bruker AutoMapper (for å mappe objekter automatisk), andre foretrekker manuell koding. Én modul har globale feilbehandlere, en annen logger alt manuelt.

Det finnes standarder, men de er fragmenterte. Den største feilen du kan gjøre her er å prøve å «fikse» alt med én gang. Tenk deg at noen kommer hjem til deg og begynner å ommøblere, male om og kaste favorittstolen din – uten å spørre. Du ville ikke tatt det lett. Det gjør ikke teamet heller.

I stedet bør du forstå hvorfor ting er som de er. Mye i gamle systemer er resultat av faktiske kompromisser og tekniske begrensninger. Respekter det før du prøver å forbedre det.

Bygg tillit før du leder endring

I etablerte prosjekter bør du begynne som en helt vanlig utvikler. Plukk noen bugs (feil) fra backloggen. Ikke refaktorer. Ikke skriv alt på nytt. Løs dem slik teamet gjør det i dag. Lær deg systemet – både teknisk, forretningsmessig og sosialt.

Når du forstår hvordan ting henger sammen, vil du også se hvor standardene spriker. Da kan du begynne å jobbe for samkjøring, uten å forstyrre leveranseflyten.

Slik gjør du det:

Kartlegg det som faktisk finnes.
Dokumenter hvordan ting faktisk gjøres, ikke bare det som står i gamle wiki-sider. Se på kodebasen: struktur, navngivning, teststrategier, logging, bygg og deploy.
Sett midlertidig brems på nye ideer.
La teamet jobbe som før en liten periode, men gjør det klart at du tar en runde med å samle og analysere det som er.
Presenter med respekt.
Når du har oversikten, del funnene med teamet. Ikke som problemer, men som observasjoner. Spør: Stemmer dette? Ønsker vi å fortsette slik, eller kan vi forenkle og enes om én retning?
La teamet eie standardene.
Du kan lage et forslag, men teamet må få eie det. La dem utfordre det, forbedre det. Det handler ikke om din preferanse. Det handler om hva som fungerer i praksis.
Dokumentér og forankre i kodebasen.
Når standardene er vedtatt – dokumentér dem. Ikke i en glemt side på Confluence, men rett i prosjektet: Maler, eksempler og genererte moduler. Gjør det lett å gjøre riktig.

Derfor betyr det noe

Gode standarder handler ikke bare om struktur og orden. De påvirker:

Hvor raskt nye utviklere kommer inn
Hvor trygt teamet kan levere funksjonalitet
Hvor enkelt det er å rette feil
Hvor robust systemet er når det vokser

Og viktigst av alt: Standarder påvirker teamfølelsen. Et team som jobber etter felles mønstre, deler også ansvar. Et team som diskuterer hver minste tekniske detalj, mister tempo og motivasjon.

Som tech lead er ikke målet ditt å vinne diskusjoner. Målet er å skape struktur slik at diskusjonene fører frem.

Avslutning: Den stille påvirkningen

De beste tech leadsene er sjelden de som roper høyest. De er de som lytter, observerer og vet når de skal snakke – og når de skal holde munn.

Standarder lager ikke seg selv. Og de håndhever seg i hvert fall ikke selv. De formes av mennesker, og fungerer bare når folk faktisk tror på dem. Den tilliten får du ikke med autoritet, du får den med samarbeid.

Uansett om du bygger nytt eller går inn i noe gammelt blir påvirkningen din som lead målt i hvordan teamet jobber sammen, hvor trygt de leverer og hvordan prosjektet utvikler seg over tid.

Det er dette tause ansvaret vi bærer og det er det som skiller en dyktig utvikler fra en god tech lead.

‍