Ho assunto oltre 500 ingegneri. Ecco cosa avrei voluto sapere il primo giorno

Quindici anni fa ho fatto la mia prima assunzione engineering. Mi e andata bene — la persona si e rivelata eccellente. Ma non avevo un framework, non avevo un processo, e non avevo la minima idea di cosa stessi facendo.

Cinquecento assunzioni dopo, ho una prospettiva molto diversa. Alcune lezioni sono arrivate dai successi. La maggior parte dai fallimenti. Tutte hanno plasmato il modo in cui penso oggi alla costruzione di team tecnici.

Queste non sono teorie da manuale di business school. Sono pattern che ho visto ripetersi in startup a Londra, Berlino, Milano, Amsterdam, e in team remoti distribuiti su tre continenti.

Lezione 1: Il miglior predittore di successo non e il CV

All’inizio della mia carriera, ero impressionata dal pedigree. Nomi di grandi aziende, lauree nelle migliori universita, titoli altisonanti. Ho imparato a mie spese che questi sono segnali deboli.

Il predittore piu forte che ho trovato e quello che una persona ha costruito e rilasciato. Non in quale team era. Non per quale azienda lavorava. Cosa ha contribuito personalmente a creare e quali sono stati i risultati.

Uno sviluppatore che ha costruito e lanciato un side project con 1.000 utenti mi dice piu di qualcuno che ha passato tre anni in una FAANG lavorando su un componente di un componente.

Questo e particolarmente rilevante nel contesto italiano, dove il peso del “nome dell’azienda” e del titolo di studio e ancora molto forte. Ho visto troppi processi di selezione dove un candidato con una laurea al Politecnico e un passaggio in una grande consulenza veniva preferito automaticamente a un autodidatta che aveva costruito prodotti reali. Nella mia esperienza, e quasi sempre la scelta sbagliata.

Non sto dicendo che l’esperienza in grandi aziende sia inutile. Dico che non e sufficiente. Scavate sempre nella domanda “cosa hai fatto tu personalmente?” La risposta rivela tutto.

Lezione 2: La velocita di assunzione e un vantaggio strategico

Credevo che prendersi tempo per assumere fosse un segno di scrupolosita. Ora so che di solito e un segno di indecisione.

I candidati migliori — quelli che ogni azienda vuole — sono fuori dal mercato in 10-14 giorni. Se il vostro processo dura 6 settimane, state sistematicamente selezionando persone che hanno meno alternative.

Questo non significa prendere decisioni affrettate. Significa eliminare gli sprechi dal processo. Ogni giorno tra un colloquio e l’altro deve avere uno scopo. Se non ce l’ha, state solo perdendo candidati.

Le aziende che ho visto vincere costantemente la guerra per il talento condividono un tratto: prendono decisioni velocemente. Non decisioni avventate. Decisioni veloci e informate.

In Italia, dove i processi aziendali tendono a essere piu lenti per cultura, la velocita nel recruiting e un vantaggio competitivo enorme. Ho visto startup italiane perdere candidati eccellenti a favore di aziende olandesi, tedesche o britanniche semplicemente perche queste ultime facevano un’offerta due settimane prima.

Lezione 3: La cultura non e fatta di benefit

Ho visto aziende con uffici bellissimi, pranzo gratuito e ferie illimitate faticare a trattenere gli ingegneri. Ho visto aziende senza nessuno di questi benefit costruire team che restano per anni.

La cultura non e quello che offrite. E come si sentono le persone quando lavorano con voi.

Le cose che contano davvero per gli ingegneri:

• Hanno autonomia su come lavorano?
• La loro opinione e genuinamente valorizzata nelle decisioni tecniche?
• Esiste un percorso di crescita chiaro?
• Il codebase e qualcosa di cui possono essere orgogliosi, o ogni giorno e una lotta contro il debito tecnico?
• La leadership li protegge da riunioni inutili e politiche interne?

Se ottenete queste cose, il tavolo da ping pong e irrilevante.

Nella mia esperienza con aziende italiane, il problema culturale piu diffuso e la mancanza di autonomia. Troppi team engineering sono gestiti con un approccio command-and-control che soffoca la creativita e spinge i profili migliori verso aziende straniere che offrono piu fiducia e responsabilita. Se volete trattenere talento tech in Italia, dovete offrire un ambiente dove gli ingegneri si sentono proprietari del loro lavoro, non esecutori di ordini.

Lezione 4: Il costo di un’assunzione sbagliata e molto peggio di quanto pensiate

Tutti sanno che le assunzioni sbagliate sono costose. Ma il costo reale non e lo stipendio o la fee del recruiter. E il danno al team circostante.

Ho visto una singola assunzione senior sbagliata:

• Causare le dimissioni di tre ingegneri validi nel giro di 6 mesi
• Introdurre decisioni architetturali che hanno richiesto 18 mesi per essere smantellate
• Distruggere la sicurezza psicologica del team, rendendo tutti timorosi di esprimere opinioni
• Ritardare la roadmap di prodotto di un intero trimestre

Il costo finanziario di un’assunzione sbagliata viene spesso citato come 1,5-3 volte lo stipendio annuo. Nella mia esperienza, quando si calcola il danno al team, per i ruoli senior si avvicina a 5-10 volte.

Per questo sono assolutista sulle reference check. Non quelle formali, da HR a HR, con domande preconfezionate. Conversazioni reali con persone che hanno lavorato a stretto contatto con il candidato. “Lo riassumeresti?” e l’unica domanda che conta davvero.

In Italia, le reference check sono ancora poco diffuse o fatte in modo superficiale. Questo e un errore costoso. Investite 30 minuti in una conversazione onesta con un ex collega e risparmierete mesi di problemi.

Lezione 5: La diversita non e un nice-to-have

Saro diretta: i team omogenei costruiscono prodotti peggiori. L’ho visto cosi tante volte che non lo considero piu discutibile.

Quando ogni ingegnere nel team ha lo stesso background, la stessa formazione e la stessa prospettiva, condividono gli stessi punti ciechi. Costruiscono per persone come loro. Mancano edge case che team diversi intercettano naturalmente.

Ma ecco dove la maggior parte delle aziende sbaglia sulla diversita: la trattano come un problema di pipeline. “Semplicemente non riceviamo candidature diverse.” Questo e quasi sempre un sintomo, non una causa.

Le cause sono di solito:

• Job description scritte in modo che scoraggiano candidati diversi dal candidarsi
• Processi di selezione che premiano uno specifico stile comunicativo rispetto alla capacita effettiva
• Un team che appare e si percepisce come poco accogliente per chiunque sia diverso
• Canali di sourcing che raggiungono sempre la stessa demografia

In Italia, dove il settore tech e ancora fortemente sbilanciato in termini di genere e background, questo tema e particolarmente urgente. Le aziende che investono attivamente nella diversita non lo fanno per compliance o per immagine — lo fanno perche costruiscono prodotti migliori e team piu resilienti.

Sistemate il sistema, e la pipeline seguira.

Lezione 6: Il recruiting remoto ha cambiato tutto (ma non come pensate)

Quando il lavoro remoto e diventato mainstream, mi aspettavo che rendesse il recruiting piu facile. Accesso al talento globale, nessun vincolo geografico, cosa c’e da non amare?

La realta e piu sfumata. Il recruiting remoto ha ampliato il bacino di talenti ma ha anche ampliato la competizione. La vostra startup a Milano ora compete con aziende a San Francisco, Londra e Singapore per lo stesso candidato.

Cosa e realmente cambiato:

• La compensazione e diventata piu complessa. Pagate in base alla localita? Al valore? Con un’unica banda globale? Non c’e una risposta universalmente giusta, ma serve una filosofia chiara. Per le aziende italiane, questo e un tema cruciale: se pagate “stipendi italiani” a ingegneri che possono lavorare per aziende che offrono stipendi nord-europei da remoto, perderete talento.

• La costruzione della cultura e diventata intenzionale. In ufficio, la cultura accade per caso. Da remoto, deve essere progettata. Le aziende che non hanno investito in questo hanno perso persone.

• L’onboarding e diventato critico. Un ingegnere remoto che ha un pessimo primo paio di settimane non si riprendera mai. L’isolamento amplifica ogni segnale negativo.

• I metodi di valutazione si sono adattati. Le sessioni di pair programming in video funzionano sorprendentemente bene. I take-home project sono controversi ma danno ai candidati il tempo di mostrare il loro lavoro migliore. Il live whiteboard coding si traduce terribilmente in remoto.

Lezione 7: Il colloquio e una valutazione bidirezionale

Ci ho messo un tempo imbarazzantemente lungo a interiorizzare questa lezione. Per anni, ho trattato i colloqui come l’azienda che valuta il candidato. Non e cosi. E una valutazione reciproca.

I migliori candidati stanno intervistando voi tanto quanto voi state intervistando loro. Stanno valutando:

• Quanto e organizzata questa azienda? (Il colloquio e iniziato puntuale? Gli intervistatori sembravano preparati?)
• Come comunicano le persone? (Il feedback e stato tempestivo e rispettoso?)
• Com’e davvero la cultura engineering? (Hanno parlato di sfide reali o hanno solo dipinto un quadro roseo?)

Ora dico ai miei clienti: progettate il vostro processo di selezione come se il candidato fosse il vostro cliente. Perche in un mercato dove il talento scarseggia, lo e.

Questo vale doppio in Italia, dove la cultura del “l’azienda fa un favore al candidato assumendolo” e ancora diffusa in molti contesti. I profili tech senior hanno il potere negoziale dalla loro parte. Trattateli di conseguenza.

Lezione 8: La retention inizia prima del primo giorno

La leva di retention piu potente non e la compensazione, lo sviluppo di carriera o la cultura. E assumere la persona giusta per il ruolo giusto al momento giusto.

La maggior parte del turnover che ho investigato risale a un disallineamento che esisteva fin dall’inizio:

• Il ruolo e stato presentato come qualcosa che non era
• Le aspettative di crescita del candidato non corrispondevano alla traiettoria dell’azienda
• C’era un disallineamento valoriale che il colloquio non ha fatto emergere
• La sfida tecnica e stata sovrastimata o sottostimata

Un hiring onesto e trasparente e la singola strategia di retention piu efficace. Ogni ora che investite nell’assicurarvi che il fit sia genuinamente corretto vi ripaga dieci volte in turnover evitato.

Ho visto aziende italiane perdere ingegneri dopo sei mesi perche durante il colloquio avevano promesso “un team che fa innovazione” e la realta era manutenzione di un legacy system. Quella disonesta — anche se non intenzionale — costa enormemente.

Lezione 9: Il processo scala. L’istinto no.

Con 5 ingegneri, il founder puo prendere decisioni di assunzione basandosi sull’istinto. Conosce esattamente cosa serve, puo valutare il fit intuitivamente, e il suo giudizio e generalmente buono.

Con 15 ingegneri, questo meccanismo si rompe. Con 30, e un disastro.

La transizione dall’istinto al processo e scomoda per i founder. Sembra burocratica. Sembra lenta. Ma senza di essa, ottenete decisioni di assunzione inconsistenti, bias inconsci che operano senza controllo, e un’esperienza candidato che dipende interamente da quale intervistatore capita.

Il processo non deve essere pesante. Ma deve esistere:

• Scorecard definite per ogni fase del colloquio
• Intervistatori calibrati che sono stati formati su cosa valutare
• Sessioni di debrief strutturate con feedback documentato
• Criteri decisionali chiari: chi decide e sulla base di cosa?

Nella mia esperienza, i founder italiani sono particolarmente restii a questa transizione. C’e una cultura del “mi fido del mio istinto” che funziona bene per le prime assunzioni ma diventa pericolosa man mano che il team cresce. L’istinto non e sbagliato — e incompleto. Il processo non sostituisce l’istinto. Lo completa.

Lezione 10: Chiedete aiuto prima di averne bisogno

Questa e forse la lezione piu importante, e quella che i founder resistono di piu ad accettare.

Quando vi rendete conto che il vostro processo di assunzione e rotto, avete gia perso candidati eccellenti. Quando notate che la cultura engineering ha un problema, i vostri migliori ingegneri stanno gia facendo colloqui altrove. Quando scoprite una lacuna di compliance, potreste essere gia esposti.

Il momento migliore per ottenere aiuto sulla funzione people e prima che le cose si rompano. Costruite l’infrastruttura quando le cose sono tranquille. Progettate i processi prima di essere disperati. Cercate input esperto mentre avete ancora opzioni.

Ho passato 15 anni a guardare aziende imparare queste lezioni nel modo piu duro. Alcune mi hanno chiamata dopo che il danno era fatto — team smembrati, ingegneri chiave persi, mesi di roadmap bruciati. Quelle che mi hanno chiamata prima hanno avuto risultati nettamente migliori e hanno speso molto meno.

Questo vale per le startup italiane tanto quanto per quelle nel resto d’Europa. Anzi, forse di piu, perche il bacino di talento tech in Italia e piu piccolo e ogni assunzione sbagliata ha un impatto proporzionalmente maggiore.

Costruire team engineering e difficile. E anche una delle cose piu consequenziali che un’azienda fa. Trattatela con la serieta che merita.

Dopo cinquecento assunzioni e quindici anni, se devo distillare tutto in un’unica verita, e questa: le aziende che costruiscono grandi team engineering non sono quelle con i budget piu alti o i brand piu forti. Sono quelle che trattano il recruiting come una disciplina — con lo stesso rigore, la stessa iterazione e la stessa attenzione ai dati che dedicano al prodotto.

Tutto il resto segue.