Sono passati mesi dall’inizio della missione ristrutturazione aziendale e ormai si vede bene la fine dell’anno. Negli ultimi tempi abbiamo affrontato una crescita aziendale non indifferente, non solo dal punto di vista delle persone, ma anche dei ruoli, dei dipartimenti e della cultura necessaria alla crescita stessa.

Nonostante la considerazione non possa essere definitiva, visto che continueremo a crescere ancora anche per tutto il 2022, posso già affermare che questa quest (glossario da gamer) è stata, e probabilmente sarà, una delle più complesse affrontate nella mia vita professionale. C’è tutto dentro: organizzazione, approccio filosofico/culturale/etico/economico, analisi dei dati, misurazione delle metriche di team, tecnologia, e via discorrendo. Ma alla base, sempre e solo una cosa, le persone.

Mi ricordo con nostalgia quando il mio lavoro era pensare “chissà se i miei test sulle performance rispetteranno i risultati che mi aspetto in produzione” o “come posso scalare con il tal SQL server” o ancora “voglio sistemare quella stored procedure per ridurre il tempo di risposta”. Era comunque molto impegnativo, vero, e senza studio e ricerca costante gli obbiettivi non si raggiungevano. Però era piuttosto deterministico. Diciamo che con un relazionale in certi casi hai quel dipende che i fan delle regole scolpite non digeriscono, ma era ancora macchina, software e tecnologia in generale. Oggi il mio lavoro è cambiato, un po’ per necessità, ma anche, in parte, per piacere e per sfruttare meglio la mia forma mentis, tutto sommato orientata all’organizzazione e all’ottimizzazione.

Scrivo questo post per condividere alcune riflessioni su quanto sia importante muoversi bene in contesti di migrazione come quello che stiamo vivendo, contesti in cui anche l’influsso di cambiamenti radicali a livello sociale (vedi pandemia) ci pone di fronte a scenari del tutto nuovi, con sfide non previste e difficoltà mai avute.

In passato molti di noi bramavano la possibilità di lavorare in remoto, di avere trattamento e approccio smart, di essere più indipendenti da tempo per ragionare ad obbiettivi. Oggi, alcune di queste condizioni sono fisiologicamente diventate uno standard, per la maggior parte accettate come nuovo modello. Altre hanno toccato l’esagerazione, come il non vedersi più di persona nemmeno quando possibile/importante, il numero delle call conference, il fatto di avere tutto e subito, sempre online. E ora, il metaverso (concetto che io ricordo dagli anni 90 da un romanzo intitolato Snow Crash) e tutte le innovazioni che, come la storia ci insegna, vengono idolatrate e demonizzate da chi, rispettivamente, vede solo vantaggi o tragedie apocalittiche. Oggi, comunque, abbiamo la gara a quello che va di moda e i social sono la monoposto con cui parteciparvi.

Ma crescere e cambiare vanno ben oltre questo. Quando abbiamo dovuto agire per predisporre un nostro percorso, non dormivo la notte, per paura (che ho tutt’ora) di una implosione aziendale e/o di non essere all’altezza. Il primo problema è stato avere una deadline stretta, che ci ha dato un ritmo atipico per fare selezione del personale. Per fortuna, la possibilità di lavorare da remoto con pochi requisiti di presenza ci ha dato il quid per venirne fuori egregiamente, visto che il resto è già people-first fin da quando abbiamo avviato l’attività. Le persone aggiunte seguono tutte i nostri principi, e non potremmo scegliere diversamente, pena “non remare tutti nella stessa direzione”.

Ma il vero problema, che é quello per cui ho fatto più fatica e che tuttora mi tiene sotto battuta, è stata la scalabilità dei nostri processi in essere. Ah, come funzionavano bene quindici persone fa! Da qualche tempo, invece, ogni cosa aveva iniziato a rallentare, si avevano stalli continui, la consapevolezza trasversale calava sempre di più e le prime reazioni precipitose rischiavano di portare a figure gatekeeper. Forse è naturale arrivare a ciò nella mente di tutti noi, a prima vista. Ma per chi crede nei principi della cultura DevOps e osserva più a lungo la situazione, questa non può essere la soluzione.

Ed è qui che abbiamo deciso di cambiare seriamente. Nessuna reorg, nessuna variazione all’organigramma. La gerarchia è rimasta piuttosto piatta, e non ci siamo fatti sopraffare dalla voglia di adattare il software sulla base della struttura aziendale (Team Topologies e la legge di Conway). Al contrario, abbiamo aggredito i problemi uno ad uno, cambiando a volte il processo, altre volte le abitudini. Abbiamo incluso persone nuove, con tanta esperienza sia con lo strumento (Azure DevOps) sia con le migrazioni culturali in realtà ben più grandi della nostra, abbiamo destabilizzato, di certo, ma stiamo già percependo i risultati. Per non dimenticare che l’appoggio del mio socio Michael Denny è stato indispensabile. I principi condivisi dall’azienda partono, in fondo, da noi due.

È importante avere una cultura aziendale condivisa in termini DevOps, ancor prima di pensare a qualunque strumento o prodotto. E non basta il coraggio, non serve il controllo gerarchico, ma un vero team di persone affiatate e pronte all’adattamento

La prossima retrospettiva verrò certamente rimproverato per l’impeto e la spinta rivoluzionaria, insieme a chi ha fatto sì che questo accadesse (il collega e amico Michele Ferracin, che mi ha consigliato anche il libro di cui sopra). Non potrò dare torto a chi lo farà; i cambiamenti fatti, forse, potevano essere affrontati con meno foga. Il fatto è che il processo antecedente alle modifiche non sarebbe più stato sostenibile e il rischio sarebbe stato quello di incappare in scelte da punto di non ritorno. Ho trattenuto il fiato e, credetemi, rispetto al quantitativo di variazioni, sono stato praticamente trasparente.

E ora? Beh, abbiamo una kanban board ben fatta, che rispecchia perfettamente un processo semplice, meno stati, meno informazioni inutili, meno dispersione e più consapevolezza trasversale. Certo, dobbiamo pulire gli arretrati, ma il peggio é passato. Siamo anche pronti a ridurre il numero di strumenti, perché essi sono stati semplicemente un supporto per la nostra cultura, sempre molto forte.

Con questo post, in conclusione, volevo sottolineare quanto sia importante avere una cultura aziendale condivisa in termini DevOps, ancor prima di pensare a qualunque strumento o prodotto. Senza questa radicata visione, la nostra azienda non sarebbe mai riuscita a reggere la crescita fino ad ora, né tantomeno a cambiare radicalmente pur mantenendo senza implodere. E non si tratta di hard skill, ma di un duro e prolungato lavoro di persone che remano dalla stessa parte, da oggi ancora più in maniera coerente e sincronizzata. Non basta il coraggio, non serve il controllo gerarchico, ma un vero team di persone affiatate e pronte all’adattamento.