In questa intervista con il CTO di Jointly, Enrico Maria Cestari, esploreremo la sua prospettiva sul futuro della figura del CTO nei prossimi 10 anni, prendendo in considerazione l’importanza della gestione tecnologica e delle dinamiche organizzative all’interno delle aziende. Enrico condividerà anche la sua visione sul ruolo dell’intelligenza artificiale e come questa potrebbe plasmare il futuro della programmazione e della tecnologia.
Come evolverà la figura del CTO nei prossimi 10 anni?
Sono convinto che rispetto al passato si comprenderà sempre più l’aspetto “manageriale” associato alla figura del CTO, rispetto a quello prettamente tecnico. Questo perché il tradizionale approccio basato su “Business Strategy” e “IT Strategy reattiva e di supporto” non si sposano bene con il panorama attuale, completamente rivoluzionato e guidato dalla tecnologia. La tecnologia diventa la locomotiva del treno, non più un vagone. Di conseguenza le aziende hanno bisogno di avere una visione tecnologica tanto profonda quanto quella posseduta sul mercato. Contemporaneamente è necessaria una capacità di lavorare con e sulle persone affinché l’organizzazione rimanga fluida e dinamica abbastanza da accogliere cambiamenti che al momento presente non si possono neppure predire.
AI generative: quale credi sarà il futuro della programmazione e della tecnologia nei prossimi 10 anni?
Lo dico subito: i developer resteranno.
Tuttavia il loro ruolo evolverà, come del resto già è stato nel passato diverse volte, e raggiungerà un nuovo livello di astrazione: il mestiere del developer sarà sempre più quello di problem solver e gestore di sistemi complessi, i cui micro dettagli implementativi potranno invece essere demandati al supporto dell’AI.
L’AI avrà un ruolo estremamente disruptive anche nell’automazione dei processi interni di un’azienda. Questo si traduce in: non più ricerche su Google, ma assistenti virtuali ad hoc per ogni singolo dipendente che attingono alla knowledge base specifica dell’azienda e supportano gli individui nelle attività del day by day. Fine dell’help desk interno?
Puoi suggerire un libro che ti è stato utile per diventare un buon CTO?
The Connector Manager.
In un ambito di Knowledge Working, accettare di non essere il “super esperto” che può insegnare tutto a tutti è fondamentale…però è anche altrettanto cruciale capire come sopperire a questo limite intrinseco! Ecco, l’approccio “Connector” (che il libro applica al coaching ma che di fatto si può estendere a varie altre attività manageriali) è stato per me un punto di svolta. Ad onor del vero, devo dire che nel mio caso ho anche avuto la fortuna di vederlo applicato sul campo da un CTO a cui veniva naturale, ancora prima che entrambi venissimo a conoscenza del libro!
Quali sono 3 passi importanti per scalare il team?
- Avere bene in testa l’architettura dei sistemi di cui abbiamo realmente bisogno in relazione alle necessità del business attuali e future – ricordandoci che architetture software ed assetto organizzativo dell’azienda si parlano strettamente (cfr. legge di Conway).
- Gestire la fase di recruiting: inserire le persone corrette è fondamentale, se si sbaglia su questo punto si rischia di distruggere anche un buon pregresso, magari costruito bene. Le persone sono accomunate da valori ed approcci culturali che sposano, e fare scelte coerenti in questo senso è importante tanto quanto scegliere persone tecnicamente competenti.
- Monitoraggio costante delle dinamiche: quando un team si costruisce, si generano nuove dinamiche fra gli individui. È compito del CTO (avvalendosi in caso di Engineering Manager quando il team scala) tenere d’occhio queste dinamiche e facilitare la risoluzione dei conflitti principali, lasciando sempre il giusto grado di autonomia affinché il Team possa trovare il suo equilibrio.
Quali sono le problematiche che si possono incontrare quando si scala il team?
Mancanza di idee chiare: le professionalità in ambito Tech sono estremamente variegate, alcune sono più trasversali, altre estremamente specializzate. Se non si ha ben chiaro dove si vuole arrivare si rischia che il team nel suo complesso abbia delle lacune oppure che ci siano troppe figure in ruoli che richiederebbero meno capacity. Su questo punto, un consiglio: confrontatevi con il vostro Team. Se un organismo funziona bene, sarà il principale fornitore di insight circa eventuali mancanze o aggiustamenti da fare.
Quali sono i segnali per riconoscere un potenziale leader nel team?
La stima dei compagni di Team è il punto chiave. Le figure tecniche amano lavorare con peer competenti, che abbiano un’autorevolezza importante nel loro ambito di expertise. E poi la capacità di comunicare: i tecnici devono affrontare problemi molto complessi e spesso spiegarli a persone che svolgono altri mestieri può essere davvero complicato, ma un buon leader ce la fa!
Come mantenere la cultura aziendale quando si scala il team?
Questo è un punto su cui mi confronto spesso con i miei colleghi e difficilmente troviamo una soluzione definitiva. Man mano che si scala, introdurre un minimo di “gerarchia” è fisiologico per poter assicurare la gestione organizzativa. Ritengo che la chiave sia curare molto attentamente i momenti in cui ci si astrae e non si ha più un contatto diretto con tutti, cosa che avviene nelle prime fasi di una start up. Dobbiamo nutrire una fiducia cieca nelle persone che riportano direttamente a noi (per esempio: gli engineering manager) affinché si impegnino quotidianamente per far passare alle persone i valori culturali che tanto si è faticato per concretizzare prima dello scale up. E naturalmente supportare attivamente affinché questo avvenga, nonché fare “zoom in” in quelle aree in cui ci si accorge che ci sono delle frizioni.
Lettura consigliata: Cos’è e perché è importante la trasparenza quando si cerca lavoro nel mondo dev
Quali sono i rischi del debito tecnologico?
- Costo (monetario): Il debito tecnologico va considerato come una liability nel balance sheet. Se da un lato un po’ di debito può essere fisiologico in un momento di rapida crescita, un eccesso significa perdere molto tempo in futuro (tradotto: un costo più elevato) sia per creare nuove funzionalità che anche solo per risolvere il debito già esistente.
- Numero di bug elevato: Un forte debito tecnologico porta alla mancanza di controllo del sistema (e viceversa, innescando un circolo vizioso) – di conseguenza è molto più probabile che nuovi rilasci o anche solo piccole modifiche diano origine ad errori da sistemare
- Morale del team: Avere una codebase ricca di debito è demotivante per gli sviluppatori, che devono faticare doppiamente anche solo per rilasciare funzionalità che in condizioni migliori sarebbero molto semplici. Inoltre, se da un lato è del tutto sano applicare le regole del refactoring, dover investire una quantità esagerata di tempo soltanto in questo tipo di attività può avere degli impatti sulla psychological safety del team, specialmente se la sensazione è che da parte del management ci sia scarsa attenzione verso questo tema.
Quali sono gli errori più comuni che portano al tech debt?
- Velocità di sviluppo sbilanciate: Spesso il team tech comunica l’esigenza di “rallentare” alcuni sviluppi per poter garantire che vengano fatti con la qualità desiderata – il trade off tra la voglia di rilasciare commercialmente un prodotto o una funzione e la qualità con cui il codice viene sviluppato deve sempre essere ben bilanciato. Voler accelerare a tutti i costi e pressare il team affinché restringa i fisiologici tempi di sviluppo è la ricetta perfetta per il proliferare del debito tecnico, in quanto porterà a trovare escamotage e a fare scelte architetturali meno solide, pur di poter “mettere la spunta” sullo sviluppo. Inutile dire che questa accelerazione presenterà un conto salato in futuro.
- Approccio sbagliato allo sviluppo: Scrivere codice è un’attività complessa sotto diversi punti di vista, e sebbene uno stesso problema possa essere risolto in modi diversi, non tutti hanno la stessa qualità. Utilizzare i test automatici è un tipico esempio di come migliorare la qualità del codice e ridurre il debito al costo di un investimento di tempo iniziale maggiore. Adottare best practices e standard condivisi con il team, che migliorano la facilità di comprensione della codebase, sono tutti investimenti di tempo con un alto ritorno. Naturalmente è necessario che le skill del team siano adeguate e che la comprensione ed il commitment verso i temi relativi alla qualità del codice siano profondi.
- Perdita di conoscenza architetturale: La codebase è complessa, scritta di corsa, il codice non si comprende da solo e per giunta la documentazione è poca e i commenti non sono chiari – tutta la conoscenza è nelle mani dei developer in carica (alle volte neppure interni all’azienda). Una situazione di questo tipo è del tutto fertile alla crescita del debito, in quanto è sufficiente che poche persone smettano di lavorare per l’azienda per far si che la conoscenza architetturale e del codice si disperda, rendendo molto più complesso il lavoro di sviluppatori nuovi che dovranno sistemare le cose (e sperabilmente crearne di nuove).
Che approccio/strategia segui per evitare il code debt in azienda?
- Costante allineamento con il team di Prodotto: in primis, bisogna evitare che le richieste al team di sviluppo siano irrealistiche o che non venga tenuto conto degli alert del team stesso. Il tempo dedicato alle nuove feature deve essere bilanciato con quello necessario a risolvere eventuale debito pregresso – inoltre il tempo di sviluppo deve essere sensato affinché i dev possano scrivere il codice con la qualità necessaria, evitando di introdurre debito nuovo. Importante il trade off: non bisogna sfociare nel “perfezionismo tecnologico” e sovra ingegnerizzare eccessivamente le soluzioni,rischiando di rendere il prodotto non appetibile dal punto di vista commerciale (se i rilasci sono troppo lenti si rischia di perdere vantaggio competitivo).
- Allineamento del team di sviluppo circa la qualità attesa del codice: adottare le pratiche adeguate può minimizzare tantissimo i problemi futuri; in particolare penso all’utilizzo di test automatici (non necessariamente applicare il TDD alla lettera) ed adottare un approccio che attinge alle filosofie agili e DevOps, ricercando un miglioramento continuo iterazione dopo iterazione. Anche pratiche come le code review ed il pair programming possono essere molto utili, specialmente con developer nuovi nel team che stanno ancora familiarizzando con la codebase.
- Monitoraggio del debito e revisione: come un debito finanziario, anche quello tecnologico non è intrinsecamente negativo – lo diventa quando non è misurato, gestito, accettato consapevolmente. Se rilasciare una feature in due settimane, accettando di introdurre del debito e sapendo di doverlo poi sanare ci concederà un grosso vantaggio competitivo, introdurlo può avere senso. L’analisi costi-benefici qui è chiave (anche se non sempre facile da quantificare). Dedicare del tempo strutturato alla revisione del codice, al refactoring ed alla minimizzazione del debito esistente è un punto cruciale.
Perché pensi che il debito tecnologico sia aumentato così tanto negli ultimi anni?
Sono convinto che la causa principale sia una mancanza di comprensione del debito tecnologico: al di fuori dell’ambiente Tech, questo concetto suona sconosciuto, a volte visto addirittura come una scusante per rallentare alcuni sviluppi. Inevitabilmente una mancanza di comprensione porta a quelle scelte che poi innescano il crescere del debito stesso: pressione del management per sviluppi rapidi, focalizzazione eccessiva sui risultati a breve termine, mancanza di un’analisi costi-benefici sensata.
Al tempo stesso, la complessità del software aumenta, e spesso le richieste sono eccessive in relazione anche alle competenze che l’azienda può permettersi di avere; forzare un team non ancora sufficientemente maturo a rilasciare qualcosa di troppo complesso può portare ad architetture non solide e scelte inefficaci, che poi si pagano nel lungo periodo.
Leggi anche:
