Come scalare le pratiche di ingegneria mentre il team cresce?

Question

Accepted Answer

Le pratiche che funzionano per 3 ingegneri si rompono a 30. Il coordinamento informale, la conoscenza tribale e i processi manuali non scalano. Un senior TL deve **evolvere le pratiche davanti alla curva di crescita**, formalizzando solo la giusta quantità di struttura per mantenere la velocità senza burocrazia.

## Cosa deve scalare

```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
```

## Un esempio concreto

Con 5 persone, tutti conoscono tutto il sistema e deployano a mano. A 25, è il caos: serve una vera pipeline CI/CD, ownership dei servizi, runbook scritti e norme di review, altrimenti il team si blocca a combattere gli uni con gli altri.

## Aggiungi struttura al momento giusto

Non imporre processo pesante su un team piccolissimo (li soffoca), e non aggrapparsi all'informalità da startup su uno grande (crolla). Aggiungi ogni pezzo di struttura *quando il dolore appare*, idealmente poco prima. Guarda i segnali: merge conflict crescenti, colli di bottiglia di conoscenza, deploy instabili.

## Il compromesso

Più processo scambia flessibilità per consistenza e scala. Troppo poco e team grandi si dibattono; troppo e soffochi la velocità che ti ha reso vincente. Calibra continuamente.

## Perché è importante

Le pratiche che hanno reso vincente un team piccolissimo soffocheranno attivamente uno più grande.

Un TL che scala le pratiche proattivamente mantiene un team in crescita veloce; uno che non lo fa guarda il velocity collassare mentre il team cresce, il classico inganno di scaling.