Hvordan håndtere uenighet i teknologivalg som tech lead

Uenighet i teknologivalg er uunngåelig. Det er faktisk et sunnhetstegn, et tegn på at teamet bryr seg, at folk har erfaring og at de tenker selvstendig. Men for en tech lead er slike situasjoner krevende. Når valget står mellom Refit og HttpClient, mellom Entity Framework og Dapper, eller mellom å bygge selv og kjøpe ferdig, er ikke målet å vinne diskusjonen. Det er å bygge retning, trygghet og felles eierskap.

Uenighet er ikke konflikt før du gjør den til det

Uenighet i seg selv er konstruktivt. Konflikten oppstår først når prosessen oppleves urettferdig. Når noen ikke blir hørt, eller når beslutningen virker tilfeldig. Mange tekniske konflikter handler derfor mindre om kode og mer om tillit.

Som jeg skrev i Det tause ansvaret: ledelse i utvikling handler sjelden om teknologi alene, men om hvordan vi skaper trygghet rundt beslutninger. Først når folk opplever at prosessen er rettferdig, tåler de utfallet også når de er uenige.

Et nyttig første steg er å klargjøre hva uenigheten egentlig handler om:

• Funksjonelt: ytelse, minnebruk, sikkerhet
• Operasjonelt: vedlikehold, observability, CI/CD
• Menneskelig: kompetanse, komfortsone, eierskap

Når du skiller disse lagene, ser du raskere hva som faktisk må løses.

Bruk struktur, ikke autoritet

En vanlig feil tech leads gjør, er å «bestemme» altfor tidlig. Autoritet er en dårlig erstatning for prosess. Det du trenger er struktur, en måte å veie argumenter på uten at diskusjonen blir personlig.

To verktøy fungerer spesielt godt:

1. TDR – Technical Decision Record

I Hvordan etablere tekniske standarder som faktisk etterleves skrev jeg om hvordan TDR-er gir en enkel og etterprøvbar beslutningsstruktur. Det samme gjelder her: poenget er ikke dokumentet, men rettferdigheten i prosessen.

2. Design review

Et kort, fokusert møte der alle relevante stemmer får legge frem argumenter basert på erfaring og fakta. Din oppgave er å balansere samtalen, ikke å konkludere for tidlig. Eierskap skapes gjennom involvering.

Fra uenighet til forankring

Når diskusjonen blir tett, hjelper det å jobbe i tre steg:

1. Forstå – ikke for å avsløre svakheter, men for å forstå prioriteringene bak standpunktet.
2. Synliggjør kriteriene – hva teller faktisk? Kompleksitet? Stabilitet? Observability?
3. Beslutning med retning – forklar hvorfor valget ble tatt og hva det betyr fremover.

En beslutning uten kontekst føles som et diktat. En beslutning med retning føles som ledelse.

Når du ikke får enighet

Noen ganger kommer du ingen vei. Da handler det om å balansere fremdrift og forankring.

Et nyttig prinsipp er:

“Dissent, then commit.”
Alle får si sitt. Når beslutningen først er tatt, står man samlet.

Et annet grep er å sette et revisjonspunkt:

“Vi velger Refit nå, og evaluerer etter første release.”

Da blir beslutningen læringsbasert, ikke ideologisk.

Når du blir oppfattet som dogmatisk

For teknisk sterke leads kan presisjon i språk oppleves som rigiditet. Du prøver å være tydelig, men blir tolket som bastante eller styrende. Det skjer ofte når du sitter med mer kontekst enn resten av teamet.

Når det skjer, er det nyttig å minne om to ting:

• Det finnes sjelden ett riktig svar. De fleste teknologivalg er avveininger, ikke fasiter.
• Formålet er ikke å vinne, men å belyse konsekvenser.

Små formuleringer gjør stor forskjell:

• «Dette er én tilnærming. Hva tenker dere?»
• «Jeg heller mot dette, men la oss teste kriteriene sammen.»
• «Erfaringen min peker hit, men det er ikke den eneste riktige løsningen.»

Språket ditt kan avgjøre om du oppfattes som dogmatisk eller som tydelig.

La de som faktisk gjør arbeidet eie beslutningen

En moden tech lead vet når man skal slippe til andre. Når en utvikler eller et lite team skal bygge og vedlikeholde funksjonaliteten, er det ofte riktig at de tar den endelige beslutningen.

Din rolle er da å:

• synliggjøre risiko og avhengigheter
• sikre konsistens i systemet
• tilby erfaring, ikke føringer
• støtte dokumentasjon og forankring

Eierskapet bør ligge hos dem som skal leve med koden. Det skaper trygghet og stolthet, og ofte bedre løsninger.

Som jeg skrev i Teknisk gjeld som et teamfenomen: tekniske valg er også relasjonelle. De handler om samspill, ikke bare arkitektur.

Evolusjon, ikke revolusjon. Særlig når nye utviklere (eller ny tech lead) kommer inn

Når nye utviklere eller en ny tech lead kommer inn i et etablert team, blir systemet sett med helt nye øyne. Det fører ofte til gode spørsmål:

• «Hvorfor gjør vi det slik?»
• «Har dere vurdert denne tilnærmingen?»
• «Hva var begrunnelsen for dette valget?»

Det kan oppleves som kritikk, men intensjonen er som regel konstruktiv: å forstå, å dele erfaringer og å identifisere forbedringsmuligheter. Det er her linjen må være tydelig: Idéer er ønsket. Revolusjon er ikke det.

Evolusjon handler om:

• å forstå konteksten før man foreslår endringer
• å forbedre uten å avinstallere teamets identitet
• å bygge videre på det som fungerer
• å tilføre nye perspektiver uten å undergrave gamle valg

For å få alle på samme side må teamets teknologiske reise bli eksplisitt:
Hvorfor ting er som de er.
Hvilke kompromisser som ligger bak.
Hva teamet har prøvd tidligere.
Hva som faktisk bør forbedres nå.

Når nye utviklere, eller ny tech lead, forstår historien blir det lettere å foreslå retning.
Når teamet forstår intensjonen bak spørsmålene, tåler de endringer.
Når begge deler er synlig, blir nye impulser en katalysator og ikke en trussel.

Forbedring starter med idéer. Idéer starter med nye øyne. Men evolusjon krever at nye øyne kobles til teamets virkelighet, ikke bryter med den.

Til slutt: Samarbeid slår rett svar

Det viktigste i et utviklingsteam er ikke perfekte teknologivalg, men at de tas sammen på en måte som bygger tillit, retning og fremdrift.

Godt samarbeid tåler feil valg. Selv riktige valg faller sammen hvis samarbeidet rakner.

Når teamet opplever:

• at uenighet er trygt
• at beslutninger er rettferdige
• at ansvar er distribuert
• at prosessen er transparent

da forsvinner mye av det som kan oppleves som dogmatisme. Og du står igjen med det som faktisk betyr noe: et team som drar i samme retning - ikke fordi alle er enige, men fordi alle er trygge.