Perché i leader intelligenti saltano i dettagli e chiedono il cambiamento

La chiamata che ha cambiato il mio modo di pensare alle retrospettive

Michael Heap, un leader ingegneristico, è stato recentemente coinvolto in una chiamata con il suo omologo ingegneristico e il loro SVP di ingegneria. Qualcosa era andato storto—non catastrofico, ma abbastanza serio da meritare l'attenzione dei dirigenti. Mentre Heap iniziava a spiegare la sequenza degli eventi, l'SVP lo ha interrotto con una frase che inizialmente sembrava sprezzante: "Michael, non voglio i dettagli."

L'SVP ha continuato, spiegando che se fossero entrati nei dettagli, le ragioni sarebbero state perfettamente ragionevoli. Avrebbe capito le decisioni, avrebbe empatizzato con il team, e poi—criticamente—la stessa cosa sarebbe successa di nuovo. La sua domanda finale ha riformulato l'intera conversazione: "Voglio sapere cosa stiamo cambiando."

All'inizio, Heap pensava che fosse una scorciatoia—un leader che evitava la complessità disordinata di un incidente reale. Ma presto si rese conto che era il contrario. L'SVP stava dichiarando fiducia: "Credo già in te. Ora parliamo di cosa succede dopo."

Il problema con "Perché è successo?"

La maggior parte delle organizzazioni risponde al fallimento ponendo una singola domanda: "Perché è successo?" È una domanda a cui tutti sanno rispondere. I team scrivono cronologie, ricostruiscono decisioni e mappano le dipendenze. Producono un documento che spiega la combinazione specifica di eventi che ha portato all'incidente.

Tutti annuiscono. Dicono: "Ha senso." E poi proseguono con la loro giornata. Ma come sottolinea Heap, capire un problema non equivale a risolverlo. In effetti, una buona spiegazione può peggiorare le cose. Una volta che tutti concordano che il comportamento era ragionevole, l'urgenza di cambiare qualcosa svanisce.

Quando un incidente viene inquadrato come una sequenza sfortunata ma comprensibile di eventi in cui nessuno è in colpa, nulla cambia. Sei mesi dopo, lo stesso fallimento si ripete, e tutti si chiedono come ci siano finiti di nuovo.

Spostare la domanda

Per guidare un vero cambiamento, Heap sostiene che le organizzazioni dovrebbero smettere di chiedere "Perché è successo?" e invece chiedere: "Cosa stiamo cambiando affinché la stessa classe di fallimento sia meno probabile la prossima volta?"

Questa riformulazione ha implicazioni profonde. Considera queste comuni spiegazioni di retrospettive:

• "Ce lo siamo persi perché Alice era in ferie e Bob pensava che il team Widgets fosse responsabile." La vera domanda: Come rendiamo la proprietà inequivocabile quando qualcuno non è disponibile?
• "I requisiti sono cambiati tre giorni prima del lancio." La vera domanda: Cosa succede quando i requisiti cambiano all'interno della finestra di lancio?
• "L'avviso è scattato, ma l'ingegnere di turno aveva già gestito venti avvisi a basso valore quella sera." La vera domanda: Come miglioriamo il rapporto segnale-rumore dei nostri avvisi?

Ciascuno di questi spostamenti sposta l'attenzione dalla colpa individuale al miglioramento sistemico. Come nota Heap, "Di solito non sono le persone a dover cambiare." Stanno prendendo le migliori decisioni possibili con le informazioni, gli incentivi e i vincoli che hanno intorno.

Perché le buone spiegazioni non sono soluzioni

Heap è particolarmente critico verso le retrospettive piene di impegni vaghi come "dovremmo coinvolgere il supporto prima" o "dobbiamo comunicare meglio." Il suo preferito: "La prossima volta saremo più attenti." Questi sono, nelle sue parole, "una raccolta di speranze travestite da progresso."

Se un'azione correttiva dipende dal fatto che le persone ricordino una conversazione di sei mesi fa, non hai un'azione correttiva—hai folklore organizzativo. Heap propone un semplice test: Se tutti i coinvolti nell'incidente lasciassero l'azienda domani, la soluzione funzionerebbe ancora? Se la risposta è no, allora le persone potrebbero aver imparato qualcosa, ma il sistema è ancora destinato a fallire.

La domanda più forte è: "Se la stessa situazione si verificasse domani, cosa porterebbe a un risultato diverso?" Un processo che forza una decisione è un miglioramento. Un sistema che previene la classe di errore è ancora più forte.

Il rischio del processo fine a se stesso

Ma Heap mette in guardia dal correggere eccessivamente. Non ogni fallimento merita un nuovo processo. È così che si costruiscono ambienti in cui nessuno vuole lavorare. A volte il costo di prevenire la ricorrenza è più alto del costo di accettare occasionalmente il fallimento—e va bene così.

La chiave è accettare il fallimento con gli occhi aperti. "Stiamo accettando consapevolmente questo rischio" è fondamentalmente diverso da "abbiamo detto che ci impegneremo di più e tutti si sono sentiti meglio." Il primo è una decisione strategica; il secondo è un placebo emotivo.

La fiducia come strumento di leadership

Riflettendo sulla chiamata, Heap ora vede l'impazienza dell'SVP come una dichiarazione di fiducia. Il dirigente non aveva bisogno di prove che il team fosse competente o ben intenzionato. Era disposto a partire da quel presupposto. Se l'indagine avesse mostrato il contrario, si sarebbe potuto gestire separatamente.

Ciò che l'SVP non voleva era che l'empatia diventasse il meccanismo attraverso il quale l'organizzazione si assolveva dal dover cambiare. Questa è una distinzione sottile ma critica. L'empatia non è un sostituto del miglioramento.

Come conclude Heap, "A volte la cosa più utile che un leader può dire è: 'Credo in te. Non ho bisogno dei dettagli. Dimmi cosa stiamo cambiando.'"

Perché questo è importante per i team di ingegneria

Questa lezione è particolarmente rilevante per i team di ingegneria, dove le retrospettive sono un punto fermo della risposta agli incidenti. Il formato tradizionale—cronologia, causa principale, azioni correttive—spesso produce documenti che sono approfonditi ma inefficaci. Spostando l'attenzione dalla spiegazione al cambiamento, i team possono rompere il ciclo di incidenti ricorrenti.

Parla anche di un principio di leadership più ampio: fidati della competenza del tuo team e rendi il sistema responsabile. Le persone sono raramente la causa principale dei fallimenti sistemici. Prima le organizzazioni interiorizzeranno questo, prima smetteranno di ripetere gli stessi errori.