In 12 anni di costruzione di prodotti software, gestione di team di sviluppo e intervento in progetti falliti come Fractional CTO, ho visto startup bruciare centinaia di migliaia di euro in assunzioni sbagliate. Non perché i founder fossero negligenti — la maggior parte erano persone intelligenti e determinate che semplicemente non sapevano cosa cercare.
Lo schema è sempre lo stesso. Un founder chiude un round seed, si entusiasma, pubblica un annuncio pieno di buzzword, assume la prima persona che dice "Conosco React" e sei mesi dopo si chiede perché il prodotto è ancora rotto, il codebase è un disastro e metà del budget è sparito.
Vedo questi errori ogni singola settimana. Sono costosi, sono prevedibili e sono del tutto evitabili. Ecco i sette che costano di più alle startup — e cosa fare invece.
Errore #1: assumere in base alla tecnologia, non alla capacità di problem-solving
Questo è l'errore più comune che vedo, e inizia dalla descrizione del lavoro. "Cerchiamo uno sviluppatore React/Node.js con oltre 5 anni di esperienza." Sembra ragionevole, vero? Non lo è. È l'equivalente di assumere un falegname perché possiede una marca specifica di martello.
Le tecnologie cambiano. React potrebbe essere il framework dominante oggi, ma cinque anni fa era Angular. Cinque anni prima ancora, jQuery dominava tutto. Gli sviluppatori che prosperano sono quelli che sanno imparare qualsiasi strumento e applicarlo per risolvere problemi di business reali. Quelli che ristagnano sono quelli che si definiscono attraverso una singola tecnologia.
Quando valuto uno sviluppatore, non chiedo "Conosci TypeScript?" — chiedo "Raccontami di una volta in cui hai dovuto costruire qualcosa senza documentazione e con una deadline stretta." Voglio capire come ragionano, non quali tutorial hanno completato.
Ecco cosa conta davvero in un'assunzione di sviluppatori:
- Pensiero analitico: Sono in grado di scomporre un problema complesso in parti più piccole e risolvibili?
- Adattabilità: Hanno lavorato su stack diversi o sono bloccati in un unico ecosistema?
- Comunicazione: Riescono a spiegare decisioni tecniche a un founder non tecnico?
- Responsabilità: Si assumono la responsabilità quando le cose si rompono, o puntano il dito contro gli altri?
Un grande problem-solver che conosce Python può imparare TypeScript in poche settimane. Uno sviluppatore mediocre che "conosce React" scriverà comunque codice mediocre — solo in React.
Il parere di Michele
Una volta ho assunto un ingegnere backend che non aveva mai toccato React per guidare un rifacimento del frontend. In tre settimane, superava le prestazioni dell'"esperto React" che avevamo inizialmente assunto. La differenza? Capiva l'architettura, la gestione dello stato e i flussi utente a un livello fondamentale. Il framework era solo sintassi. Basta assumere per parole chiave. Assumete per intelligenza.
Errore #2: il mito dello "sviluppatore full-stack"
Ogni annuncio di lavoro di una startup dice "Sviluppatore Full-Stack". È diventato il titolo predefinito perché i founder pensano di avere due sviluppatori al prezzo di uno. In realtà, di solito si ottiene qualcuno che è mediocre in tutto ed eccellente in niente.
Voglio essere chiaro: i veri sviluppatori full-stack esistono. Ne ho conosciuti una manciata in oltre 12 anni e più di 100 prodotti. Sono ingegneri eccezionali che hanno passato un decennio a padroneggiare sia frontend che backend, capiscono database, DevOps, sicurezza e progettazione di sistemi. Sono anche incredibilmente rari e incredibilmente costosi.
Quello che di solito si ottiene assumendo uno "sviluppatore full-stack" è qualcuno che ha seguito un tutorial MERN stack, ha costruito una to-do app e ora elenca sia frontend che backend nel curriculum. Quello non è full-stack. È uno sviluppatore junior con una base di conoscenze ampia ma superficiale. È esattamente per colmare questo divario che abbiamo creato LD Academy: un programma gratuito di 30-60 giorni che trasforma junior acerbi in ingegneri pronti per la produzione prima ancora che tocchino il codice di un cliente.
Il modello dello sviluppatore a T
Quello che serve davvero sono sviluppatori a T — persone con competenze profonde in un'area (la barra verticale della T) e conoscenze operative in aree adiacenti (la barra orizzontale). Uno sviluppatore frontend che capisce il design delle API e sa leggere il codice backend. Uno sviluppatore backend che può costruire un'interfaccia decente quando serve.
Per le startup in fase iniziale, ecco il mio consiglio: partite con due specialisti forti invece di un generalista mediocre. Uno sviluppatore frontend senior e uno backend senior supereranno due sviluppatori "full-stack" ogni singola volta. Scriveranno codice migliore, saranno più veloci e produrranno meno bug.
Il parere di Michele
Ho salvato almeno una dozzina di progetti in cui lo "sviluppatore full-stack" aveva costruito un frontend funzionante ma un backend che non reggeva oltre 100 utenti. O, al contrario — un'API perfettamente architettata con un frontend che sembrava progettato nel 2009. La specializzazione non è un lusso. È il modo in cui si costruiscono prodotti che funzionano davvero. Se stai costruendo un team di sviluppo dedicato, costruiscilo attorno a specialisti complementari.
Errore #3: scegliere l'opzione più economica
Capisco il fascino. Sei una startup. La liquidità è limitata. Trovi uno sviluppatore su Upwork a $15/ora quando gli sviluppatori locali chiedono $80-150/ora. La matematica sembra ovvia. Non lo è.
Ecco la vera equazione che i founder non fanno mai prima di assumere:
Costo reale = Tariffa oraria × Ore impiegate × Moltiplicatore di rilavorazione
Vi mostro cosa succede nella pratica con uno scenario reale che ho incontrato l'anno scorso — una startup che aveva bisogno di un portale clienti:
| Fattore | Sviluppatore economico ($15/ora) | Sviluppatore senior ($100/ora) |
|---|---|---|
| Ore stimate | 400 ore | 160 ore |
| Costo iniziale | $6.000 | $16.000 |
| Rilavorazione necessaria | 60% delle funzionalità | 10% delle funzionalità |
| Ore di rilavorazione | 240 ore | 16 ore |
| Costo rilavorazione | $3.600 | $1.600 |
| Bug e manutenzione (6 mesi) | $4.000 | $800 |
| Costo totale | $13.600 | $18.400 |
| Time to market | 6 mesi | 2,5 mesi |
| Costo opportunità di 3,5 mesi di ritardo | Incalcolabile | — |
Lo sviluppatore "economico" è costato quasi quanto in termini di spesa diretta — e ha impiegato più del doppio del tempo. Se si considera il costo opportunità di 3,5 mesi di ritardo nel lancio sul mercato, l'assunzione economica è stata nettamente più costosa. Ho visto questo schema ripetersi decine di volte con startup che cercavano di esternalizzare lo sviluppo al ribasso.
Questo non significa che dobbiate assumere gli sviluppatori più costosi. Significa: valutate il costo per risultato, non il costo per ora. Un grande sviluppatore a $100/ora che consegna in quattro settimane costa meno di un cattivo sviluppatore a $15/ora che impiega quattro mesi e consegna qualcosa che deve essere ricostruito.
Il parere di Michele
Uno dei progetti più dolorosi che abbia mai ereditato era un'app fintech costruita da un team di sviluppatori a $12/ora in otto mesi. Il cliente pensava di aver risparmiato €100K. Ho dovuto dirgli che l'intero codebase doveva essere buttato via e riscritto da zero. Alla fine hanno speso 3 volte quello che avrebbero pagato se avessero assunto correttamente dal primo giorno. L'economico costa caro. Sempre.
Errore #4: nessun processo di valutazione tecnica
Ecco una verità scomoda: la maggior parte dei founder non è in grado di valutare gli sviluppatori. E questo va benissimo — non dovreste essere esperti tecnici per guidare una startup tecnologica. Ma significa che avete bisogno di un processo di valutazione strutturato, non di un'intuizione.
Quello che vedo invece sono founder che assumono sulla base di una conversazione di 30 minuti, un bel sito portfolio e un atteggiamento sicuro. La sicurezza non è competenza. Ho incontrato sviluppatori che parlavano brillantemente di architettura a microservizi e non erano in grado di scrivere una funzione pulita neanche a pagamento.
Un framework di valutazione pratico
Ecco il processo in tre fasi che uso quando aiuto le startup ad assumere sviluppatori:
- Progetto da completare a casa (2-4 ore): Date ai candidati un compito piccolo e realistico legato a quello che costruiranno effettivamente. Non un puzzle LeetCode — un problema reale. "Costruisci un semplice endpoint API che gestisca l'autenticazione utente e restituisca risultati paginati." Questo vi dice come strutturano il codice, gestiscono i casi limite e scrivono la documentazione.
- Sessione di code review (45 min): Esaminate insieme il loro lavoro. Chiedete perché hanno preso determinate decisioni. Dove migliorerebbero con più tempo? Come gestirebbero 10 volte il traffico? Questo rivela la profondità della loro comprensione e se hanno cercato una soluzione su Google o la capiscono davvero.
- Discussione di system design (30 min): Presentate una versione semplificata della vostra sfida di prodotto reale. "Dobbiamo costruire un sistema di notifiche in tempo reale per 50.000 utenti. Come lo affronteresti?" Non cercate la risposta perfetta — cercate un pensiero strutturato.
Campanelli d'allarme durante i colloqui tecnici che dovrebbero farvi desistere:
- Non riescono a spiegare il proprio codice del progetto da casa
- Diventano difensivi quando mettete in discussione le loro scelte tecniche
- Usano gergo tecnico in modo eccessivo ma non sanno semplificare i concetti quando richiesto
- Affermano di aver "costruito tutto" nella loro azienda precedente
- Non hanno domande sul vostro prodotto, architettura o team
Il parere di Michele
Se siete founder non tecnici, portate qualcuno di tecnico nel processo di valutazione. Non deve essere un CTO a tempo pieno — un Fractional CTO può aiutarvi a progettare il processo di valutazione, partecipare ai colloqui tecnici e assicurarsi che non stiate assumendo in base al carisma invece che alla competenza. Questa singola decisione può farvi risparmiare sei cifre.
Errore #5: assumere troppi, troppo in fretta
Avete appena chiuso la vostra Serie A. Avete $3M in banca. Il board vuole vedere una crescita rapida. Così passate da 2 a 12 sviluppatori in tre mesi. Congratulazioni — avete appena garantito che i prossimi sei mesi saranno più lenti, non più veloci.
Questa è la Legge di Brooks in azione: "Aggiungere risorse umane a un progetto software in ritardo lo ritarda ulteriormente." Frederick Brooks lo scrisse nel 1975, ed è ancora una delle verità più ignorate del nostro settore. Ogni nuovo sviluppatore ha bisogno di onboarding. Ogni nuovo sviluppatore crea più overhead di comunicazione. Ogni nuovo sviluppatore ha bisogno di contesto che esiste solo nella testa del team esistente.
Ecco la matematica che i manager ignorano: con 3 sviluppatori si hanno 3 canali di comunicazione. Con 6 sviluppatori, 15. Con 12 sviluppatori, 66. L'overhead di comunicazione cresce esponenzialmente mentre l'output cresce linearmente — se va bene.
La dimensione giusta del team per ogni fase
- Pre-product-market fit (fase MVP): 2-3 sviluppatori al massimo. Serve velocità e flessibilità, non organico.
- Post-PMF, pre-scalabilità: 4-6 sviluppatori, organizzati in 1-2 piccoli squad. Focus sulla costruzione corretta del prodotto core.
- Fase di crescita: Scalare i team con incrementi di 2-3 persone ogni 6-8 settimane. Dare a ogni gruppo il tempo di integrarsi prima di aggiungerne altri.
- Fase di scala: 15+ sviluppatori, organizzati in squad autonomi di 4-6 con confini di ownership chiari.
La regola d'oro: non raddoppiate mai le dimensioni del team in un singolo trimestre. Se avete 4 sviluppatori, non assumetene più di 4 nei prossimi tre mesi. Idealmente, aggiungete 2-3 e lasciate che si stabilizzino.
Il parere di Michele
Ho lavorato con una startup che è passata da 3 a 15 sviluppatori in due mesi. La loro velocità non è aumentata — è calata del 40%. I 3 sviluppatori originali passavano tutto il tempo a fare onboarding, code review e a rispondere alle domande invece di costruire funzionalità. Ci sono voluti sei mesi per riprendersi. Fate crescere il team come fate crescere un prodotto: in modo iterativo, con cicli di feedback e con pazienza.
Errore #6: ignorare cultura e comunicazione
Ho visto sviluppatori tecnicamente brillanti distruggere team. Non per il loro codice — per il loro atteggiamento. Sminuivano le idee degli altri. Si rifiutavano di documentare qualsiasi cosa. Scrivevano codice che solo loro potevano capire, creando un single point of failure che teneva l'intera azienda in ostaggio.
L'abilità tecnica senza compatibilità culturale è un problema, non un vantaggio. E nell'era del lavoro da remoto, la comunicazione non è solo un nice-to-have — è la competenza più importante del team.
Come si presenta la comunicazione nella pratica
Per i team di sviluppo remoti e ibridi — che ormai sono la maggioranza — queste sono le competenze comunicative che valuto:
- Chiarezza nella scrittura: Sanno scrivere una descrizione chiara di una pull request? Sanno documentare una decisione tecnica in modo che qualcun altro possa capirla sei mesi dopo?
- Disciplina asincrona: Forniscono abbastanza contesto nei messaggi in modo che il destinatario non abbia bisogno di un follow-up? O inviano "Ehi, possiamo parlare?" senza alcun contesto?
- Aggiornamenti proattivi: Segnalano i blocchi prima che diventino crisi? O scoprite che qualcosa è bloccato tre giorni dopo?
- Feedback costruttivo: Sanno fare una code review del codice altrui senza essere condiscendenti? Sanno ricevere feedback senza mettersi sulla difensiva?
Uso quello che chiamo il "test di passaggio di consegne asincrono": immaginate che questo sviluppatore completi una funzionalità complessa il venerdì pomeriggio e vada in vacanza per due settimane. Un altro sviluppatore del team potrebbe riprendere il lavoro il lunedì basandosi solo sulla descrizione della PR, i messaggi dei commit e la documentazione? Se la risposta è no, avete un problema di comunicazione.
Il parere di Michele
Una volta ho dovuto lasciare andare lo sviluppatore tecnicamente più talentuoso con cui abbia mai lavorato. Il suo codice era elegante, le sue soluzioni brillanti, e risolveva in ore problemi che ad altri richiedevano giorni. Ma si rifiutava di partecipare alle code review, derideva gli sviluppatori junior che facevano domande e non documentava mai nulla. Quando alla fine se ne è andato, ci sono voluti tre sviluppatori e quattro mesi per capire il suo codice abbastanza bene da mantenerlo. La cultura non è qualcosa di soft. È strutturale.
Errore #7: nessun onboarding, nessuna documentazione, nessun processo
Passate settimane a trovare lo sviluppatore giusto. Negoziate il compenso. Firmate il contratto. E poi al primo giorno dite: "Ecco la repo. Fammi sapere se hai domande." Quello non è onboarding. È abbandono.
La ricerca mostra costantemente che gli sviluppatori che non ricevono un onboarding strutturato hanno 2-3 volte più probabilità di andarsene entro i primi 90 giorni. E quando se ne vanno, si ricomincia da capo — meno il tempo, il denaro e lo slancio persi.
Il processo di onboarding minimo indispensabile
Non serve un programma di formazione aziendale. Servono queste cinque cose:
- Documento di panoramica dell'architettura: Una singola pagina che spiega come funziona il sistema, quali servizi esistono, come comunicano e dove risiede il codice. Aggiornatelo ogni trimestre.
- Guida al setup locale: Istruzioni passo-passo per far funzionare l'ambiente di sviluppo da zero. Se ci vogliono più di 30 minuti, sistematelo.
- Lista di task per la prima settimana: Da tre a cinque task piccoli e ben definiti che permettano al nuovo sviluppatore di toccare codice reale, inviare PR reali e ricevere feedback dal team.
- Buddy designato: Una persona del team che sia esplicitamente responsabile di rispondere alle domande durante le prime due settimane. Non "tutti possono aiutare" — una persona specifica.
- Check-in a 30 giorni: Una conversazione strutturata su cosa funziona, cosa è confuso e cosa potrebbe essere migliorato — sul processo, non solo sulla persona.
Questo richiede pochi giorni di setup una tantum e vi fa risparmiare mesi di frustrazione per ogni nuova assunzione. Ancora più importante, la documentazione interna è una strategia di retention. Gli sviluppatori che capiscono il sistema su cui lavorano sono più produttivi, più sicuri di sé e più propensi a restare.
Le aziende con il più basso turnover di sviluppatori che ho visto hanno tutte una cosa in comune: un'eccellente documentazione interna. Non perfetta — solo abbastanza buona perché un nuovo sviluppatore possa diventare produttivo entro la prima settimana.
Il parere di Michele
In una delle mie venture, abbiamo ridotto il tempo di ramp-up dei nuovi sviluppatori da 6 settimane a 5 giorni investendo due settimane nella documentazione di onboarding. È una riduzione del 90%. Il ROI è stato assurdo — abbiamo risparmiato circa 4 settimane di stipendio sprecato per ogni singola assunzione successiva. Se pensate di non avere tempo per scrivere documentazione, sicuramente non avete tempo per continuare a sostituire sviluppatori che se ne vanno perché sono frustrati e persi.
La matrice di assunzione: cosa cercare davvero
Dopo centinaia di assunzioni, ho sintetizzato la valutazione degli sviluppatori in questa matrice ponderata. Usatela come framework di punteggio durante il vostro processo di colloquio — valutate ogni criterio da 1 a 5 e moltiplicate per il peso:
| Criterio | Peso | Come valutare |
|---|---|---|
| Capacità di problem-solving | 25% | Progetto da casa + discussione dal vivo |
| Competenze comunicative | 20% | Chiarezza scritta e verbale, disciplina asincrona |
| Esperienza rilevante | 15% | Progetti passati in domini o a scale simili |
| Profondità tecnica | 15% | Comprensione approfondita dei concetti fondamentali oltre i framework |
| Compatibilità culturale e responsabilità | 10% | Responsabilità, iniziativa, collaborazione nel team |
| Adattabilità | 10% | Storico di apprendimento di nuove tecnologie e domini |
| Corrispondenza tech stack specifico | 5% | Conoscenza attuale del vostro stack esatto |
Notate che la conoscenza tecnologica specifica è solo il 5% della valutazione. È intenzionale. Tutto il resto in questa lista è più difficile da insegnare e più predittivo del successo a lungo termine.
Uno sviluppatore che ottiene un punteggio alto in problem-solving, comunicazione e adattabilità ma non ha mai toccato il vostro tech stack supererà sempre uno che conosce l'intero stack ma non possiede queste capacità fondamentali. Ogni. Singola. Volta.
State per assumere sviluppatori? Parliamone prima
Ogni errore di assunzione in questa lista è uno che ho commesso io stesso all'inizio della mia carriera o che ho visto commettere a un cliente — e di cui ho poi ripulito i danni. La differenza tra un team di sviluppo di successo e un pozzo di soldi dipende quasi sempre da come vengono fatte le prime tre o quattro assunzioni.
Se siete founder che si preparano a costruire un team di sviluppo, o se avete già assunto e le cose non vanno bene, posso aiutarvi. Come Fractional CTO, ho progettato processi di assunzione, valutato candidati e strutturato team per startup in tutta Europa e Medio Oriente.
Una consulenza di 30 minuti può farvi risparmiare mesi di costosi tentativi ed errori. Esamineremo la vostra situazione attuale, identificheremo dove siete vulnerabili e costruiremo una strategia di assunzione che funzioni davvero.
“Lo sviluppatore più costoso che assumerete mai è quello sbagliato. Il secondo più costoso è quello giusto che non avete preparato per il successo.”
— Michele Cimmino