Crescere nell’IT senza smettere di essere tecnici (il problema che vedo in Italia)

Ricordo le mie prime esperienze strutturate nel mondo IT enterprise.

Era il periodo in cui iniziavano ad affacciarsi Agile e Scrum. Scrum dominava la scena e molte aziende provavano ad adottarlo, spesso con grande buona volontà ma con ancora poca maturità.

Uno degli aspetti più ricorrenti che ho osservato in quel periodo era la difficoltà ad accettare un concetto molto semplice: che fosse il team a decidere quanto lavoro riusciva davvero a portare a termine.

All’epoca mi occupavo di sviluppo backend e design. Ero ancora agli inizi della mia carriera, ma avevo la fortuna di lavorare su progetti interessanti e di crescere tecnicamente.

Un giorno un cliente mi fece quello che per lui era un grande complimento: mi propose di diventare Scrum Master, cioè di spostarmi verso un ruolo meno tecnico e più orientato alla facilitazione e al coordinamento.

Ricordo di essere rimasto piuttosto sorpreso.

Mi chiesi: perché prendere una persona che sta crescendo tecnicamente all’interno di un team e spostarla dopo poco tempo in un ruolo diverso?

Perché togliere qualcuno dalla parte operativa proprio quando porta valore aggiunto e sta iniziando a capire davvero come funzionano i sistemi?

E soprattutto: perché una delle forme di crescita più comuni sembra essere quella di coordinamento o comunque meno tecnico?

Questa domanda negli anni mi è rimasta dentro.

Non è una regola universale e non vale per tutte le aziende italiane.

Ma è un pattern che ho osservato in diversi contesti enterprise e consulenziali, e che mi è stato confermato anche da altri professionisti del settore.

La carriera tecnica che sembra non esistere

Nel tempo mi sono confrontato spesso con amici e colleghi che hanno costruito la loro carriera fuori dall’Italia.

In molti contesti internazionali è abbastanza comune che una persona possa crescere rimanendo un tecnico: diventare senior engineer, architect, principal engineer, guidare decisioni tecniche importanti senza necessariamente spostarsi verso ruoli puramente manageriali.

In diversi contesti italiani, invece, ho osservato un pattern differente.

A un certo punto della carriera, il percorso tende a diventare implicito:

tecnico → senior → team lead → manager

Non tanto perché sia sempre la scelta migliore, ma perché spesso è l’unica struttura di crescita realmente riconosciuta.

In più di un contesto, questo si traduce in una mancanza di alternative tecniche con pari visibilità, impatto e riconoscimento.

 Il tecnico visto come esecutore

Parte di questa dinamica è probabilmente anche culturale. In molti contesti il tecnico viene ancora percepito come qualcuno che “esegue”:

una figura a cui assegnare task, che scrive codice o configura sistemi, e che alla fine della giornata chiude il suo lavoro come in una catena di montaggio.

Ma chi lavora davvero nel mondo IT sa che la realtà è molto diversa.

Progettare sistemi complessi, architetture cloud, piattaforme distribuite o infrastrutture scalabili richiede esperienza, capacità di analisi e anni di pratica sul campo.

Non è solo “scrivere codice” o “configurare server”.
È comprendere come funzionano davvero i sistemi, prendere decisioni con impatti nel tempo e gestire complessità reali.

Naturalmente non ogni ruolo tecnico richiede lo stesso livello di astrazione o progettazione.

Ma ridurre il lavoro tecnico a semplice esecuzione significa non vedere la profondità reale di molti di questi percorsi.

L’effetto collaterale: ruoli tecnici fraintesi

Questa semplificazione si riflette anche nel modo in cui vengono interpretati alcuni ruoli.

Non è raro sentire descrizioni come:

• il Cloud Architect è quello che “migra le VM”
• il DevOps è quello che “fa le pipeline”
• l’Architect è quello che “disegna qualche diagramma”

In realtà molti di questi ruoli nascono proprio dall’evoluzione della carriera tecnica.

Un Cloud Architect, per esempio, è tipicamente qualcuno che ha passato anni a costruire sistemi, a gestire problemi reali di scalabilità, affidabilità e complessità distribuita.

Non è semplicemente qualcuno che esegue una migrazione.

E paradossalmente questo avviene proprio mentre il mondo tecnologico diventa sempre più specializzato.

Negli ultimi anni sono emersi ruoli sempre più specifici: DevOps, DevSecOps, Platform Engineer, AI Engineer.

Figure che riflettono quanto i sistemi moderni siano complessi e quanto sia necessario sviluppare competenze mirate, eppure, in alcuni contesti, si fa ancora fatica a distinguere ruoli che in realtà hanno responsabilità molto diverse.

Lo si vede anche nei processi di recruiting, dove il titolo di un ruolo viene interpretato in modo molto generico.

Il punto non è stabilire se una persona sia o meno in grado di svolgere determinate attività operative.

Un professionista con esperienza è spesso perfettamente in grado di farlo.

Il punto è un altro.

Quando un ecosistema tecnologico matura, emergono ruoli specializzati perché servono competenze diverse per risolvere problemi diversi.

Se questa evoluzione viene banalizzata, si finisce per banalizzare anche i ruoli che da quella crescita nascono.

In questo scenario, anche il modo in cui viene raccontata oggi la Generative AI rischia di peggiorare ulteriormente la percezione del lavoro tecnico.

Se passa l’idea che progettare sistemi o costruire software significhi semplicemente chiedere qualcosa a un modello e aspettare una risposta, si rischia di semplificare eccessivamente competenze che in realtà richiedono esperienza, contesto e comprensione profonda.

Management e competenza tecnica

Il punto non è che il management sia un’evoluzione sbagliata, il problema è quando diventa l’unica evoluzione possibile.

Nella mia esperienza sono stato molto fortunato. Ho avuto modo di lavorare con architetti e IT manager estremamente competenti, persone che avevano passato molti anni nel mondo operativo prima di spostarsi verso ruoli più strategici.

Ed era evidente la differenza.

Erano professionisti con cui potevi discutere di architetture, scalabilità o resilienza, ma che allo stesso tempo erano perfettamente in grado di interagire con il business e con gli stakeholder.

Professionisti che magari la mattina discutevano con il business di evoluzione di una piattaforma e il pomeriggio si sedevano con il team a ragionare e fare coaching su un’architettura reattiva, oppure su come applicare uno Strangler Fig Pattern con un Anti-Corruption Layer, o persino a scrivere insieme qualche riga di codice per chiarire un’idea.

Non perché il loro ruolo fosse scrivere codice ogni giorno, ma perché avevano una comprensione reale di ciò che stavano progettando.

Ed è proprio questo il punto.

Si possono ricoprire ruoli di leadership tecnologica o di IT management e allo stesso tempo rimanere profondamente tecnici.

La competenza tecnica non scompare quando si cresce di ruolo.

Se mai, è ciò che permette di prendere decisioni migliori.

La carriera tecnica è una carriera vera

Forse il punto non è scegliere tra essere tecnici o manager.

Non è una contrapposizione.

Nel mondo IT esistono percorsi diversi, e alcuni ruoli di leadership si fondano proprio su una forte credibilità tecnica.

Il punto è riconoscere che la carriera tecnica è una carriera vera.

Un percorso fatto di esperienza, profondità, comprensione dei sistemi e capacità di prendere decisioni sempre più complesse.

Una carriera tecnica matura dovrebbe avere:

• livelli chiari di crescita (senior, staff, principal…)
• impatto reale sulle decisioni, non solo sull’implementazione
• riconoscimento economico e organizzativo comparabile al management

Senza questo, non si sta crescendo davvero nella tecnica.
Si sta semplicemente cambiando mestiere.

E forse è proprio per questo che la carriera tecnica non è una fase iniziale.

È una carriera in sé