Il Cambiamento di Mentalità DevOps: Lezioni di Leadership da un CTO
D: Hai un mentore che ti ha ispirato o aiutato nel tuo percorso professionale finora?
Ce ne sono davvero tanti. Far parte della comunità delle startup a Raleigh, nel North Carolina, è stato fantastico e ci sono decine di persone che mi hanno aiutato in modi che forse nemmeno immaginano. Potrei citare nomi specifici, ma alcune storie fondamentali hanno plasmato la mia visione del mondo.
Una di queste viene da un direttore delle vendite che parlò in uno dei miei corsi di imprenditorialità durante l'università. Da studente di ingegneria concentrato sullo sviluppo di codice e delle competenze tecniche, le vendite mi erano totalmente estranee e persino poco interessanti. Tuttavia, questa persona condivise una storia che mi aiutò a vedere le cose sotto una luce diversa.
Ricordava una chiacchierata con un suo collega tecnico. Il collega gli disse: “Non capisco come fai.” Il venditore rispose: “A fare cosa?” Il collega rispose ancora: “Avere un obiettivo da raggiungere. Deve essere molto stressante dover vendere per poter mangiare.” Ci rifletté un attimo e rispose semplicemente: “Sì, è vero, ma se non vendo io, non mangi nemmeno tu.”
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
Questa storia mi ha davvero aiutato a contestualizzare l’ingegneria.
Puoi costruire il prodotto o servizio più straordinario, ma se non riesci a mostrare il valore alle persone a cui può servire, stai semplicemente facendo ingegneria nel vuoto.
Un’altra persona che mi ha aiutato è stata un mentore che aveva gestito aziende e divisioni ingegneristiche e poi aveva deciso di dedicarsi ad aiutare le persone a sviluppare le proprie idee e trovare ruoli in diverse startup. Mi ha guidato attraverso molte sfide, ma uno dei consigli chiave che mi ha lasciato è che la maggior parte dei leader di organizzazioni tecniche eccelle in una di tre aree:
Il “capo tecnico”, il manager rockstar o la persona chiave per il prodotto. Aggiungeva che un’azienda di successo ha bisogno di tutte e tre queste figure e che un grande leader deve riconoscere chi è lui stesso e poi assumere persone che abbiano le altre competenze. Questo mi ha aiutato a capire la mia crescita come leader ingegneristico e quando devo spingere su un aspetto oppure lasciar spazio su altri.
D: Puoi indicare tre punti di forza o competenze che sono stati importanti nel tuo percorso?
Un motto che seguo è: “Prima integrati, poi distinguiti.” Anche se è una frase ad effetto, mi ricorda che quando inizio a lavorare con un nuovo team devo prima imparare a conoscerlo. Capire perché le cose sono fatte in un certo modo è fondamentale per costruire fiducia.
Ad esempio, se mi presento il primo giorno e cerco subito di proporre o attuare un grosso cambiamento, la reazione naturale sarà la resistenza, e sarò io stesso a rendermi la vita più difficile in seguito. È importante cercare somiglianze e punti di contatto all’interno di un nuovo team, prima di sfidare lo status quo o provare a introdurre grandi cambiamenti. Questo approccio è valido anche nella creazione di nuove relazioni in ogni ambito della vita.
Un’altra massima che mi guida è: “Quello che le persone dicono e fanno è solo correlato a ciò che pensano e sentono.” Può sembrare pessimista, ma mi piace l’idea che spesso gli esseri umani siano sotto forte pressione ad agire o esprimersi in un certo modo.
Per esempio, quando chiedi a qualcuno come va la giornata, quasi sempre risponde “Bene”, invece di aprirsi davvero e raccontare come sta. Quando si lavora con team e gruppi, è importante prestare attenzione a queste pressioni per poter comprendere e empatizzare profondamente. Ad esempio, se qualcuno ti riferisce direttamente, può essere difficile per lui assumersi la responsabilità di un errore se teme delle conseguenze.
Come leader, è essenziale costruire e valutare costantemente l’ambiente di lavoro per favorire l’apertura. Altrimenti, potremmo involontariamente creare una cultura in cui i problemi si annidano nel team e non vengono affrontati.
Nel gestire i team, è necessario essere costantemente introspettivi e riflessivi per sviluppare competenze solide. Anche se “guardare dentro se stessi” funziona per me, potrebbe non essere il modo migliore per tutti, e un buon leader deve riconoscere che ogni persona impara e cresce in modo diverso.
Un leader efficace si concentra sull’equilibrio tra il raggiungimento degli obiettivi e l’empatia, riflettendo costantemente sia sui propri punti di forza e debolezza che su quelli del team più ampio.
D: Su quali competenze stai ancora cercando di crescere?
Tornando ai consigli di uno dei miei mentori, sto lavorando costantemente sull’aspetto gestionale dei tre pilastri del ruolo di leader tecnico. Sono stato fortunato a lavorare con un collega straordinario in questo, che mi ha mostrato alcune modalità chiave per crescere e migliorare.
Come cofondatore di una startup tecnologica, mi sono concentrato molto su tecnologia e prodotti e ho lavorato con team piccoli. Ora che la nostra organizzazione sta crescendo, devo crescere insieme a lei. L’arte della gestione è una competenza tanto quanto lo sviluppo software.
D: Parliamo di cosa significa avere un team DevOps di successo. Quali sono gli obiettivi chiave che un team DevOps può identificare in un percorso di trasformazione digitale?
Una delle cose più importanti che sento dagli altri leader è l’importanza di avere una visione condivisa di cosa significhi DevOps per la propria organizzazione. Ho visto organizzazioni dove “DevOps” significa assumere un SRE, chiamarlo DevOps engineer e festeggiare.
Prendere i componenti principali del ciclo DevOps e identificare come fluiscono lavoro e idee nel tuo processo di sviluppo è un punto chiave da cui partire. Prendi una singola richiesta di sviluppo dall’inizio e seguila fino a quando genera la prossima attività; potresti individuare lacune fondamentali.
Ad esempio, potresti scoprire che il tuo team QA è isolato e che esiste una mentalità del tipo “lanciare il lavoro dall’altra parte del muro”, la quale impatta sulla velocità di avanzamento. Una volta che inizi a definire questo flusso di processo nella tua organizzazione, puoi valutare gli strumenti più adatti per aiutarti.
Molte organizzazioni partono dagli strumenti e cercano di forzare lentamente e dolorosamente il cambiamento organizzativo da lì. È un modo inverso per cominciare.
D: Ci sono sfide o insidie comuni che i team DevOps dovrebbero considerare?
DevOps è un modo di lavorare. Sotto molti aspetti, è il seguito della trasformazione agile che ha rivoluzionato il settore dello sviluppo software decenni fa. È importante pensarla in questo modo. Molte organizzazioni hanno avuto difficoltà con la trasformazione agile a causa della mancanza di comprensione e coinvolgimento dei leader. I manager pensavano che bastasse iniziare a fare stand-up meeting per completare il 50 percento di ticket in più. Guardando indietro, era ovviamente sbagliato.
Allo stesso modo, oggi molti leader pensano che basti implementare una pipeline CI/CD per superare le metriche Dora e ottenere il 50 percento di produttività in più. Il vero cambiamento è nella mentalità. DevOps permette la piena proprietà dell’intero ciclo di consegna del software, grazie al quale i team possono costruire sistemi migliori. DevOps dà potere ai team di riconoscere come migliorare e di attuare questi miglioramenti, quindi i leader devono creare quello spazio e offrire supporto per vedere davvero gli impatti organizzativi.
D: In che modo una collaborazione ed una comunicazione efficaci tra membri del team possono migliorare la produttività e il successo di un team DevOps? Quali pratiche possono favorire tutto ciò?
La comunicazione è cruciale in ingegneria. Quasi ogni problema nasce da una comunicazione inefficace e DevOps non fa eccezione. Tornando all’importanza di una visione condivisa di cosa rappresenta DevOps nella propria organizzazione, bisogna davvero comprendere la direzione e avere quella visione comune per avere una possibilità di successo.
Alcune delle pratiche fondamentali che ho visto sono la definizione di gate semplici nelle varie fasi del processo. Devono essere legati al lavoro, non alle persone che lo eseguono. Definire dei processi su come i compiti e le informazioni fluiscono nel team permette di essere efficienti nel passaggio di consegna, soprattutto quando arrivano interruzioni, e consente di scalare le diverse parti del team in modo indipendente.
Ogni team e ogni prodotto ha esigenze leggermente diverse, e individuare questi gate e cosa deve accadere in ognuno aiuta a scoprire dove risiedono le inefficienze.
D: Quale ruolo gioca CI/CD nel DevOps e quali sono le migliori pratiche per implementare pipeline CI/CD al fine di garantire un processo di rilascio software fluido e affidabile?
È fondamentale portare le modifiche al software dall’idea alla produzione il più rapidamente possibile. I processi manuali sono estremamente lenti e dipendono dagli esseri umani. Gli esseri umani, pur essendo ottimi in attività come la risoluzione dei problemi e la creatività, spesso non sono bravi a seguire liste di controllo in modo esaustivo centinaia di volte al giorno. Automatizzare le attività ripetitive permette davvero al tuo team di concentrarsi su ciò che sa fare meglio. Inoltre, i computer sono eccezionalmente veloci e possono scalare rapidamente. Creare una pipeline che sfrutti queste capacità è il principale vantaggio dell’adozione di un processo CI/CD.
Un aspetto chiave da ricordare nel costruire un processo di questo tipo è bilanciare velocità e sicurezza. Anche se puoi automatizzare completamente ogni commit da uno sviluppatore direttamente in produzione, ciò non garantisce alcuna sicurezza. Costruire la tua pipeline per consentire quel livello di velocità e aggiungere gradualmente controlli può aiutarti in futuro. Forse all’inizio tutto deve essere esplicitamente approvato da un ingegnere QA e da un ingegnere dei rilasci, ma il processo effettivo può ridursi alla pressione di un pulsante.
Una volta implementati i test automatici, potresti essere in grado di eliminare l’approvazione QA.
D: In che modo favorire una cultura e una mentalità DevOps contribuisce al successo complessivo di un team DevOps e quali strategie possono utilizzare le organizzazioni per promuovere questa cultura tra i loro team di sviluppo e operations?
La sfida principale in questa trasformazione è affrontare la mentalità del "lancio oltre il muro". Se sei all’inizio di questo percorso, potresti avere cinque o sei team che devono lavorare su ogni pezzo prima che arrivi in produzione. Passando al DevOps, si promuove una responsabilità condivisa per l’intero ciclo di vita del prodotto.
Questo può richiedere cambiamenti significativi nel modo in cui progetti, costruisci e distribuisci la tua soluzione. Sebbene molti conoscano la creazione di software facilmente testabile, adottare una cultura DevOps richiede la realizzazione di sistemi e piattaforme di cui possano essere responsabili end-to-end piccoli team.
D: Quali sono i “5 Componenti Essenziali di un Team DevOps di Successo”? Racconta una storia o un esempio per ciascuno.
1. Una comprensione condivisa di cosa significa DevOps per la tua organizzazione. – Una delle iniziative DevOps più controproducenti si verifica quando il management e il team non sono allineati sui risultati attesi. DevOps è molto più che assumere ingegneri “DevOps” e acquistare uno strumento CI/CD. Una volta raggiunto l’allineamento sul fatto che si tratta di un cambiamento di mentalità, dai potere ai team di assumersi davvero la responsabilità della consegna end-to-end del valore per il cliente.
2. Spazio e supporto per identificare e implementare cambiamenti – I team DevOps spesso individuano molti modi per migliorare la delivery e l’efficienza del team. Non dare spazio a questa esplorazione limita molto l’impatto che il tuo team può avere nel guidare il cambiamento.
3. Strumenti per misurare e identificare il successo tramite i dati – Tutti conoscono le metriche DORA e le quattro misurazioni chiave da utilizzare nella tua organizzazione di sviluppo per valutare la maturità DevOps. Sebbene siano un ottimo punto di partenza, devi identificare cosa significa essere un’organizzazione DevOps per la tua azienda – e dovresti farlo tramite i dati.
4. Un prodotto costruito per supportare la responsabilità e lo sviluppo di questa filosofia – DevOps è un’ottima filosofia per molte aziende, ma spesso le realtà non sono pronte ad abbracciare la trasformazione. È necessario essere sicuri che il proprio prodotto possa essere gestito da un team integrato di operation e sviluppo. Prodotti on-premise, prodotti con cicli di rilascio rigidi e prodotti che semplicemente non sono maturi abbastanza per supportare un tale team potrebbero non essere adatti. Noterai qualche vantaggio se il team adotta una mentalità più operativa, ma gli impatti saranno limitati.
5. Automazione e strumenti – Garantire che le cose avvengano in modo coerente e rapido, oltre ad assicurare la responsabilità rispetto agli accordi di lavoro. Uno dei cambiamenti fondamentali in un’organizzazione DevOps riguarda gli accordi di lavoro che stabilisci con il tuo team e tra i vari team. Se stai definendo un processo di test che richiede che tutto il codice sia testato per le regressioni prima della distribuzione, dovresti automatizzarlo. Occorre stabilire controlli e gate automatizzati per garantirlo. Una volta che hai implementato questi strumenti e queste pratiche, spesso obiettivi ambiziosi come la continuous deployment sono solo a pochi passi di distanza.
Assicurati che i test non solo vengano eseguiti, ma soddisfino i tuoi standard di qualità.
D: Quali tendenze emergenti vede che potrebbero avere un impatto significativo sulle strategie di trasformazione digitale in futuro?
Molte delle grandi promesse di strumenti come la transizione al DevOps si basano su dati di alto livello e risultati generali. Spesso, questi numeri eclatanti, come “la tua organizzazione è il 50 percento più efficiente”, sono quasi impossibili da misurare, e può essere difficile verificare di aver davvero raggiunto questi tipi di risultati.
Mi aspetto di vedere uno sforzo più mirato nell’identificare specifici risultati per ogni organizzazione prima di avviare un percorso di trasformazione digitale pluriennale. Questo non solo si allinea alla maggiore attenzione verso l’efficienza aziendale degli ultimi anni, ma garantisce anche il successo. Invece di obiettivi generici come quelli menzionati, traguardi specifici (ma d’impatto) come “Risolvere i problemi dei clienti il 25 percento più velocemente” sono più mirati.
Favorire la Crescita Attraverso il Mentoring
Il potere del mentoring e di una comunicazione aperta è evidente nel percorso di Jeremy Freeman. Imparando attivamente dagli altri e favorendo un ambiente collaborativo, i leader possono dare la possibilità ai propri team DevOps di raggiungere grandi risultati.
Iscriviti alla Newsletter di The CTO Club per altre interviste, approfondimenti DevOps e consigli su mentoring!