Guide

Il Vero Costo di una Cattiva Assunzione Tecnica

Di Marc Molas·5 febbraio 2024·9 min di lettura

La stima standard del settore dice che una cattiva assunzione costa tra 1,5x e 3x lo stipendio annuo della posizione. Se assumi un ingegnere senior a 80.000 euro all'anno e non funziona, stai guardando un buco tra 120.000 e 240.000 euro.

Ma quella cifra cattura solo la parte visibile. Quella che puoi mettere in un foglio di calcolo. Ciò che davvero distrugge una startup non è il denaro perso — è il tempo che non torna e il danno che ha lasciato.

I costi visibili: quello che puoi calcolare

Partiamo dall'ovvio, perché già fa abbastanza male:

Stipendio accumulato. I mesi che hai pagato prima di renderti conto dell'errore. Di solito 3-6 mesi.
Costi di recruiting. Se hai usato un'agenzia, hai pagato tra il 15% e il 25% dello stipendio annuo. Se lo hai fatto internamente, il tempo investito in screening, colloqui e negoziazione.
Indennità di uscita. A seconda del paese e del contratto, può variare da un mese a diversi mesi di stipendio.
Costo di sostituzione. Si ricomincia da capo. Un altro giro di pubblicazione offerte, screening CV, colloqui tecnici, negoziazione. Con fortuna, 2-3 mesi. Altrimenti, 6.

Somma tutto e arrivi facilmente a quella stima di 1,5-3x. Ma è qui che la maggior parte delle analisi si ferma. Ed è qui che inizia il vero danno.

I costi invisibili: quello che non compare in nessun foglio di calcolo

Debito tecnico ereditato

Un cattivo ingegnere non solo non costruisce ciò che dovrebbe. Costruisce male ciò che tocca. Codice senza test, architettura che non scala, dipendenze inutili, astrazioni che nessuno capisce. Quando se ne va, quel codice resta. E qualcuno deve farci i conti.

Ho visto casi in cui un ingegnere è rimasto 4 mesi in una startup e ha lasciato un codebase che il senior successivo ha impiegato 6 settimane a riscrivere prima di poter andare avanti. Quelle 6 settimane sono puro costo affondato — non stai costruendo feature nuove, stai disfacendo il lavoro di qualcuno che se ne è andato.

Danno al morale del team

Questo è ciò che si misura meno e ha più impatto. Quando un membro del team non rende, il resto lo sa. Prima di te, di solito. E ogni settimana che passa senza che tu faccia qualcosa al riguardo, la tua credibilità come leader si erode.

I bravi ingegneri non vogliono lavorare con cattivi ingegneri. Se ci metti troppo ad agire, il rischio non è solo perdere quello che non funziona — è che quelli che funzionano inizino a cercare altrove.

Deadline non rispettate

Hai assunto quell'ingegnere perché dovevi consegnare qualcosa. Una feature critica, un'integrazione, un MVP. Ogni mese che passa con qualcuno che non esegue è un mese di ritardo sul tuo prodotto. In una startup, questo può significare:

Perdere una finestra di mercato. Il tuo concorrente ha lanciato per primo.
Perdere la fiducia degli investitori. Non hai rispettato la roadmap che hai presentato nel round.
Perdere clienti. Hai promesso una feature per il Q1 e non è arrivata.

Perdita di conoscenza istituzionale

Quando qualcuno se ne va — anche se è qualcuno che non rendeva bene — si porta via contesto. Decisioni che ha preso, conversazioni che ha avuto con altri membri del team, comprensione del dominio di business. Parte di quel contesto si perde per sempre. L'ingegnere successivo parte con un deficit informativo che impiega settimane a colmare.

La linea temporale del disastro

Mettiamo dei numeri sul tempo:

Mesi 0-3: Assunzione. Pubblichi l'offerta, filtri, fai colloqui, negozi, onboarding. Se va tutto bene, 2-3 mesi. Se il mercato è caldo — e nel tech lo è — possono essere 4-6.
Mesi 3-6: Luna di miele. Il nuovo ingegnere entra. I primi mesi sono di ramp-up. È normale che non produca al 100%. Gli dai il beneficio del dubbio.
Mesi 6-9: Il sospetto. Inizi a vedere segnali. Le code review tornano con molti commenti. I task si ritardano. Altri ingegneri iniziano a lamentarsi in privato. Ma pensi: "Forse ha bisogno di più tempo."
Mesi 9-11: La certezza. Ormai sai che non funziona. Ma adesso devi gestire l'uscita. Conversazioni difficili, documentare le performance, processo di offboarding.
Mesi 11-14: Di nuovo al punto di partenza. Ricominci ad assumere.

Risultato: fino a 14 mesi persi. Per una startup che cerca di raggiungere il product-market fit, può essere letale.

Perché succede: gli errori più comuni

Le cattive assunzioni non sono sfortuna. Sono il risultato di un processo rotto. Questi sono gli errori che vedo più frequentemente:

Assumere con urgenza, non con criterio

"Ci serve un backend developer per ieri." Suona familiare. La pressione di consegnare fa abbassare l'asticella. Accetti il candidato che va "bene" invece di aspettare quello "eccellente." Quella scorciatoia costa sempre di più.

Fidarsi troppo del CV

Un CV impressionante non garantisce nulla. Ho intervistato candidati con esperienza in Google e Amazon che non riuscivano a risolvere un problema basilare di system design. E ho visto ingegneri di aziende sconosciute che scrivevano codice impeccabile. Il CV ti dice dove è stata una persona. Non ti dice come lavora.

Non fare una valutazione tecnica vera

Una conversazione di 30 minuti non è una valutazione tecnica. Se non stai facendo code review di codice reale, esercizi di system design o almeno una sessione di pair programming, stai tirando a indovinare. E indovinare con assunzioni da 60.000-100.000 euro l'anno è un rischio assurdo.

Valutare il colloquio, non la produzione

C'è gente che fa colloqui incredibilmente bene e produce in modo mediocre. E viceversa. Se il tuo processo seleziona per capacità di colloquio invece che per capacità di esecuzione, stai ottimizzando per la cosa sbagliata.

Come prevenirlo: il framework che funziona

Non c'è garanzia al 100%, ma puoi ridurre drasticamente il rischio:

1. Vetting tecnico rigoroso. Non solo algoritmi e strutture dati. Valutazione di codice reale. Come struttura un progetto? Come gestisce gli errori? Come ragiona sul testing? Sa spiegare decisioni architetturali prese in progetti precedenti?

2. Valutazione da parte di ingegneri, non di recruiter. Un recruiter può valutare soft skill e fit culturale. Non può valutare se qualcuno sa progettare un sistema di code distribuite. I tuoi ingegneri senior — o il tuo CTO — devono essere nel processo.

3. Periodo di prova reale. Non un periodo di prova in cui guardi se la persona "si integra." Un periodo in cui le assegni lavoro reale con deliverable concreti e valuti la qualità dell'output. 2-4 settimane sono di solito sufficienti per capire se qualcuno esegue davvero.

4. Referenze tecniche, non solo professionali. Non chiamare solo il suo ex capo. Parla con qualcuno che ha revisionato il suo codice o ha lavorato nello stesso team tecnico. Le domande che contano: "Lavoreresti di nuovo con questa persona? Le affideresti un progetto critico?"

Come lo risolviamo in Conectia

Tutto quanto sopra richiede tempo, expertise tecnica e un processo ben definito. La maggior parte delle startup in fase iniziale non ha tutte e tre le cose. Hanno fretta, hanno un founder tecnico già al limite della sua capacità e non hanno un processo di hiring collaudato.

È esattamente per questo che abbiamo creato Conectia. Il nostro processo di vetting ha un tasso di accettazione dell'8%. Non è un filtro di CV — è una valutazione tecnica guidata da CTO con esperienza in produzione. Valutiamo codice reale, capacità di system design ed esperienza dimostrabile in ambienti startup.

Se un ingegnere non funziona, lo sostituiamo nei primi 30 giorni senza costi aggiuntivi. Non perché ci aspettiamo che succeda — il nostro tasso di retention è del 95% — ma perché capiamo che per un founder, la fiducia nel processo conta tanto quanto il risultato.

Il costo di una cattiva assunzione non è un numero su un foglio di calcolo. È tempo che non recuperi, codice che devi riscrivere e morale del team che impiega mesi a ricostruirsi. Il miglior investimento che puoi fare non è assumere in fretta — è assumere bene.

Stanco di processi di assunzione che non filtrano davvero? Parla con un CTO — ingegneri senior pre-validati con garanzia di sostituzione in 30 giorni.