Når vi snakker om teknisk gjeld, handler samtalen ofte om dårlig kode, utdaterte dependencies eller arkitektoniske snarveier. Det høres ut som et rent teknisk problem. Men realiteten er at teknisk gjeld sjelden oppstår i isolasjon – den vokser fram i team som mangler felles eierskap, klare beslutninger eller gode vaner.
Som tech lead er det fristende å tro at løsningen ligger i refaktorering eller verktøy. Men for å redusere teknisk gjeld over tid, må vi begynne med å se på årsaken – og den er som regel menneskelig.
Når teknisk gjeld er et symptom på teamatferd
Gjeld i kodebasen kommer sjelden fra én enkelt dårlig beslutning. Ofte oppstår den gradvis, som et resultat av manglende koordinering, pressede leveranser og fravær av felles forståelse.
Typiske symptomer:
- Flere utviklere løser samme problem på ulike måter
- Midlertidige løsninger blir permanente
- Manglende eierskap til struktur, navngivning, API-kontrakter eller logging
- TODO-kommentarer som sprer seg i kodebasen uten eierskap eller kontekst
- Uklare eller uuttalte beslutninger – ingen vet hvorfor ting ble gjort slik
Når team ikke tar seg tid til å evaluere praksisene sine, bygger det seg opp uoversiktlig kompleksitet over tid.
Teknisk gjeld er ikke alltid negativt
Gjeld kan også være et strategisk valg. I noen situasjoner er det helt riktig å prioritere fart fremfor struktur – så lenge det gjøres bevisst og med en plan for tilbakebetaling.
Eksempel 1:
Et team integrerer mot et API som fortsatt er under utvikling. I stedet for å lage en generell løsning for mapping og feilhåndtering, velger de å hardkode logikken midlertidig for å kunne jobbe parallelt. Det gir rask verdi, og forbedringene kommer senere – basert på reelle behov.
Eksempel 2:
Et startup-team lanserer en MVP til investorer. For å møte fristen kutter de noen hjørner i arkitekturen, vel vitende om at det må ryddes opp senere. Demoen gir finansiering og retning – og gjør gjelden verdt det.
Forskjellen mellom nyttig og farlig teknisk gjeld handler om bevissthet og eierskap. Har teamet kontroll – eller kontrollerer gjelden teamet?
De vanligste typene teknisk gjeld – og hva du bør prioritere
Å identifisere hvilken type teknisk gjeld dere står overfor, er avgjørende for å prioritere riktig. Ikke all gjeld haster like mye, og ikke alt bør løses først. Under finner du noen typiske former for teknisk gjeld – og når de bør adresseres:
- Kodedesign og struktur
Kjennetegn: duplikasjon, monolittisk logikk, ikke-testbar.
Prioriter når: det hindrer utvikling, skaper bugs eller bremser teamet. - Avhengigheter og biblioteker
Kjennetegn: utdaterte dependencies, deprecated API-er.
Prioriter når: det blokkerer oppdatering eller skaper sårbarheter. - Sikkerhetsgjeld
Kjennetegn: manglende inputvalidering, hardkodede secrets, usikrede biblioteker.
Prioriter når: alltid – dette er alvorlig risiko. - Build- og deploy-prosess
Kjennetegn: manuelle steg, ustabile pipelines.
Prioriter når: det gir treg, risikabel eller ustabil leveranse. - Testing
Kjennetegn: lav testdekning, flaky tester, ingen automatisering.
Prioriter når: teamet mister tillit til endringer og slipper gjennom feil. - Kunnskapsgjeld
Kjennetegn: TODOs uten kontekst, manglende dokumentasjon, dårlig commit-hygiene.
Prioriter når: nye utviklere onboardes, eller ved høy rotasjon i teamet.
Sikkerhetsgjeld – den farligste og mest neglisjerte formen
Mange team tar lett på sikkerhet i starten – bevisst eller ubevisst. Men sikkerhetsgjeld bygger seg raskt opp og er vanskelig å oppdage uten gode rutiner.
Eksempler:
- Tokens eller passord hardkodet i kildekoden
- Inputvalidering som er fraværende eller mangelfull
- Bruk av usikrede tredjepartsbiblioteker med kjente sårbarheter
En god tech lead sørger for at:
- Dependency scanning og CVE-varsler er på plass (f.eks. Dependabot, Snyk)
- Secrets lagres sikkert (f.eks. Key Vault, AWS Secrets Manager)
- Sikkerhet er en naturlig del av code review og teststrategi
Tech leadens rolle: Fra ryddegutt til kulturbærer
Teknisk gjeld er aldri bare et resultat av valg som ble tatt – det handler om praksisene som får utvikle seg uadressert. Her er hvorfor tech leadens rolle er helt sentral:
1. Synliggjør det ingen sier høyt
Teknisk gjeld forsvinner ikke av seg selv. Sett det på agendaen i retrospektiver, sprintplanlegging og estimering – og sørg for at teamet har et språk for å snakke om det.
2. Etabler balanse mellom fart og kvalitet
Hjelp teamet å se når det er greit å ta snarveier – og når det ikke er det. En god tech lead skaper trygghet for å si "dette må vi gjøre riktig".
3. Bygg inn forbedring i hverdagen
Unngå skippertak. Gå foran som et godt eksempel og gjør små forbedringer når du først er i koden – boy-scout-regelen i praksis.
4. Gjør teknisk gjeld forståelig for beslutningstakere
Teknisk gjeld er ofte usynlig for de som prioriterer arbeid. Det er din jobb å forklare hvordan dårlig testdekning, manuell deploy eller hardkodede secrets koster tid, penger og trygghet – og hvorfor det lønner seg å rydde. Bruk konkrete eksempler, målbar effekt og integrer opprydding i demoer.
Hva gjør du når du arver store mengder gjeld?
Når du kommer inn i et prosjekt med mye teknisk gjeld, kan det virke overveldende. Ikke fall for fristelsen til å rydde alt med én gang.
- Observer først – rydde senere
Bruk første uker på å lære, ikke forbedre. Forstå hva som fungerer og hvorfor ting er som de er. - Forbedre gjennom faktisk arbeid
Løs bugs og bygg ny funksjonalitet, men gjør det litt bedre hver gang. Bruk boy-scout-regelen – etterlat koden litt bedre enn du fant den. - Lag oversikt, men prioriter strengt
Kartlegg hva som faktisk skaper problemer – og ignorer resten inntil videre. - Vis frem fremgang
Snakk om opprydding i demoer. Vis effekt, ikke bare innsats.
Verktøy og praksis som hjelper
- Retrospektiver som inkluderer tekniske frustrasjoner
- TDRs (Technical Decision Records) for å forklare og huske valg
- Pull Request-maler med spørsmål om mønstre og gjeld
- Statisk analyse og sikkerhetsskanning som gjør problemene synlige
- Tydelige commit-meldinger og små, meningsfulle commits gjør det mulig å forstå historikk og redusere kunnskapsgjeld
Avslutning: Gjeld er kultur, ikke bare kode
Teknisk gjeld oppstår ikke bare i kode – den vokser ut av menneskelige valg, strukturer og vaner. Som tech lead har du mulighet til å påvirke langt mer enn kodekvalitet. Du kan forme en kultur der bevissthet, eierskap og kontinuerlig forbedring er en del av hverdagen.
Du trenger ikke å fjerne all teknisk gjeld. Men du må sørge for at teamet har kontroll – og verktøyene og støtten til å håndtere den før den blir kritisk.
For gjeld er uunngåelig. Kaos er det ikke.
