Hvorfor onboarding‑beslutninger betyr mer enn kode. Teknisk gjeld blir ofte fremstilt som et rent teknisk problem. Vi snakker om kodekvalitet, forhastet arkitektur eller feil teknologivalg. Det er en behagelig forklaring, og noen ganger stemmer det. Men som regel er den ufullstendig.
I realiteten starter mye av den tekniske gjelden i organisasjoner ikke i koden i det hele tatt. Den oppstår langt tidligere, i onboarding‑fasen. Den kommer av uklare beslutninger, manglende eierskap og antakelser som aldri ble gjort eksplisitte. Når dette senere viser seg som det vi omtaler som «teknisk gjeld», er den reelle årsaken som regel både eldre og langt mer krevende å rette opp.
De fleste onboarding‑løp er bygget rundt et tydelig og forståelig mål: å få systemene i drift. Miljøer settes opp, integrasjoner kobles, brukere kan logge inn, og go‑live nås. Sett fra et tradisjonelt prosjektperspektiv ser dette ut som en suksess.
Men under overflaten står ofte en rekke viktige spørsmål ubesvart:
Hvem eier egentlig systemet når prosjektteamet trekker seg ut?
Hva regnes som normal drift – og hva er avvik?
Hvilke beslutninger ble bevisst tatt som midlertidige, og hvilke var ment å være varige?
Hvilke antakelser lå til grunn for at man kunne bevege seg raskt?
Når disse spørsmålene forblir uavklarte, introduserer onboarding usikkerhet i tillegg til de nye systemene. Denne usikkerheten er usynlig i starten, og den skaper ikke nødvendigvis umiddelbare hendelser. I stedet blir den liggende, og dukker først opp senere, gjerne i forbindelse med endringer, skalering, hendelser eller overlevering mellom team.
På tvers av mange onboarding‑prosesser dukker de samme mønstrene opp igjen og igjen. Ikke på grunn av dårlig intensjon, men på grunn av tempo, press og dyktige mennesker som gjør sitt beste med begrenset tid.
Ofte blir ikke langsiktig eierskap tydelig definert. Ansvar er tydelig i selve leveransen, men hvem som faktisk har ansvar etter onboarding, forblir uklart. Når utfordringer oppstår måneder eller år senere, brukes tiden på å diskutere hvem som eier dem i stedet for hvordan problemet skal løses.
I andre tilfeller blir beslutninger tydelig omtalt som midlertidige «foreløpig». Snarveier, unntak eller midlertidige løsninger tas i bruk for å opprettholde fremdrift. Uten et klart tidspunkt for når disse beslutningene skal vurderes på nytt, blir «midlertidig» gradvis permanent.
Antakelser spiller en sentral rolle. Forventninger til kapasitet, bruksmønstre, supportmodeller og avhengigheter mellom integrasjoner behandles ofte som felles forståelse, heller enn dokumenterte fakta. Når antakelser ikke skrives ned, forblir de ikke fleksible – de stivner sakte til virkelighet.
Under tidspress oppstår også workarounds. Det som begynner som en praktisk løsning der og da, ender ofte med å definere hvordan systemet brukes i årevis. Over tid blir disse workaroundene normalen, selv om det aldri var intensjonen.
Til slutt ser vi ofte at onboarding‑prosessen er ensidig fokusert på go‑live, mens det som skjer etterpå forblir implisitt. Optimalisering, stabilisering og overføring av eierskap antas, heller enn planlegges.
Dette er ikke et resultat av dårlig ingeniørarbeid. Det er et naturlig resultat av å bevege seg raskt uten å gjøre forutsetninger og beslutninger eksplisitte.
Når situasjonen til slutt omtales som «teknisk gjeld», er symptomene ofte velkjente. Det er usikkerhet rundt hvem som eier endringer. Deler av systemet blir «fareområder» ingen ønsker å røre. Manuelle prosesser lever videre uten at noen fullt ut forstår dem ende‑til‑ende. Forbedringer utsettes fordi konsekvensene er uklare.
Samtaler starter med setninger som:
«Vi har alltid gjort det sånn.»
På dette tidspunktet fremstår gjelden som dypt teknisk. Nedbetalingen krever langt mer enn å rydde i kode eller oppgradere plattformer.
Mange organisasjoner forsøker å håndtere teknisk gjeld sent, gjennom opprydningsinitiativ eller egne refaktoreringsprosjekter. Slike tiltak kan hjelpe, men de hindrer sjelden at de samme utfordringene oppstår igjen.
Det mest virkningsfulle tidspunktet for å redusere denne gjelden er tidlig, i selve onboarding‑fasen. Det forutsetter verken nye verktøy eller omfattende rammeverk. I praksis handler det ofte om å gjøre noen få, grunnleggende grep mer bevisst.
Øyvind Bredland - Team Lead Customer Onboarding, Cegal
Eierskap må gjøres eksplisitt fra start. Viktige beslutninger bør dokumenteres, sammen med kontekst og avveiinger. Antakelser bør skrives ned, ikke bæres stilltiende. Midlertidige beslutninger bør ha en tydelig forståelse av når – og hvordan – de skal revurderes. Og onboarding bør sees som starten på drift, ikke slutten på leveranse.
I bunn og grunn handler dette om tydelighet.
Teknologi vil endre seg. Kontekst vil skifte. Krav vil utvikle seg. Det som gjør team i stand til å tilpasse seg, er ikke fraværet av gjeld, men at tydelighet er tilstede. Tydelighet rundt hvorfor ting ble gjort, hvem som eier dem, og hvilke antakelser som fortsatt gjelder.
Derfor er teknisk gjeld som regel ikke teknisk. Den er et resultat av usikkerhet som blir introdusert tidlig og aldri avklart. Å redusere den starter sjelden i koden. Det starter med å være eksplisitt, tidlig, og villig til å revurdere beslutninger før de setter seg.
Onboarding etablerer forventninger, vaner og grenser som lever lenge etter leveransen. Når eierskap, beslutninger og antakelser forblir implisitte på dette stadiet, forsvinner de ikke. De dukker opp igjen senere som friksjon, usikkerhet, og det vi altså ofte ender med å kalle teknisk gjeld.
Jo tidligere disse tingene tydeliggjøres, desto enklere blir alt som følger etter.