CTO, engineering manager o fractional: chi serve davvero al tuo team

CTO, engineering manager o fractional? Chi serve davvero al tuo team

Il momento in cui la domanda arriva è quasi sempre lo stesso: il prodotto funziona, il team ha superato le cinque o sei persone e le decisioni tecniche hanno smesso di essere rapide. A quel punto il founder cerca un job title: CTO, head of engineering, engineering manager, fractional. Il job title è l'ultima domanda da porsi. Prima viene la diagnosi, perché i tre ruoli curano malattie diverse e assumere quello sbagliato costa quanto un anno di sviluppo. In questo articolo: i sintomi, le soglie di crescita, i numeri del mercato italiano ed europeo e la distinzione tra fractional e interim che quasi nessuno spiega in italiano.

Se stai leggendo questo articolo, probabilmente ti sei ritrovato a fare una di queste due ricerche: "quando serve un CTO" oppure "fractional CTO cosa fa". Il problema di entrambe è che partono dal job title. Un job title è ambiguo: il CTO di una startup di tre persone scrive codice tutti i giorni, il CTO di una banca digitale passa le giornate in riunioni con il board, gli investitori e gli stakeholder, e tra i due esistono almeno quattro figure intermedie che portano nomi diversi in ogni azienda. Chiedere a un founder "ti serve un CTO?" è come chiedere a un paziente "ti serve un chirurgo?": prima serve capire che cosa non va.

La domanda utile è un'altra: dove si sta bloccando la tua startup? La direzione tecnologica, che decide cosa costruire e perché, e la gestione dell'esecuzione, che decide come e quando consegnare, entrano in crisi in momenti diversi, con sintomi e rimedi diversi. Confonderle è l'errore più costoso che un founder possa fare in questa fase, perché porta ad assumere un profilo forte che risolve il problema sbagliato.

Tre ruoli, tre direzioni

Il modo più pulito per separare i ruoli è guardare a quale domanda risponde ciascuno. Il CTO risponde a "cosa costruire e perché": guarda fuori dall'azienda e avanti nel tempo, verso il mercato, il board, gli investitori, i clienti. Le sue responsabilità tipiche riguardano le scelte architetturali, i settori regolamentati, la roadmap tecnologica da uno a tre anni e la gestione del rischio. L'head of engineering e l'engineering manager rispondono a "come e quando": guardano dentro l'azienda, al processo di sviluppo, alla qualità delle consegne, alla crescita delle persone. L'engineering manager gestisce direttamente da sei a otto sviluppatori, fa i colloqui individuali, sblocca il team ogni giorno, pianifica gli sprint.

Nelle realtà italiane early stage questi ruoli vivono compressi in una persona sola, quasi sempre il founder tecnico o lo sviluppatore più senior. Va bene, finché funziona. Il problema è capire quando smette di funzionare e il segnale è quasi sempre lo stesso: chi guidava la direzione si è ritrovato a gestire l'esecuzione, o viceversa e nessuna delle due cose viene più fatta bene.

Due storie raccontano bene questa separazione. Calvin French-Owen, cofondatore di Segment, racconta la propria transizione: founder che scriveva gran parte del codice e restava reperibile notte e giorno, poi leader che delega pezzo per pezzo, fino ad assumere un VP of Engineering che prendesse in carico l'organizzazione. Il CTO, nella sua descrizione, non è il custode del codice: è lo strumento con cui l'azienda fa recruiting tecnico, costruisce autorevolezza sul mercato e parla con i clienti. Patrick Kua, CTO di N26 durante l'iper-crescita della banca, ha separato la gestione delle persone dal ruolo di Tech Lead, introducendo gli engineering manager, e quando il ruolo di CTO è diventato prevalentemente operativo e legato al reporting è passato lui stesso a Chief Scientist. I ruoli non sono traguardi da conquistare: sono funzioni che si accendono e si spengono al ritmo della crescita.

La diagnosi parte dai sintomi

Un founder vede i sintomi molto prima di leggere un organigramma. La lettura è semplice: i sintomi legati all'esecuzione indicano un problema manageriale; quelli legati alla direzione, un problema strategico. Ecco le due liste.

Sintomi che puntano all'engineering manager

  • I rilasci rallentano: i tempi di consegna si allungano, la quota di codice riscritto aumenta, ogni modifica piccola diventa grande.
  • Il backlog di bug e funzionalità cresce più veloce della capacità di consegnare, e il morale scende di pari passo.
  • Il founder o il tech lead gestisce direttamente otto o più persone: i colloqui individuali sono spariti, la pianificazione degli sprint è diventata improvvisazione.
  • Gli sviluppatori non crescono: niente mentoring, nessuna pianificazione di carriera, e le prime dimissioni arrivano tra le persone migliori.
  • La qualità viene tagliata sistematicamente per rispettare le scadenze: il debito tecnico è una scelta che si ripete ogni sprint, non un incidente isolato.

Sintomi che puntano al CTO

  • Le riscritture e i dibattiti architetturali si trascinano da mesi, e nessuno ha l'autorità per chiuderli.
  • C'è il timore concreto che l'architettura non regga una crescita di dieci volte, ma nessuna roadmap per affrontarla.
  • Il founder tecnico ha raggiunto il proprio limite direzionale: l'organizzazione viene guidata alla giornata, senza una traiettoria.
  • Si avvicina un round di finanziamento e gli investitori chiedono una roadmap tecnologica credibile, con audit e due diligence.
  • Arrivano clienti o settori regolamentati, che pretendono un responsabile tecnico nominato e risposte su sicurezza e conformità.
  • Le fondamenta del sistema non reggono più: il degrado è strutturale, non il frutto di scelte forzate.

C'è un segnale che merita un'attenzione speciale, perché unisce le due liste: il debito tecnico. Se il debito nasce da scelte forzate sotto scadenze irrealistiche, è un problema di processo e di governo del lavoro, quindi manageriale. Se il debito nasce da fondamenta sbagliate, stack inadeguato o decisioni architetturali prese senza esperienza, è un problema di direzione. Il primo si cura mettendo ordine nel flusso di lavoro; il secondo si cura ridisegnando le fondamenta. Capire quale dei due hai davanti è quasi sempre il passo più prezioso di tutto il processo.

I quattro stati di salute del team

Will Larson, che ha guidato team a Digg, Uber e Stripe, ha definito un vocabolario che rende la diagnosi ancora più precisa. Un team di sviluppo si trova sempre in uno di quattro stati. Il primo è falling behind, l'accumulo di arretrati: ogni settimana il backlog è più lungo della settimana prima, tutti lavorano moltissimo e il progresso non si vede. Il secondo è treading water, a galla: il lavoro critico si consegna, ma il debito tecnico non scende e i nuovi progetti non partono. Il terzo è repaying debt, il rientro del debito: il team trova il margine per ristrutturare e i benefici cominciano a comporsi. Il quarto è innovating: il debito è sostenibile e la maggior parte dell'energia va a soddisfare nuovi bisogni degli utenti.

Il punto di Larson, che è anche il cuore di questo articolo, è che ogni stato richiede un rimedio diverso. Un team in falling behind ha bisogno di capacità e di protezione dalle interruzioni: un intervento manageriale. Un team in treading water ha bisogno di ridurre il lavoro in corso e finire più cose: ancora manageriale. Un team in repaying debt ha bisogno che il refactoring punti nella direzione giusta, e qui serve la guida architetturale, direzionale. Un team in innovating ha bisogno di una roadmap che trasformi il margine in vantaggio competitivo: direzionale di nuovo. La sequenza è semplice e risponde da sola alla domanda sul ruolo: gli stati più critici richiedono un engineering manager, quelli più avanzati un CTO.

C'è però una cosa da dire con onestà: questi rimedi richiedono tempo. Larson insiste sul fatto che i sistemi accumulano mesi di attrito e che toglierlo richiede pazienza, non colpi di genio. Nessun consulente, fractional o no, accelera quei tempi; il suo valore è evitare che tu scelga il rimedio sbagliato e perda altri due trimestri.

Le soglie che contano

Oltre ai sintomi esistono numeri, e sono sorprendentemente stabili nelle organizzazioni sane. Un manager segue da sei a otto ingegneri: con meno di quattro persone da seguire finisce per fare il tecnico anziché il manager, con più di otto o nove si riduce a spegnere incendi. Sotto le quattro persone, un team è spesso solo un insieme di individui con un nome collettivo, fragile al primo abbandono. Una rotazione di reperibilità 24/7 richiede otto persone per essere sostenibile. Un manager di manager segue da quattro a sei manager. Sono numeri di aziende, non di budget: valgono a Berlino come a Roma.

Sul fronte della direzione le soglie riguardano il volume delle decisioni strategiche. Finché il team resta sotto le dieci, dodici persone, le decisioni architetturali che contano sono poche al mese: poche ore alla settimana di direzione esperta bastano a coprirle, ed è il territorio naturale del fractional. Tra le quindici e le venti persone il ruolo unico si spacca: la visione e la gestione richiedono persone diverse, CTO e head of engineering affiancati. Oltre le venti o trenta persone, o quando la tecnologia è essa stessa il prodotto, il carico direzionale supera le venti ore settimanali e il CTO full-time diventa la forma corretta. Larson descrive queste soglie come un aiuto a pensare, non una camicia di forza, ma chi le ignora le ritrova tutte, di solito nel momento peggiore.

Quanto costa ciascuna via

Le stime che seguono sono ordini di grandezza, non preventivi: euro, Italia ed Europa salvo indicazione diversa, basati su benchmark di mercato pubblici e verificati a settembre 2026.

Un CTO assunto in Italia ha una retribuzione media di circa 76.000 euro lordi l'anno secondo PayScale, con un range che va dai 36.000 euro delle prime fasi, dove lo stipendio è compensato dall'equity, fino oltre i 150.000 euro delle scale-up. Al costo va aggiunto il carico contributivo, che porta il costo azienda intorno al trenta per cento in più. Un CTO fractional in Europa costa in media tra 4.000 e 12.000 euro al mese, per due o quattro giornate di lavoro. Su base annua sono tra 48.000 e 120.000 euro lordi, senza TFR, contributi a carico dell'azienda né equity. I progetti a termine, come un audit architetturale o una due diligence tecnica per un round, si muovono tra i 15.000 e i 75.000 euro.

C'è però un altro numero che merita attenzione: il costo di un'assunzione sbagliata. Negli Stati Uniti, un CTO full-time interrotto dopo sei mesi costa tra i 150.000 e i 250.000 dollari tra stipendio, buonuscita e ricerca del sostituto; nel Regno Unito la stima corrente per correggere un CTO sbagliato arriva a due volte lo stipendio annuo. Le commissioni di headhunting oscillano tra il quindici e il trenta per cento del salario del primo anno, e un CTO permanente impiega da tre a sei mesi prima di rendere a pieno regime. A questi costi si aggiunge quello invisibile e più grave: il periodo senza leadership tecnica, in cui le decisioni architetturali sbagliate entrano nel sistema e ci restano per anni. Fermare in tempo una riscrittura sbagliata, con una guida esperta, ripaga da solo due anni di fractional.

La logica economica del fractional, vista così, è semplice: non è uno sconto sul CTO, ma l'acquisto della quantità di direzione che serve in quella fase. Sotto le soglie descritte sopra, comprare direzione full-time vuol dire bruciare cassa; sopra quelle soglie, accontentarsi del part-time vuol dire correre un rischio che non serve.

Fractional, interim e full-time non sono sinonimi

In Italia queste tre parole vengono spesso usate senza distinzione, con conseguenze pratiche su aspettative, contratti e costi. Il fractional è part-time continuativo: da una a quattro giornate a settimana, per mesi o anni. Fa direzione: roadmap tecnologica, scelte di stack, piano di assunzioni, audit, rapporto con gli investitori. Non gestisce l'operatività quotidiana, e questo è un requisito, non un limite: chi ti vende un fractional che fa anche gli sprint del team ti sta vendendo qualcos'altro. L'interim è full-time temporaneo: tre, sei, dodici mesi, in genere dopo l'uscita improvvisa di un CTO, durante una crisi o come ponte verso l'assunzione definitiva. Prende l'operatività per intero e la riconsegna stabilizzata. Il full-time è la forma permanente, adatta quando si superano le soglie di crescita che abbiamo descritto.

La domanda «mi serve un fractional?» va quindi divisa in due: serve direzione o serve esecuzione? Se serve direzione, con quale volume? Se la risposta è direzione leggera e continua, pre-seed o seed, team sotto le dieci persone, founder non tecnico o round in preparazione, il fractional è la forma corretta. Se la risposta è una crisi operativa da sedare, serve un interim. Se il problema è che il team non consegna, serve un engineering manager, e chiamarlo fractional CTO non cambierà la diagnosi.

Quando la risposta non è un ruolo nuovo

C'è un caso, sorprendentemente frequente, che nessuno dei tre ruoli risolve: manca il metodo. Il team consegna o non consegna in base all'umore della settimana, le specifiche non esistono, la review del lavoro non avviene mai, il PoC è diventato produzione senza che nessuno lo decidesse. Qui la carenza non è di leadership ma di processo, e il rimedio è mettere ordine nel come si lavora prima di decidere chi deve guidarlo. È il motivo per cui il mio metodo di lavoro inizia da discovery e specifiche scritte, e non da un ruolo: in quasi tutte le situazioni che mi arrivano, la domanda iniziale del founder era un job title e la risposta era un passaggio mai fatto.

Vale la stessa onestà sugli altri due casi tipici. Se l'MVP è una demo che deve diventare prodotto, il problema è la distanza tra prototipo e produzione: un intervento architetturale mirato, di quelli che ho descritto parlando di MVP costruiti con i coding agent, non un organigramma. Se il problema è una persona che non cresce, serve mentoring, non un CTO. E se il founder tecnico non vuole delegare, nessuna assunzione reggerà: prima si risolve quella riluttanza.

In pratica

La diagnosi si può fare in quattro passi. Primo: dai un nome allo stato del tuo team, usando i quattro stati di Larson, perché il rimedio dipende da quello più che da ogni altra cosa. Secondo: conta le persone e le distanze. Se gestisci otto sviluppatori da solo, il tuo problema urgente è manageriale anche se il tuo sogno si chiama CTO. Terzo: guarda il calendario strategico dei prossimi sei mesi: un round, un cliente, una riscrittura decisiva spostano la priorità verso la direzione. Quarto: solo ora scegli il job title, e poi il contratto: fractional se serve direzione continua e leggera, interim se è una crisi da gestire, full-time quando le soglie sono superate, engineering manager se il blocco è nell'esecuzione.

Il job title arriva per ultimo. Chi te ne propone uno per primo, senza fermarsi a chiedere in che stato è il tuo team e che cosa si è rotto, probabilmente ti sta vendendo la propria disponibilità. Un buon consulente, fractional o no, comincia dalla diagnosi e accetta anche la risposta che gli fa perdere il lavoro: che forse non ti serve lui, ti serve un metodo.

Fonti

Easter egg

Il numero nascosto di questo articolo è l'otto: otto persone per un team stabile, otto per una reperibilità sostenibile, otto al massimo per un manager. Will Larson arriva a dire che dividere un'organizzazione per otto ne rivela il futuro. E a N26, quando Patrick Kua ha dovuto separare la gestione delle persone dai Tech Lead, la parola d'ordine era di nuovo la stessa: un manager per otto. Se nella tua azienda quel rapporto non esiste ancora, ora sai come calcolarlo.