Onboarding i tekniske team — utvikling, IT-drift, dataingeniør, sikkerhet — er notorisk vanskelig. Den nyansatte trenger ikke bare lære selve domenet og kodebase, men også interne prosesser, beslutningshistorikk, ansvarsfordeling, og hvilke verktøy som brukes hvor.
I scale-ups er det ofte slik at "onboarding-dokumentasjon" er en README som ble skrevet av første utvikler for to år siden, oppdatert tilfeldig, og som per i dag dekker omtrent 30 % av det en ny ansatt faktisk trenger å vite. Resten lever som tribal knowledge — historier, Slack-tråder, og «spør Per om det».
Dette er en skjult kostnad. La oss anslå hva den faktisk er, og hva som kan gjøres med den.
Hvor mye taper du på dårlig onboarding?
Anta et team med 15 tekniske ansatte, gjennomsnittlig 20 % årlig turnover (en realistisk rate i nordiske tech-bedrifter), og en gjennomsnittslønn med byrder på rundt 1 200 000 kr per ansatt.
Hvis hver ny ansatt taper 3 måneder produktivitet fordi onboardingen er fragmentert — som er konservativt — er det:
- 3 ansatte starter per år (15 × 20 %)
- Hver taper 3 måneder × 100 000 kr/mnd ramped produktivitet ≈ 300 000 kr
- Total: ca 900 000 kr/år i tapt produktivitet
Det inkluderer ikke kostnaden ved at eksisterende teammedlemmer bruker tid på å forklare ting, eller risikoen ved at nyansatte tar feil beslutninger fordi de ikke forsto kontekst.
Dette er typisk usynlig fordi det aldri kommer på en faktura. Men det er reelt.
Hva som faktisk mangler
Når jeg snakker med team om onboarding-dokumentasjon, er det fire ting som mangler nesten alltid:
1. Prosessoversikt for kjerneflyter
Hvordan rulles en endring ut til produksjon? Hvordan håndteres en incident? Hvordan godkjennes endringer i kritiske systemer? Disse prosessene finnes i hodene til 2–3 personer. Når en ny ansatt skal gjøre dem første gang, må de gjette eller spørre, og da blir det inkonsistent.
2. Beslutningshistorikk
"Hvorfor bruker vi Kafka og ikke RabbitMQ?" "Hvorfor er kontoplan satt opp slik?" "Hvorfor stoler vi ikke på dette eksterne API-et?" Svarene finnes ofte i en gammel diskusjon, en arkitektur-skisse, eller i hodet til den som var med fra start. Nye ansatte gjentar enten beslutningen uten å vite hvorfor, eller stiller spørsmålet på nytt.
3. Ansvarskart
Hvem eier hvilke systemer? Hvem skal varsles ved hvilke type incidenter? Hvem kan godkjenne hva? I scale-ups endrer dette seg ofte uten at noen oppdaterer. Nye ansatte blir sendt rundt mellom team før de finner riktig person.
4. Verktøy-katalog med kontekst
Hvilke verktøy bruker teamet, hva brukes de til, og hva er alternativene man har vurdert? Lister over verktøy uten kontekst er nesten verdiløse — du må forstå hvorfor verktøyet er der.
Hvorfor README-en ikke er nok
README-filer er bra for tekniske detaljer i én kodebase, men de skalerer dårlig som onboarding-dokumentasjon. Tre grunner:
- De fragmenteres. Hver service har sin egen README, og det blir 50 README-er ingen klarer å holde oppdaterte.
- De handler om "hvordan", ikke "hvorfor". README-en sier hvordan du kjører testen, ikke hvorfor systemet er bygget som det er.
- De er ikke prosess-orienterte. README-en sier ikke "for å rulle ut, gjør X, deretter Y, sjekk Z" — den sier "her er kommandoene".
Prosess-dokumentasjon bør være separat og handle om end-to-end-flyter, ikke om enkelt-systemer.
Hva god onboarding-dokumentasjon ser ut som
For tekniske team har jeg sett tre komponenter som fungerer:
1. Prosesskart (BPMN eller tilsvarende) for de 5–8 viktigste flytene
Eksempler:
- Hvordan rulles en endring ut til produksjon (fra commit til prod)
- Hvordan håndteres en P1-incident (fra varsel til post-mortem)
- Hvordan onboardes ny kunde i systemet (om relevant)
- Hvordan administreres tilganger (provisjonering, deprovisjonering, revisjon)
- Hvordan håndteres feilrettinger i produksjon (hotfix-flow)
For en innføring i hvordan du tegner BPMN, se denne artikkelen.
2. ADR-er (Architecture Decision Records) for kjernebeslutninger
Kort dokumenter, ofte 1–2 sider, som beskriver en arkitektur-beslutning, hva som ble vurdert, og hvorfor det ble valgt. Disse er gull verdt fordi de bevarer kontekst.
3. Ansvarsmatrise med eierskap per system
En enkel tabell over alle kritiske systemer/områder, med eier, backup-eier, og siste oppdaterte dato. Oppdateres kvartalsvis.
Hvordan starte når du har null dokumentasjon
Det vanligste hinderet for å starte er at "vi må dokumentere alt". Det stemmer ikke. Start med:
- Identifiser de tre prosessene som nye ansatte spør om mest. Spør lederne. Sannsynligvis er det utrulling, incident-håndtering, og tilgangshåndtering.
- Få en eksisterende ansatt til å forklare hver prosess i 30 min. Spille inn med Loom eller skrive ned mens de snakker.
- Transkriber til prosessdiagram + narrativ. Dette er ofte der det er verdt å få ekstern hjelp — det er en spesifikk ferdighet å oversette en muntlig forklaring til strukturert dokumentasjon.
- La en ny ansatt teste dokumentasjonen. Hvis de kommer seg gjennom prosessen uten å spørre, er du i mål. Hvis ikke, oppdater.
- Gjenta for neste prosess.
Etter 3–6 måneder har du et grunnlag for 5–10 kjerneflyter. Det er der gevinsten begynner å vise seg.
Hvis du vurderer ekstern hjelp
Vi leverer prosessdokumentasjon for tekniske team i samme format som for finansprosesser: BPMN, narrativ, ansvarsregister. Forskjellen er typisk at vi gjør 60-min walkthrough-calls med eksisterende team-medlemmer i stedet for å gå gjennom SOPer (som ofte ikke finnes for tekniske flyter).
Se hvordan vi jobber eller se eksempel-leveransen.
Oppsummering
Onboarding-dokumentasjon for tekniske team er en av de største skjulte kostnadene i scale-ups. Det er ikke en luksus — det er en investering med en målbar ROI i form av redusert ramp-tid og lavere belastning på eksisterende team.
Den enkleste måten å starte er å dokumentere de 3–5 prosessene som nyansatte spør om mest. Resten kommer etter hvert.