Hvordan skalerer du engineering practices, når teamet vokser?

Question

Accepted Answer

Practices, der fungerer for 3 engineers, bryder sammen ved 30. Uformel koordination, tribal knowledge og manuelle processer skalerer ikke. En senior TL skal **udvikle practices forud for vækstskurven**, formalisere netop nok struktur til at bevare velocity uden bureaukrati.

## Hvad der skal 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

Ved 5 personer kender alle hele systemet og deployer manuelt. Ved 25 er det kaos, du har brug for en rigtig CI/CD pipeline, service ownership, skrevne runbooks og review norms, eller teamet bliver lammet af at kæmpe med hinanden.

## Tilføj struktur just in time

Ikke pålæg tung proces på et lille team (det kvæler dem), og lad være med at holde fast i startup informalitet på et stort team (det kollapser). Tilføj hver enkelt del af strukturen *når smerten dukker op*, ideelt set lige før. Pas på signalerne: stigende merge konflikter, knowledge bottlenecks, ustabile deploys.

## Trade-off'en

Mere proces handler flexibilitet til gengæld for konsistens og skala. For lidt og store teams skaber uorden; for meget og du kvæler den hastighed, der gjorde dig succesfuld. Kalibrér løbende.

## Hvorfor det betyder noget

De practices, der bragte et lille team til succes, vil aktivt kvæle et større.

En TL, der skalerer practices proaktivt, holder et voksende team hurtigt; en, der ikke gør det, ser velocity kollapse, når teamet vokser – det klassiske scaling-fælde.