In Italia crescere nell’IT significa smettere di essere tecnici?

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 che ricordo meglio 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é l’unica forma di crescita sembra sempre essere quella di coordinamento o comunque meno tecnico?

Questa domanda negli anni mi è rimasta dentro.

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.

E la sensazione che ho avuto molte volte è stata diversa.

In molti contesti internazionali sembra perfettamente normale che una persona possa crescere rimanendo un tecnico: diventare senior engineer, architect, principal engineer, guidare decisioni tecniche importanti senza necessariamente diventare un manager lontano dalla parte tecnica.

Nel mercato italiano invece ho spesso avuto una percezione diversa.

Sembra quasi che a un certo punto della carriera il percorso diventi inevitabile:

tecnico → senior → team lead → manager

Come se l’unico modo per crescere fosse smettere di fare il tecnico.

 Il tecnico visto come esecutore

Forse il problema è anche culturale. Spesso nel nostro settore il tecnico viene ancora percepito come qualcuno che “esegue”:

qualcuno 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.

Un po’ il vecchio stereotipo del nerd e del suo computer.

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 soprattutto anni di pratica sul campo.
Non è solo “scrivere codice” o “configurare server”.

È capire come funzionano davvero i sistemi.

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 complessità reale di molti di questi percorsi.

Quando i ruoli tecnici vengono fraintesi

Questo si vede anche nel modo in cui spesso vengono interpretati alcuni ruoli. Non è raro sentire cose del tipo:

• 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, dovrebbe essere 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 succede 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 molto mirate.

Eppure, in alcuni contesti, si fa ancora fatica a distinguere ruoli che in realtà hanno responsabilità molto diverse.

Non è raro, per esempio, che il ruolo di Cloud Architect venga letto in modo molto vicino a quello di un sistemista, o sovrapposto ad altri ruoli architetturali che possono avere alcune aree di overlap, ma anche responsabilità differenti.

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

Ma il punto non è stabilire se una persona sia o meno in grado di fare un certo tipo di attività.

Un professionista con molti anni di esperienza probabilmente è perfettamente in grado di fare un lift-and-shift, configurare una macchina o gestire un backup.

Il punto è un altro.

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

Un Cloud Architect non esiste solo perché qualcuno deve migrare delle macchine virtuali.
Esiste perché progettare piattaforme cloud scalabili, resilienti e sostenibili nel tempo è diventato un problema architetturale complesso.

E forse il vero tema è proprio questo: quando la crescita tecnica viene banalizzata, si rischia di 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 finisce per banalizzare ancora di più competenze che in realtà richiedono esperienza, contesto e comprensione profonda dei sistemi.

Nel mondo IT per essere un buon manager aiuta capire la tecnologia

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 persone a cui potevi chiedere un pattern architetturale, discutere di scalabilità o di resilienza di un sistema, ma che allo stesso tempo erano perfettamente in grado di parlare 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, parlare con il business, guidare una strategia tecnologica e allo stesso tempo rimanere profondamente tecnici.

La competenza tecnica non scompare quando si cresce di ruolo.  Se mai, diventa ciò che permette di prendere decisioni migliori.

La carriera tecnica è una carriera vera

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

Il punto non è contrapporre carriera tecnica e management, ma riconoscere che nel mondo IT esistono percorsi diversi, e che 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 architetturali sempre più complesse.

E che proprio questa esperienza, spesso, è ciò che permette poi di diventare anche dei buoni manager.

Perché nel mondo IT, alla fine, la tecnologia non è solo uno strumento operativo.

È il cuore di tutto.

Questo non significa che tutti i ruoli manageriali debbano essere tecnici. Ma nel mondo IT esistono forme di leadership che nascono proprio dalla profondità tecnica e dalla capacità di comprendere davvero i sistemi.

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

È una carriera in sé.