Il DevOps è Leadership

Praticamente da quanto ho cominciato a lavorare ho notato che molto spesso i corsi di formazione manageriale, che siano dedicati all’area di gestione dei progetti o alla comunicazione, diventano occasione, per i partecipanti, di una sorta seduta di “autocoscienza”, in perfetto stile alcolisti anonimi.

In pratica a un certo momento del corso qualcuno “dà il La” e tutti partono con una serie di considerazioni più o meno critiche sulla propria azienda, sulle modalità di conduzione di progetti e clienti, piuttosto che sulle doti (o sulla mancanza delle stesse) di comunicazione e leadership dei propri superiori, diretti o meno.

La leadership, in particolare, sembra essere un’esigenza sempre più sentita e diffusa, tanto da ritrovarla continuamente citata nei post dei vari social professionali o nelle ricette miracolose che il guru di turno propone nel proprio libro “assolutamentedacomprarealtrimentinondiventeraimairealizzatosullavoro”.

Anche il solo fatto che una ricerca del sostantivo fatta sul “motore di ricerca con tante O” tiri fuori 554 MILIONI di risultati (a ieri) la dice lunga sul fenomeno.

Io non voglio entrare nel merito “sociopolitico” della questione, ma temo di non potermi sottrarre dal dire la mia sull’argomento, almeno per quanto riguarda l’aspetto più legato al DevOps, così come accennato nell’ormai noto post apripista.

Perchè il DevOps è Leadership?

La risposta risiede nella necessità, da parte di un buon DevOps Officer (figura che, da letteratura, dovrebbe stare “al latere” del PM di sviluppo e del responsabile di esercizio) di essere autorevole e di “condurre” i gruppi di lavoro dei due schieramenti, il Dev e l’Ops, verso l’obiettivo comune di far arrivare l’applicazione in esercizio, facendo in modo al contempo di diffondere la cultura della collaborazione ed evitando di ritrovarsi con due fazioni che si parlano solo a colpi di “email bollate”.

Quando scritto rende evidente che una figura di questo tipo deve avere ottime doti di comunicazione, molta pazienza e una competenza tale da non poter essere facilmente messa in discussione nei momenti di conflitto, quando alcune decisioni che devono essere prese scontenteranno l’una o l’altra parte.

Il tutto mantenendo sempre al minimo quella che può essere vista come “indebita ingerenza” verso la formale autorità dei responsabili “tradizionali”, fungendo invece da facilitatore, da “spingitore di gruppi di lavoro“, aiutando gli altri a lavorare meglio sobbarcandosi quei compiti “connettivi” che consentono a un progetto applicativo di andare avanti senza troppi scossoni.

E’ la politica del “piano di scale” come la chiamo io, cioè l’attitudine ad andare a parlare di persona con il tecnico di turno per sbloccare una situazione, senza mandare email “fire and forget”.

E quando la figura di Officer non è presente su un progetto o in un’organizzazione? In quel caso sta a ognuno dei componenti del gruppo adottare la forma mentis adatta a portare a casa il risultato con la soddisfazione di tutti, anche se, nella mia esperienza, alla fine il DevOps Officer “ufficioso”, cioè la persona che è più naturalmente portata a darsi da fare per migliorare la situazione e risolvere i conflitti emerge sempre, anche se spesso, purtroppo, è tutto lavoro extra che non gli viene riconosciuto.

Un PM che stimo molto una volta mi ha detto che stava misurando la sua attività di DevOps con il contapassi, penso che mai metodo di misurazione sia stato più azzeccato.

Detto questo, posto che non ho la ricetta finale per il “Vero Leader”, vi lascio con un paio di link di approfondimento che a mio parere rendono bene l’idea del tipo di Leadership e il percorso di crescita personale che dovrebbe fare un buon DevOps Officer (ufficialmente designato o meno) per diventare realmente efficace nel suo lavoro:

Il Leader gentile

Il Leader secondo Amazon

La Servant Leadership secondo Adam Bowen

Nonché, tornando al tema delle sedute di autocoscienza di inizio articolo, con la frase detta dagli alcolisti anonimi all’inizio e alla fine di ogni seduta, che ho letto recentemente su Dylan Dog (poi dice che i fumetti non sono educativi) e che è singolarmente vicina allo stato d’animo che, secondo me, dovrebbe avere un DevOps Officer quando si appresta a “entrare in campo”.

“Signore, concedimi la serenità di accettare le cose che non posso cambiare, il coraggio di cambiare quelle che posso e la saggezza di conoscere la differenza”

Alla prossima.