Quanto deve "rimanere tecnico" un Data & AI Manager?
Il dilemma più comune per qualsiasi leader di team tecnici, nel mondo Dati & AI e non solo
Original in Italian; automatic translation into English available here.
Intro
“Cosa vuoi fare da grande?”
Questa è la domanda a cui ci si trova davanti non solo a 10 anni, ma anche molto più avanti!
Mettiamo da parte l’astronauta, il calciatore, o magari l’infuencer (argh). Per chi ha un background tecnologico e un po’ di anni in vari ruoli nel mondo IT, oggi come oggi questa domanda diventa: vuoi fare l’engineering manager (EM) o il tech lead (TL)?
Questi due ruoli partono da una base tecnica comune e poi si biforcano: da un lato il TL, che ha l’eccellenza tecnica come proprio obiettivo, dall’altro l’EM, che è un profilo molto particolare di people manager in ambito tech.
Uno schema, per un ingegnere, vale più di mille parole:
Le aziende tecnologiche (ed in primis le Big Tech americane) hanno capito che non tutti gli ingegneri e i tecnici sono uguali, al di là dei soliti cliché: chi è portato per diventare un super esperto di una tecnologia - e spesso non ha interesse e predisposizione per guidare un gruppo di persone - può diventare un eccellente TL, in grado di risolvere problemi complessi e contribuire attivamente a molteplici progetti.
Chi invece ha un buon mix di competenze tecniche e relazionali potrà invece prendere la strada dell’EM. Un ruolo complesso che richiede di tenere il piede in due scarpe… e far coesistere l’indole tecnica con quella manageriale.
Lavoro complesso, dove trovare l’equilibrio è un arte. Quello che poi succede nella pratica, è spesso finire per sbilanciarsi ed entrare a far parte di due fazioni opposte.
La fazione #1: i manager “vigili”
In molti contesti, specialmente quelli delle enterprise tradizionali, un EM finisce spesso col ricoprire il ruolo del manager “vigile”.
No, non è un aggettivo relativo al suo essere attento a ciò che accade. È un sostantivo: faccio riferimento al vigile urbano, immerso nel traffico di mille progetti e attività.
Anche se è normale che la gestione del team, degli stakeholder, del budget, delle timeline di progetto siano tutte attività fondamentali (e time-consuming), essere completamente avulso dal mondo tecnico e delegare al 100% qualsiasi scelta tecnica porta almeno a due problemi:
Risulta impossibile prendere decisioni tech incisive con un orizzonte di medio-lungo termine, trovando una sintesi tra le opzioni (sempre crescenti) in termini di stack tecnologici e le effettive esigenze aziendali. E nessuna azienda che si definisce tech dovrebbe affidarsi ciecamente a consulenti esterni o fornitori di una specifica tecnologia per definire la propria data & tech strategy.
Risulta altrettanto impossibile, a meno di non avere doti di leadership portentose, ottenere credibilità, autorevolezza e fiducia da parte del team. Tutte cose che non si sviluppano automaticamente per un ruolo in organigramma.
La fazione #2: i manager “smanettoni”
Se da un lato credo pochissimo nei “vigili”, trovo molto naif l’alternativa di una sorta di manager “smanettone”, in prima linea sullo sviluppo di codice e continuamente con le mani in pasta.
Per inciso, tra i sostenitori di questo approccio c’è Elon Musk, secondo cui ogni manager (di X, un tempo Twitter) deve dedicare almeno il 20% del proprio tempo a scrivere codice.
Se guardiamo speficamente X, tra una perdita del 15% degli utenti e del 70% della valutazione nell’ultimo anno, non è andata proprio benissimo… ma anche per tanti altri motivi :)
Tornando al tema dei manager smanettoni, vedo almeno altrettanti problemi rispetto ai manager vigili. Ovviamente però sono di natura completamente diversa.
Il punto è che un EM si trova davanti ad un problema di ottimizzazione vincolata, dove il vincolo è il tempo (che non è infinito) e l’obiettivo è massimizzare il valore aggiunto portato all’azienda da parte di tutto il team. Essere troppo hands on porta un EM a:
Sacrificare il contributo che l’EM può dare alla crescita del team, focalizzandosi invece su sè stesso (come se fosse un TL). E matematicamente, dare un piccolo contributo ad una crescita di N elementi può essere meglio che lavorare su un solo elemento (sé stesso).
Fare affidamento sul fatto che automagicamente ogni elemento del team si muova nella giusta direzione, in maniera efficiente, rispetto ad obiettivi di cui inevitabilmente ogni team member può avere solo una visione parziale. Mia esperienza: non succede, mai. E se è ok per un elemento di un team avere qualche momento da battitore libero… da lì a sentirsi abbandonato al proprio destino, il passo è breve!
La tentazione però è forte, e molti EM finiscono spesso col fare l’allenatore-giocatore… anche perché molti sono stati ottimi giocatori (e sono diventati allenatori proprio per questo, come dice Velasco in un bel talk di pochi minuti)!
C’è una terza via?
Qualche settimana fa ho letto un fantastico articolo proprio sulla ricerca di un equilibrio tra queste due fazioni, scritto da
e sicuramente ispirato alla sua esperienza pluriennale come Director of Cloud di Namecheap. Tra parentesi, il suo substack - - è tra i miei preferiti sia per contenuti che per grafici efficaci come quello sopra: potete iscrivervi gratuitamente da qui sotto.
Quindi sì, esiste una terza via e si basa sul capire la distinzione tra:
restare tecnico, che è un must
essere hands on, che gioco forza decresce man mano che un EM (o figura analoga) prende responsabilità crescenti in termini di progetti e persone
Non voglio restare sul filosofico… di seguito darò il mio punto di vista / esperienza con un taglio più vicino al mondo Dati & AI, a cui appartengo: mi rendo sempre più conto che ragionamenti validi per chi si occupa di altri ambiti tech (ad esempio applicazioni mobile e non, infrastrutture, sicurezza, …) sono abbastanza vicini e condivisibili, ma non proprio replicabili al 100% a quella che è la mia quotidianità.
Dalla teoria alla pratica: focus su Dati & AI
Provo a riassumere di seguito vari aspetti che rientrano - oppure no - nell’idea di restare tecnico, senza però avere continuamente le mani in pasta.
Mi focalizzerò soprattutto su un punto di vista di lead of leads, per dirla con le parole di Pat Kua (autore di quello che trovo il migliore articolo sull’engineering management e i diversi archetipi di questa figura), ossia su chi guida alcuni team indipendenti (e non uno solo). Hint: di fatto è la mia esperienza di tutti i giorni.
Quali sono le attività a cui potrebbe pensare un EM per restare tecnico, e quanto di frequente è ragionevole farle? Questi sono “i miei 2 cents”:
Contribuire attivamente alla codebase dei principali progetti / prodotti di data science, machine learning, AI sviluppati dal team: MAI.
Questo perché chi guida diversi gruppi di lavoro si ritrova un tempo ridotto per dare un contributo individuale e non si può fare il coder per il 10% del proprio tempo. A meno che non si parli di un progetto molto secondario… ma tipicamente, un EM trova davvero tempo da dedicare a progetti secondari?
Fare code review del lavoro del team: QUASI MAI.
Trovo che siano tre i casi in cui derogare e che giustificano il “quasi”: quando il team è in fase di creazione, in situazioni di emergenza (carenze in termini di staffing), oppure quando l’EM ha esperienza verticale su uno specifico argomento, magari da suoi ruoli pregressi.
Analizzare dati, che siano grezzi oppure i risultati di un modello: SPESSO.
Trovo che sia il modo migliore per non cadere in uno dei principali problemi per un manager: vivere in un mondo parallelo, incapace di capire i problemi reali del team. E rispetto ad altre aree tech, chi lavora con dati e algoritmi può avere più facilità nell’intromettersi ai morsetti di un progetto (input/output), oppure in qualche step intermedio.
Fare corsi e certificazioni: A VOLTE.
Sempre tenendo a mente il vincolo del tempo, in qualche caso un po’ di formazione può essere utile… magari con la spinta di una certificazione, più per l’aspetto motivazionale che per l’attestato in sé e per sé.
Da valutare caso per caso.
Seguire l’evoluzione di tecnologie e metodologie del mondo AI: SEMPRE. Tra eventi, meetup, articoli su substack/medium/linkedin, c’è l’imbarazzo della scelta. Idealmente, anche fare un drill-down su un argomento specifico, magari con la scusa di spiegarlo ad altri (come ho fatto a Pycon 2023 con Polars), può essere un’ottima idea!
Mettere in discussione (costruttivamente) decisioni analitiche, tecniche o metodologiche: SPESSO.
Se si riesce a tenere il passo con le evoluzioni tecnico/analitiche (vedi il punto sopra), si può creare un sano challenge a varie scelte operate dagli elementi del team. Non con l’obiettivo di centralizzare il processo decisionale, ma semplicemente per aiutare il team a prendere decisioni migliori. E sto dando per scontato una cosa che non piacerà agli amanti del command and control: molte decisioni (ok, non super strategiche) possono/devono essere prese dai team member più competenti sull’argomento, non da chi li guida.
Cito direttamente sempre
I believe the concept of one person "controlling" others is somewhat outdated. Developers and system engineers should feel a sense of ownership over their work, and the team should collectively maintain high standards and self-regulate from a technical standpoint. While this needs a highly cohesive team, in other scenarios, the EM can rely on Tech Leads or experienced engineers through delegation, without needing to be hands-on.
I più “tecniconi” potrebbero pensare: ma se non scrive codice e a stento riguarda quello altrui, l’EM fa davvero qualcosa di utile per supportare lo sviluppo di un team tecnico? La risposta è un forte “sì”… e richiederebbe un articolo ad hoc!
In estrema sintesi, l’orizzonte dell’EM spazia in due direzioni:
All’esterno del team, con l’obiettivo costante di ascoltare e capire a fondo le esigenze (di business) dell’azienda, per determinare come queste si possono declinare in una strategia ed una serie di azioni concrete a livello tecnico.
All’interno del team, creando quella che chiamo una “visione condivisa”, ossia l’unico modo per l’EM di non diventare un collo di bottiglia su ogni tematica che non sia squisitamente tecnica.
Conclusioni
Personalmente sono un grande fan di Satya Nadella, CEO di Microsoft da 10 anni. Un’azienda che ora è indubbiamente tra le più toniche nel campo delle Big Tech, in grado di stringere collaborazioni importanti, sviluppare prodotti innovativi e integrati, ma che un tempo veniva rappresentata così:
Nadella pone spesso l’enfasi sul concetto di bring clarity, portare chiarezza, come in alcune sue dichiarazioni che rappresentano al meglio un’idea di leadership moderna in ambito tech.
Per “distinguere il segnale immerso in tanto rumore interno ed esterno” sicuramente la competenza tecnica non è un optional, ma non va neanche fraintesa con l’essere sempre e solo hands on!
Il punto è che non avere sempre le mani in pasta deve essere dettato da una scelta deliberata, non da una mancanza di competenza.
Si tratta di mantenere un equilibrio non semplice, lungo un confine sfumato… bisogna provarci!
Concordo su quasi tutto quello che hai scritto.
Unica variante che metterei è Mettere in discussione (costruttivamente) decisioni analitiche, tecniche o metodologiche: A VOLTE (e non "spesso").
Perché? Perché il ruolo del manager è quello (anche) di far crescere le sue persone e per farlo devi delegare (anche quando sbagliano, se l'errore non costa molto). Se metti in discussione troppo spesso crei codipendenza (ovvero che finché tu non sei d'accordo la gente non va avanti). Se invece lo fai a volte la gente si lancia molto di più.
è un po' come coi bambini che iniziano a camminare: non devi tenerli, ma evitare che si schiantino :)
Bell'articolo Alberto e grazie per la mention!