Da senior engineer a engineering manager: guida alla transizione
Scritto da Luigi · Giugno 2026 · 18 min di lettura ·
Hai ottenuto la promozione a engineering manager. Oppure la stai valutando seriamente. In entrambi i casi, stai guardando un ruolo che non somiglia a niente di quello che ti ha portato fin qui. Dopo 25 anni nel settore tech e 11 anni di leadership di team e programmi cross-funzionali in una big tech company, posso dirti che questa è una delle transizioni professionali più sottovalutate e più disorientanti che esistano.
Non ho mai avuto il titolo formale di "manager" nella mia carriera. Ma ho guidato team di ingegneri, programmi che coinvolgevano decine di persone, e oggi accompagno professionisti tech che stanno affrontando esattamente questo passaggio. Quello che segue non è teoria accademica: è ciò che osservo funzionare (e non funzionare) nei percorsi reali delle persone che seguo.
Perché questa transizione è diversa da tutte le altre
Nella maggior parte delle carriere, una promozione significa fare la stessa cosa a un livello più alto. Un avvocato junior diventa senior e continua a fare l'avvocato. Un chirurgo specializzando diventa primario e continua a operare. Nel tech, il passaggio da individual contributor a manager è qualcosa di radicalmente diverso: stai cambiando mestiere.
Ci sono tre motivi per cui questa transizione è unica nel suo genere.
Le competenze che ti hanno portato qui non ti servono più
Per anni il tuo valore si misurava dalla qualità del codice che consegnavi, dall'architettura dei sistemi che progettavi, dalla velocità con cui risolvevi problemi complessi. Come engineering manager, nessuna di queste competenze è il tuo deliverable principale. Il tuo output diventa l'output del tuo team. E interiorizzare questa trasformazione richiede mesi, non giorni.
La crisi di identità è reale
Molti ingegneri costruiscono la propria identità professionale attorno all'essere "quello bravo tecnicamente." Quando smetti di scrivere codice ogni giorno, perdi una parte di chi sei. Nei miei percorsi di coaching, vedo professionisti brillanti attraversare settimane di autentico disorientamento: non si sentono più ingegneri, ma non si sentono ancora manager. Questo limbo è normale, ma va attraversato con consapevolezza.
Le metriche di successo diventano invisibili
Come IC, il feedback è immediato: la build passa, la PR viene approvata, il deploy funziona. Come manager, i risultati del tuo lavoro si manifestano in settimane o mesi. Hai fatto un buon 1:1 oggi? Lo saprai tra tre mesi, quando quella persona crescerà. Hai preso una buona decisione organizzativa? Lo vedrai nel prossimo trimestre. Questa latenza crea ansia in chi è abituato a loop di feedback rapidi.
Cosa cambia davvero nei primi 90 giorni
I primi 90 giorni definiscono le basi della tua credibilità come manager. Non perché devi dimostrare qualcosa, ma perché è il periodo in cui il team decide se fidarsi di te nel nuovo ruolo. Ecco cosa succede e su cosa concentrarti in ogni fase.
Settimana 1-2: osserva e ascolta
La tentazione più forte nelle prime due settimane è agire. Hai visto problemi come IC e ora hai il potere di risolverli. Resisti. Il tuo unico obiettivo in questa fase è capire il contesto da una prospettiva che prima non avevi.
- Fai 1:1 lunghi con ogni persona del team. Non 30 minuti di status update: un'ora di conversazione aperta. Chiedi cosa funziona, cosa non funziona, cosa cambierebbero se potessero. Prendi appunti dettagliati.
- Mappa le dipendenze organizzative. Chi sono gli stakeholder del tuo team? Da chi dipendete? Chi dipende da voi? Quali decisioni prende il tuo skip-level e quali delega a te?
- Capisci la storia recente. Ci sono stati conflitti? Promozioni mancate? Persone che se ne sono andate di recente? Ogni team ha un contesto emotivo che non trovi nelle wiki.
Settimana 3-4: stabilisci le routine
Nella seconda coppia di settimane, inizia a creare la struttura del tuo lavoro manageriale. Non stai ancora cambiando nulla: stai costruendo le fondamenta su cui poi agirai.
- Imposta cadenza e formato dei 1:1. Settimanali, 30-45 minuti, con un template leggero che copre: come stai, su cosa stai lavorando, dove sei bloccato, come posso aiutarti.
- Allineati con il tuo manager. Cosa si aspetta da te nei primi 90 giorni? Quali sono le priorità del team dal suo punto di vista? Dove puoi prendere decisioni autonome e dove devi consultare?
- Identifica le prime vittorie facili. Non grandi cambiamenti, ma piccoli miglioramenti che il team chiedeva da tempo e che nessuno aveva il mandato di fare. Rimuovere un meeting inutile, risolvere un blocco cross-team, chiarire una ownership ambigua.
Mese 2-3: agisci con intenzionalità
Dopo un mese di osservazione e un mese di strutturazione, hai abbastanza contesto per iniziare a fare cambiamenti informati. Questo è il momento in cui la tua leadership inizia a essere visibile.
- Affronta il problema più evidente. C'è quasi sempre una cosa che tutti nel team sanno essere rotta ma che nessuno ha mai affrontato. Potrebbe essere un processo, una dipendenza esterna, o una conversazione difficile con un'altra organizzazione. Prendila in carico.
- Dai il primo feedback costruttivo. Se c'è qualcuno che sta underperformando, il mese 2-3 è il momento giusto per la prima conversazione diretta. Hai avuto abbastanza tempo per osservare pattern, non stai reagendo a un singolo episodio.
- Comunica la tua visione per il team. Non un documento di 20 pagine: una direzione chiara. "Ecco dove siamo, ecco dove voglio che arriviamo nei prossimi 6 mesi, ecco cosa chiedo a ognuno di voi." Trasparenza e chiarezza costruiscono fiducia.
I 5 errori più comuni (e come evitarli)
Nei percorsi di coaching che faccio con professionisti in transizione, vedo gli stessi pattern ripetersi. Eccone cinque che puoi evitare se li riconosci in anticipo.
1. Micromanagement del codice
Il nuovo manager che continua a entrare nelle code review per riscrivere implementazioni, che prende ticket dallo sprint quando le cose rallentano, che passa ore a leggere ogni pull request. Sembra produttivo. Non lo è.
Stai facendo male il tuo vecchio lavoro (perché non hai più il contesto per farlo bene) mentre non fai affatto quello nuovo. Peggio: stai mandando un messaggio chiaro al team: "non mi fido di voi." Il risultato è che le persone migliori se ne andranno, perché nessun ingegnere senior vuole essere micromanaged.
Come evitarlo: stabilisci una regola personale. Nelle prime 4 settimane, non toccare il codice. Zero. Se vedi qualcosa che non ti convince in una review, scrivi un commento. Non riscrivere tu. Dopo il primo mese, rivaluta: il tuo coinvolgimento tecnico dovrebbe essere strategico (architettura, trade-off, direzione) non operativo (questa funzione andrebbe scritta così).
2. Non delegare decisioni
Questo è un errore che conosco bene perché l'ho commesso io stesso per anni. Guidando team e programmi cross-funzionali, mi sono trovato a lungo nella trappola di voler prendere ogni decisione tecnica, convinto che fosse il modo più veloce per ottenere il risultato giusto. Lo era, forse, nel breve termine. Ma nel medio termine stavo creando un collo di bottiglia e impedendo alle persone intorno a me di sviluppare il proprio giudizio.
La delega delle decisioni non è pigrizia: è investimento. Ogni decisione che prendi tu è una decisione che qualcuno del tuo team non ha imparato a prendere. Col tempo, diventi indispensabile nel senso peggiore del termine: il team non funziona senza di te, e tu non puoi crescere perché sei inchiodato all'operatività.
Come evitarlo: per ogni decisione che ti arriva, chiediti: "questa persona potrebbe prenderla da sola se le dessi il contesto giusto?" Se la risposta è sì, dai il contesto e lascia che decida. Accetta che farà scelte diverse dalle tue. Molte saranno ugualmente valide. Alcune saranno errori da cui imparerà.
3. Confondere leadership con controllo
Introdurre processi, richiedere approvazioni, creare dashboard per monitorare ogni aspetto del lavoro. I nuovi manager spesso confondono visibilità con controllo, e controllo con leadership. Non sono la stessa cosa.
La leadership è creare le condizioni perché persone capaci facciano il loro lavoro migliore. Il controllo è assicurarti che facciano esattamente quello che faresti tu. Il primo scala. Il secondo no.
Come evitarlo: prima di aggiungere qualsiasi processo, chiediti: "quale problema specifico risolve, e quel problema ci sta davvero facendo male?" Se non riesci a nominare un problema concreto, non aggiungere il processo. Se riesci a nominarlo, chiedi al team come vorrebbero risolverlo prima di imporre la tua soluzione.
4. Non avere un mentor
Molti nuovi manager pensano di dover capire tutto da soli. È un retaggio della cultura IC, dove l'autonomia è un valore. Ma il management è un mestiere con sfumature che non puoi imparare solo dalla teoria. Hai bisogno di qualcuno che ci sia passato, con cui confrontarti quando non sai come gestire una situazione.
Un mentor può essere un altro manager nella tua azienda, qualcuno in un'azienda diversa, o un coach professionista. L'importante è che abbia esperienza reale nel gestire persone in contesti tech e che tu possa parlargli con onestà, senza filtri politici.
Come evitarlo: entro le prime due settimane nel nuovo ruolo, identifica almeno una persona con cui avere conversazioni regolari (bisettimanali o mensili) sul tuo percorso come manager. Non aspettare di avere un problema: costruisci la relazione prima di averne bisogno.
5. Ignorare le dinamiche con gli ex colleghi
Questo merita una sezione a parte (la trovi sotto), ma vale la pena nominarlo qui: fingere che nulla sia cambiato con le persone che fino a ieri erano i tuoi pari è una strategia che fallisce sempre. La relazione è cambiata. Ignorarlo non lo rende meno vero, lo rende solo più scomodo per tutti.
Gestire gli ex colleghi che ora riportano a te
Questa è la sfida emotivamente più complessa della transizione. Ieri eravate pari: stessa seniority, stessi meeting, stesse lamentele sul management. Oggi prendi decisioni sul loro lavoro, scrivi le loro performance review, influenzi le loro promozioni. È un cambiamento enorme, e va affrontato con trasparenza.
Il risentimento è normale
Qualcuno nel team pensava che quella promozione spettasse a lui. Qualcun altro non voleva un manager interno e avrebbe preferito un esterno. Altri ancora sono semplicemente a disagio con il cambio di dinamica. Tutto questo è legittimo e prevedibile.
Non puoi eliminare questi sentimenti, ma puoi gestirli. La cosa peggiore che puoi fare è ignorarli o, peggio, cercare di compensarli essendo eccessivamente permissivo. "Ti lascio fare quello che vuoi perché mi sento in colpa per la situazione" non è leadership: è evitamento.
La conversazione da avere nel primo 1:1
Con ogni persona del team, nel primo 1:1 dopo la transizione, affronta l'elefante nella stanza direttamente. Non serve un discorso preparato, ma qualcosa come:
"So che questa situazione è strana. Fino a ieri eravamo colleghi allo stesso livello. La nostra relazione cambierà, e voglio essere trasparente su questo. Il mio lavoro adesso è aiutarti a crescere e aiutare il team a funzionare. Non ho tutte le risposte e farò errori. Ti chiedo due cose: dimmi quando sbaglio, e dammi il beneficio del dubbio mentre imparo."
Stabilire i confini senza alienare
I confini più importanti da stabilire presto:
- Le informazioni confidenziali restano tali. Avrai accesso a informazioni su compensation, piani organizzativi, situazioni personali. Non puoi più condividerle come facevi quando eravate colleghi.
- Il feedback diventa formale. Prima potevi dire "questo codice fa schifo" in modo goliardico. Ora le tue parole hanno un peso diverso. Un commento che prima era tra pari ora viene da qualcuno che scrive la tua review.
- Le relazioni sociali cambiano. Non devi smettere di andare a pranzo con il team, ma sii consapevole che la dinamica è diversa. Quello che dici in modo informale verrà interpretato come "la posizione del manager."
I professionisti che seguo spesso mi chiedono: "ma devo smettere di essere loro amico?" La risposta è no, ma devi accettare che la relazione avrà una dimensione in più. Puoi essere amichevole, rispettoso e genuino senza essere il confidente a cui raccontano tutto. E quando arriverà il momento di dare feedback difficile o prendere decisioni impopolari, dovrai farlo comunque.
Le metriche che contano per un nuovo manager
Come IC, le tue metriche erano chiare: linee di codice (si spera di no), feature consegnate, bug risolti, tempo di risposta agli incidenti. Come manager, le metriche cambiano radicalmente. Ecco quelle su cui dovresti concentrarti.
Soddisfazione e engagement del team
Non è un concetto vago. Puoi misurarlo attraverso i 1:1, le survey anonime trimestrali, il tono delle retrospettive. Un team che si sente ascoltato, che ha chiarezza sulle priorità e che percepisce opportunità di crescita performa meglio. Non è idealismo: è correlazione dimostrata.
Retention
Quante persone se ne vanno dal tuo team e perché. Se perdi due persone in sei mesi, è un segnale. Se le perdi perché trovano opportunità migliori altrove che tu non potevi offrire, è una cosa. Se le perdi perché sono frustrate dalla gestione, è un'altra. Tieni traccia e analizza ogni uscita onestamente.
Delivery predictability
Non "il team consegna tanto" ma "il team consegna quello che promette, quando lo promette." La prevedibilità è più importante della velocità pura. Un team che consegna 8 punti ogni sprint con costanza è più affidabile di uno che alterna 15 e 3. La prevedibilità costruisce fiducia con gli stakeholder e riduce la pressione sul team.
Crescita dei report diretti
Le persone nel tuo team stanno crescendo? Stanno sviluppando nuove competenze? Stanno prendendo responsabilità progressivamente più grandi? Se dopo un anno nel tuo team una persona è esattamente dove era quando è arrivata, hai un problema. Il tuo lavoro come manager include sviluppare le persone, non solo gestirle.
La metrica nascosta: quanto sei indispensabile
Paradossalmente, il segnale di un buon manager è che il team funziona anche senza di te. Se vai in ferie per due settimane e al ritorno trovi il caos, non hai costruito un team: hai costruito una dipendenza. L'obiettivo è renderti progressivamente meno necessario nelle operazioni quotidiane, così puoi concentrarti sulla strategia e sulla crescita del team.
Quando tornare IC ha senso (e non è un fallimento)
Questa è una conversazione che il settore tech sta finalmente avendo con più maturità. Non tutti quelli che provano il management vogliono restarci, e non tutti dovrebbero. Il percorso IC a livelli senior (staff engineer, principal engineer) è una carriera legittima e di alto impatto, non un "piano B" per chi non ce l'ha fatta come manager.
Segnali che il percorso IC potrebbe essere giusto per te
- Dopo 6-12 mesi nel ruolo, ti manca genuinamente il lavoro tecnico profondo, non come nostalgia ma come fonte di energia e motivazione.
- Le conversazioni sulle persone (performance, crescita, conflitti) ti drenano costantemente invece di darti soddisfazione.
- Ti trovi a cercare scuse per tornare al codice, non perché il team ne ha bisogno ma perché tu ne hai bisogno.
- La parte del ruolo che ti piace di più è la technical direction, non il people management.
Il contesto italiano
In Italia, il percorso IC a livelli molto senior è meno strutturato che nelle big tech americane. Molte aziende italiane non hanno un ladder IC che arrivi a staff o principal con compensation comparabile a un director. Questo crea una pressione implicita: "se vuoi guadagnare di più, devi diventare manager." Ne parlo in dettaglio nell'articolo staff engineer o engineering manager.
Tuttavia, con il remote work e l'accesso a aziende internazionali, questa dinamica sta cambiando. Sempre più professionisti italiani lavorano per aziende che offrono percorsi IC a livelli senior con compensazioni che in Italia sarebbero impensabili per un manager di linea.
Tornare indietro non cancella l'esperienza
Alcune delle persone più impattanti con cui ho lavorato in 25 anni di carriera sono staff engineer che hanno fatto uno o due anni di management e poi sono tornati IC. Non hanno "fallito": hanno acquisito una comprensione delle dinamiche organizzative che li rende enormemente più efficaci come contributor individuali. Capiscono come pensano i manager, come funzionano i budget, perché certe decisioni vengono prese. Questo li rende leader tecnici migliori.
Come ti posso aiutare in questa transizione
Nei miei percorsi di coaching manageriale, lavoro con professionisti tech che stanno affrontando esattamente questa transizione. Non è terapia e non è un corso generico di "leadership skills". È un percorso pratico, calibrato sulla tua situazione specifica.
Tipicamente un percorso per chi sta transitando da IC a manager include:
- 3-5 sessioni nell'arco di 2-3 mesi, concentrate nei momenti critici della transizione.
- Lavoro sulla delega e sullo stile decisionale — come smettere di fare l'IC con un titolo diverso.
- Preparazione alle conversazioni difficili — feedback, performance review, gestione dei conflitti con ex colleghi.
- Definizione delle metriche personali di successo — come sapere se stai andando nella direzione giusta quando il feedback è lento.
- Valutazione onesta della fit — il management è davvero il percorso giusto per te, o stai seguendo un'aspettativa implicita?
Porto in queste conversazioni 25 anni di esperienza nel tech, 11 anni di leadership cross-funzionale, e la prospettiva di chi ha lavorato sia in contesti internazionali che nel panorama italiano. Se vuoi esplorare se un percorso di consulenza di carriera può aiutarti, parliamone.
Domande frequenti
Quanto guadagna un engineering manager rispetto a un senior engineer in Italia?
Dipende enormemente dal contesto. In aziende italiane tradizionali, un engineering manager guadagna tipicamente il 15-30% in più di un senior engineer, con un range che va dai 55.000 ai 85.000 euro lordi per posizioni in aziende strutturate. In aziende internazionali con sede in Italia o in full remote, le cifre possono essere significativamente più alte. Il punto importante: non fare questa transizione solo per i soldi. Il delta salariale non compensa lo stress se il ruolo non ti piace genuinamente.
Quanto tempo ci vuole per sentirsi a proprio agio come manager?
La maggior parte dei professionisti che seguo riporta un punto di svolta tra i 6 e i 9 mesi. I primi 3 mesi sono quasi universalmente scomodi. Tra il mese 3 e il mese 6, inizi a sviluppare routine e a vedere i primi risultati del tuo lavoro sulle persone. Dopo i 9 mesi, la maggior parte delle persone sa se vuole restare in questo percorso o tornare IC. Se dopo 12 mesi ti senti ancora fondamentalmente a disagio, è un segnale da prendere sul serio.
Posso tornare al ruolo di IC dopo aver fatto il manager?
Sì, e sta diventando sempre più comune e accettato. Le big tech hanno percorsi strutturati per il "pendolo" tra IC e management. In aziende più piccole o tradizionali può essere più complesso politicamente, ma tecnicamente è fattibile. Il consiglio è: se decidi di tornare IC, fallo con intenzionalità. Non come una fuga dal ruolo, ma come una scelta informata basata sulla consapevolezza di cosa ti dà energia professionale.
Devo smettere completamente di scrivere codice?
Non necessariamente, ma devi cambiare il tuo rapporto con il codice. Non sei più un contributor al codebase del tuo team: qualsiasi codice tu scriva crea una dipendenza e un messaggio implicito di mancanza di fiducia. Se vuoi mantenere il contatto tecnico, fallo su side project personali, contributi open source, o prototipi esplorativi che non entrano nella critical path del team.
Come gestisco un report diretto che ha più esperienza tecnica di me?
Questa è la norma, non l'eccezione. Un buon engineering manager non deve essere il miglior tecnico del team. Il tuo valore è nella direzione, nella rimozione dei blocchi, nella crescita delle persone e nell'allineamento con gli obiettivi organizzativi. Se hai un senior staff engineer nel team che ne sa più di te sul codice, è perfetto: il tuo lavoro è creare le condizioni perché quella competenza venga usata al meglio, non competere con essa.
Se stai affrontando questa transizione adesso, o stai decidendo se farla, una sessione introduttiva gratuita di 30 minuti può darti la chiarezza per navigare i prossimi mesi con più sicurezza e meno errori evitabili.