Hvordan skalerer du ingeniørpraksis når teamet vokser?

Question

Accepted Answer

Praksis som fungerer for 3 ingeniører bryter sammen ved 30. Uformell koordinering, stammekunnskap og manuelle prosesser skaleres ikke. En senior TL må **utvikle praksis foran vekstkurven**, formalisere akkurat nok struktur til å holde hastigheten uten byråkrati.

## Hva som må skaleres

```text
✓ CI/CD — fast, reliable, automated; manual deploys don't survive growth
✓ TESTING — automated suites; you can't manually verify everything
✓ CODE REVIEW — clear norms, reasonable turnaround, ownership boundaries
✓ DOCUMENTATION — written knowledge replaces "ask Bob"
✓ ONBOARDING — repeatable, not bespoke per hire
✓ DECISION-MAKING — clear ownership; who decides what
✓ ON-CALL / OWNERSHIP — defined, rotated, not heroic
```

## Et konkret eksempel

Med 5 personer kjenner alle hele systemet og distribuerer manuelt. Med 25 er det kaos, du trenger en ekte CI/CD-pipeline, serviceeierskap, skriftlige runbooks og reviewnormer, eller teamet blir lammet av å kjempe mot hverandre.

## Legg til struktur akkurat i tide

Ikke påfør tungt prosess på et lite team (det kveles dem), og ikke kleng til startup-uformellhet på et stort team (det kollapser). Legg til hver struktur *når smerten oppstår*, helst like før. Se etter signalene: økende merge-konflikter, kunnskapsbottlenecks, usikre distribusjoner.

## Avveiingen

Mer prosess bytter fleksibilitet for konsistens og skala. For lite og store team sliter; for mye og du kveler hastigheten som gjorde deg vellykket. Kalibreres kontinuerlig.

## Hvorfor det betyr noe

Praksisen som fikk et lite team til suksess vil aktivt kvele et større team.

En TL som skalerer praksis proaktivt, holder et voksende team raskt; en som ikke gjør det, ser hastigheten kollapse når teamet vokser, den klassiske skaleringstillen.