Ho scoperto il ruolo del Chief Firefighter Officer lavorando per un’azienda informatica che si barcamenava nelle tipiche difficoltà organizzative delle aziende che gestiscono produzione, progetti, sviluppo di nuovi prodotti, servizi post vendita più o meno allo stesso modo.
Li pianificano, basandosi sulle risorse note, e poiché lavorano per dipartimenti credono che il lavoro procederà in modo lineare da un dipartimento all’altro, stimano l’effort, il tempo e le risorse necessarie e, di conseguenza, i costi. Suddividono il tempo delle persone in base all’effort frammentandolo su più progetti. Sulla carta impeccabile, nella realtà impraticabile.

Immediatamente subentrano nuovi progetti, richieste dei clienti di rendere funzionante ciò che è stato consegnato, clienti che scoprono che i requisiti richiesti non erano ciò che volevano, lavori pianificati come standard che in realtà diventano sempre l’eccezione, dipartimenti in costante ritardo con conseguente ritardo nella consegna al cliente, progetti interni senza risorse, tutte allocate a risolvere i problemi con i clienti, progetti che avrebbero dovuto costituire la svolta e sono fermi al palo, priorità che si accavallano. Il cliente che fa la voce più grossa ha la meglio sulle priorità degli altri. Alla fine per consegnare quanto promesso si aggiungono risorse, togliendole ad altri progetti, si intensifica il lavoro e si aumentano i tempi di straordinari.

Una tipica azienda che lavora in costante emergenza

Quando l’azienda mi chiamò aveva affrontato il problema introducendo l’agility in modo piuttosto convenzionale, scrum, i ruoli e dopo qualche anno in cui funzionava poco e male ecco comparire gli O&KRs. Ma continuava a non funzionare e i problemi permanevano gli stessi.

Quindi che fare?

Gli proposi una giornata di workshop per capire come lavorava il sistema (sapendo che il sistema è responsabile del 94% delle performance organizzative).
Il giorno del workshop avrei dovuto accorgermi subito che non avremmo combinato nulla di buono da una serie di segnali: alcuni manager delle funzioni chiave erano perplessi e chiedevano che cosa ci stavano a fare lì mentre i product owner e gli scrum master avevano l’aria di cani bastonati come se fossero pronti a prendersi una “lavata di testa”. Così iniziò una vivace discussione sulla filiera di processi che sarebbe stato opportuno mappare, ognuno con una propria idea.

Alla fine decisero di mappare il processo di un progetto reale che avrebbe dovuto essere rappresentativo della loro modalità di lavoro come sistema. Altro segnale che avrei dovuto cogliere: si trattava di un processo parziale, non end to end (cioè dalla richiesta del cliente alla consegna della soluzione). Le scuse per non mappare end to end erano due:

• da una parte tutti non avevano consapevolezza delle variabili della domanda iniziale, quindi non sapevano come identificare la richiesta di partenza se non in modo generico e ogni volta diverso.
• Dall’altra pensavano che il ciclo di maintenance e di customer service fosse un ciclo infinito e imprevedibile. Questo significava semplicemente che non avevano alcuna analisi della domanda e della sua variabilità e facevano di ogni progetto un’eccezione, in sostanza non vedevano le relazioni sistemiche che caratterizzano i progetti.

Comunque procedemmo con la mappatura del value stream, la definizione del lead time complessivo e di quelli parziali, del process time con molti disaccordi e battibecchi. In particolare emerse che pur lavorando su progetti comuni non tutti erano al corrente di informazioni essenziali al progetto. Questo accese accuse reciproche di esclusione da quelle informazioni. Eppure si incontravano periodicamente per verificare lo stato di avanzamento dei lavori, rispettavano i rituali di scrum con i meeting che scandivano due settimane di sprint.

Ma chi si incontrava? Dove e come visualizzavano il lavoro? Come condividevano le informazioni? Come le elicitavano dai clienti? Come rendevano evidenti i problemi? Come gestivano quei problemi?

Non solo emerse che il principale mezzo di comunicazione erano le email, ne circolavano talmente tante che “insomma non si può pretendere che le leggiamo tutte”. Diversi manager, tra cui l’amministratore delegato, sbottarono parecchie volte affermando “ma questo non me lo avete detto”, “questo però non lo sapevo!”.
L’atmosfera si stava scaldando e iniziava il gioco della patata bollente che passa di mano in mano fino a quando rimane in mano all’ultimo sventurato di turno. Insomma stavamo scoperchiando il vaso di pandora quando l’amministratore prese la parola, zitti tutti e chiuse il vaso. Fu in quel momento che scoprii che il Chief Firefighter Officer lavorava sotto copertura come CEO dell’azienda.

Il Chief Firefighter Officer

Il Chief Firefighter Officer è tipicamente l’eroe che quando si presentano le situazioni di emergenza le risolve momentaneamente spostando persone da un progetto all’altro, ristabilendo le priorità in base a criteri insondabili, prendendo decisioni impulsive. Sono più diffusi di quanto pensiate e spesso hanno scalato i livelli dell’azienda perché ritenuti degli eroi. E proprio perché tali vogliono rimanere, sono in realtà i piromani che appiccano i fuochi delle emergenze per poter intervenire a spada tratta e mettere pezze che in realtà aumentano il disordine complessivo dell’organizzazione.

Quali sono le conseguenze dell’avere dei Chief Firefighter Officer in azienda?

1. La prima è sicuramente quella di spingere tutti a ottenere risultati immediati senza pensare, senza cioè riflettere su come fare meglio, in minor tempo, più efficacemente e nel modo più efficiente.
2. La seconda è quella di non identificare i problemi risalendo alla causa radice e risolverli stabilmente, una volta per tutte. Vi è ben poca gloria nel guidare un processo scorrevole risolvendo piccoli problemi di cui nessuno quasi si accorge. Il riconoscimento pubblico dell’eroe che ha spento l’incendio e salvato l’organizzazione suona molto più glorioso.
3. La terza è che le persone non crescono abituate come sono ad eseguire i compiti che vengono assegnati dal Chief Firefighter Officer senza poterli discutere.
4. La quarta è che creano un clima di paura, durante le emergenze non ci si può permettere di sbagliare e bisogna credere, obbedire e combattere. Questo clima focalizza le persone a tenere comportamenti politici dove la sopravvivenza prevale sull’efficienza e le email in copia conoscenza si moltiplicano in modo esponenziale creando infosmog e mancanza di trasparenza che diminuisce la chiarezza comunicativa. Questa attitudine prende il nome di ‘cultura della colpa’ che induce a pensare che sia sufficiente nominare un responsabile per far procedere le cose senza intoppi. Ma in processi apparentemente lineari che procedono da dipartimento a dipartimento e tornano indietro per essere rilavorati la colpa è sempre di qualcun altro. Il vero problema della cultura della colpa è che impedisce lo sviluppo di una cultura della soluzione dell’errore che richiede invece di spostare il focus dalle persone al sistema per identificare dove è accaduto l’errore e trovare il modo di modificare le attività per non permettere che accada ancora. In questo modo si instaura il circolo vizioso per cui le persone sono sovraccaricate di lavoro, il sovraccarico crea variabilità e incertezza che a sua volta aumenta sprechi in attività inutili e poco efficaci.

Si potrebbe elencarne altre, in realtà tutte queste caratteristiche concorrono nel creare un’organizzazione disfunzionale e sono spesso correlate le une alle altre per cui occorre una trasformazione che cambi la cultura organizzativa. In particolare, queste caratteristiche concorrono a creare un sistema anti-collaborativo dove è difficile sviluppare persino la cooperazione tra funzioni, team e dipartimenti.

Conclusione

In conclusione i Chief Firefighter Officer creano più problemi di quanti ne risolvono.

Lavorare in modalità firefighting comporta la continua riallocazione di persone e risorse per finire in tempo i progetti. Inoltre la modalità firefighting instaura loop di rilavorazioni che finiscono per diventare scontate, diventando la norma. Una volta che l’organizzazione entra in modalità firefighting le performance del sistema continuano a decrescere e i manager firefighter incolpano di inettitudine gli operativi mentre la frustrazione, lo scontento e il disimpegno generali aumentano.

Inoltre la convinzione che la differenza la fanno le singole persone e i loro atti di eroismo è così radicata che i Chief Firefighter Officer vengono premiati come eroi e risolutori dei problemi e promossi a ruoli manageriali. Ruoli in cui non cambieranno atteggiamento, anzi lo intensificheranno contribuendo a peggiorare le condizioni d’insieme dell’organizzazione. Chiaramente i Chief Firefighter Officer sussistono fino a quando esistono le condizioni di perenne emergenza e la condizione di emergenza fa in modo che esistano i Chief Firefighter Officer.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.