Come costruire e scalare un team di ingegneria

Scalare un team di ingegneria non è "assumere più persone". È costruire un sistema in cui le persone giuste entrano, capiscono cosa fare, crescono e restano — mentre la qualità tiene. Crescere male è peggio che non crescere: aggiungere ingegneri a un team disorganizzato lo rende solo più lento.

Prima di assumere: sei sicuro che il problema sia il numero?

La domanda più importante prima di aprire una posizione è: stiamo andando lenti perché siamo pochi, o perché siamo disorganizzati? Spesso è la seconda. Aggiungere persone a un sistema con priorità confuse, troppo work-in-progress e processi di review lenti non accelera niente — aggiunge solo coordinamento.

La legge di Brooks è ancora valida: aggiungere persone a un progetto in ritardo lo fa ritardare di più, almeno nel breve. Assumi per capacità futura, non per spegnere un incendio presente.

Hiring: assumere per traiettoria, non solo per competenze

Le competenze tecniche sono il filtro d'ingresso, non il criterio di scelta. A parità di livello, scegli chi mostra capacità di apprendere in fretta, di lavorare bene con gli altri e di alzare il livello intorno a sé. Un processo di hiring sano ha tre proprietà:

• Segnale, non rumore. Ogni step deve misurare qualcosa che conta sul lavoro reale. Niente quiz da manuale: problemi vicini a quelli che la persona affronterà davvero.
• Coerenza. Stessa griglia di valutazione per tutti, decisioni basate su evidenze scritte, non su "sensazioni". È così che si riduce il bias e si assume in modo equo.
• Velocità. I migliori candidati ricevono più offerte. Un processo che dura settimane li perde. Rapidità e rigore non sono in conflitto se il processo è progettato bene.

«Un'assunzione sbagliata non costa solo lo stipendio: costa il tempo del team, i progetti rallentati e l'energia per rimediare. Meglio una posizione aperta più a lungo che la persona sbagliata.»

Onboarding: i primi 30 giorni decidono i prossimi due anni

Il momento in cui perdi più valore è subito dopo l'assunzione, quando una persona brava resta improduttiva e frustrata perché nessuno l'ha messa in condizione di contribuire. Un buon onboarding ha un obiettivo misurabile: una prima pull request in produzione entro la prima settimana, anche piccola.

Questo richiede preparazione: ambiente di sviluppo che funziona al day one, documentazione viva, un "buddy" assegnato e una manciata di task di ingresso ben scelti. Ogni ora investita qui si ripaga molte volte nei mesi successivi.

Struttura: spezzare prima che faccia male

Oltre le 8-10 persone, un team unico inizia a scricchiolare: i 1:1 si diluiscono, le decisioni rallentano, la comunicazione diventa overhead. È il momento di organizzarsi in team più piccoli, ciascuno con un perimetro chiaro e ownership reale su una parte del prodotto o della piattaforma.

La regola guida è la "two-pizza team": team abbastanza piccoli da nutrirsi con due pizze, abbastanza autonomi da non dipendere da altri per spedire. L'autonomia non è un benefit: è ciò che permette di scalare senza che tutto passi dal tuo collo di bottiglia.

Trattenere: le persone se ne vanno dai manager, non dalle aziende

Scalare significa anche non perdere chi hai già. I motivi per cui i bravi ingegneri se ne vanno sono noti e quasi sempre evitabili: mancanza di crescita, mancanza di riconoscimento, mancanza di contesto sul perché del loro lavoro. Tre pratiche che fanno la differenza:

1. 1:1 regolari e veri, dove si parla di carriera e ostacoli, non solo di stato dei task.
2. Percorsi di crescita espliciti, con un livello tecnico (staff/principal) tanto rispettato quanto quello manageriale.
3. Riconoscimento specifico e tempestivo: dire "grazie" e dire "perché ha contato" sono cose diverse.

Costruire e scalare un team è una delle competenze più difficili — e meno insegnate — della leadership tecnica. È uno dei pilastri dei nostri programmi: meno teoria, più framework applicabili e il confronto con chi ha già scalato team da 5 a 50.