Nelle organizzazioni si parla molto di decisionidata-driven. L’espressione suggerisce un processo quasi lineare: osserviamo i fatti, li analizziamo e scegliamo la soluzione migliore. La realtà manageriale è molto meno ordinata. Tra ciò che accade e ciò che decidiamo esiste uno spazio invisibile popolato da selezione, interpretazioni, esperienze pregresse, convinzioni e bias.
È in questo spazio che nasce una parte significativa dei conflitti organizzativi e degli errori decisionali.
La Ladder of Inference offre una rappresentazione semplice di questo processo. La sua forza non consiste nel suggerire che i manager debbano eliminare le inferenze: sarebbe impossibile. Il valore sta nelrenderle visibili, così da distinguere ciò che sappiamo da ciò che abbiamo concluso.
Il problema non sono i dati, ma il percorso che facciamo a partire dai dati
Immaginiamo una riunione di avanzamento. Il responsabile di una business unit arriva quindici minuti in ritardo, interviene poco e durante la presentazione guarda più volte il telefono. Il project manager conclude che non considera il progetto prioritario.
Il comportamento osservato è reale. La conclusione, però, non è un fatto: è il risultato di un percorso mentale.
Avremmo potuto osservare che il manager era in ritardo, ha parlato poco e ha guardato il telefono. Abbiamo selezionato questi elementi tra molti altri. Abbiamo attribuito loro un significato — disinteresse — e formulato un’assunzione: il progetto non è importante per lui. Da quell’assunzione traiamo una conclusione e, se il processo si ripete, costruiamo una convinzione stabile: «il business non supporta il progetto».
Da quel momento iniziamo inevitabilmente ad agire sulla base di quella convinzione. Coinvolgiamo meno il manager, smettiamo di chiedergli feedback, interpretiamo ogni sua assenza come conferma.
La convinzione contribuisce così a produrre la realtà che sembrava soltanto descrivere.
I gradini della scala
Alla base esiste la realtà osservabile: eventi, comportamenti, numeri, conversazioni. Nessuno, tuttavia, elabora tutta l’informazione disponibile.Selezioniamo alcuni dati e ne ignoriamo altri.
A ciò che selezioniamo attribuiamo un significato, spesso influenzato dal contesto e dalle nostre esperienze. Su quel significato costruiamo assunzioni; dalle assunzioni traiamo conclusioni; le conclusioni consolidate diventano convinzioni e le convinzioni orientano le nostre azioni.
Il processo è rapidissimo e in larga parte automatico. Il problema nasce quando arriviamo in cima alla scala dimenticando di averla percorsa. Una conclusione ci appare allora come un fatto.
«Il cliente vuole questa funzionalità.»
«Il team non è abbastanza autonomo.»
«Quella persona resiste al cambiamento.»
«Agile qui non funziona.»
«Il progetto è in ritardo perché IT è lento.»
Sono tutte affermazioni che possono essere vere. Ma possono anche rappresentare conclusioni costruite selezionando solo una parte della realtà.
Quando le inferenze diventano problemi organizzativi
In un’organizzazione il fenomeno non riguarda soltanto il singolo individuo. Le inferenze possono diventare collettive.
Una funzione commerciale può sviluppare la convinzione che IT sia burocratica. IT può convincersi che il business cambi continuamente idea. Il management può ritenere che i team abbiano bisogno di maggiore controllo, mentre i team possono interpretare lo stesso controllo come mancanza di fiducia.
Ogni gruppo seleziona eventi coerenti con la propria interpretazione e finisce per rafforzarla.
Si crea così un circuito auto-rinforzante nel quale due letture parziali della realtà diventano progressivamenteidentità organizzative.
Il conflitto smette di riguardare un problema concreto e diventa una storia: «noi siamo fatti così, loro sono fatti cosà».
A quel punto cambiare processo o organigramma serve relativamente poco. Prima occorre rendere discutibili le convinzioni che governano il comportamento.
Scendere la scala prima di decidere
La Ladder of Inference diventa uno strumento manageriale quando impariamo a percorrerla anche nella direzione opposta.
Davanti a una conclusione forte possiamo chiederci quali dati osservabili la sostengano, quali informazioni abbiamo selezionato e quali potremmo avere escluso. Possiamo interrogarci sul significato attribuito ai dati, sulle assunzioni formulate e soprattutto domandarciquale evidenza ci convincerebbe che la nostra conclusione è sbagliata.
Queste domande non impongono relativismo. Un manager deve comunque decidere.
Introducono però una distinzione fondamentale travelocità decisionale e fretta cognitiva.
Decidere rapidamente può essere necessario. Trasformare rapidamente un’interpretazione in certezza è molto più pericoloso.
Advocacy e inquiry: rendere visibile il ragionamento
Una delle applicazioni più interessanti consiste nel modificare il modo in cui le persone discutono.
Nelle riunioni manageriali utilizziamo spesso l’advocacy: sosteniamo una posizione e cerchiamo argomenti che la rafforzino. È utile, ma se tutti fanno soltanto advocacy la conversazione diventa una competizione tra conclusioni.
L’alternativa non è rinunciare alle proprie idee, ma combinareadvocacy e inquiry: spiegare come siamo arrivati a una conclusione e contemporaneamente investigare il ragionamento degli altri.
Invece di dire:
«Il cliente non vuole questa soluzione.»
possiamo ragionare in modo differente:
«Nelle ultime tre interviste nessun cliente ha utilizzato spontaneamente questa funzione; da questo sto inferendo che il valore percepito sia basso. Voi vedete dati che portano a una conclusione diversa?»
La seconda formulazione non è più debole.
Èpiù verificabile.
Una buona discussione manageriale non dovrebbe quindi mettere a confronto soltanto opinioni, ma rendere visibili i percorsi che hanno prodotto quelle opinioni.
Il caso concreto: una trasformazione Agile che sembra non funzionare
Immaginiamo un’azienda industriale che abbia introdotto team Agile per accelerare lo sviluppo di servizi digitali.
Dopo nove mesi il management è insoddisfatto. I rilasci non sono aumentati quanto previsto e alcune iniziative accumulano ritardi.
Durante uno steering committee emerge una conclusione apparentemente condivisa:
«I team non sono ancora abbastanza maturi per lavorare in autonomia.»
La risposta proposta è aumentare il controllo: reporting settimanale, approvazione preventiva delle stime, nuovi checkpoint e coinvolgimento diretto dei responsabili funzionali nella pianificazione degli sprint.
Prima di procedere, il facilitatore utilizza la Ladder of Inference.
Quali sono i dati osservabili?
Tre release hanno subito ritardi. Alcuni sprint non hanno raggiunto lo Sprint Goal. Due team hanno chiesto frequentemente decisioni al management.
Da questi dati il management ha attribuito un significato: difficoltà nella gestione autonoma. L’assunzione successiva è che la causa risieda nella maturità dei team. La conclusione diventa quindi che serva maggiore supervisione.
Scendendo la scala emergono però dati rimasti fuori dalla narrazione iniziale.
I team dipendono da una funzione infrastrutturale esterna per ogni rilascio. Il Product Owner di uno dei prodotti dedica al ruolo meno del 30% del proprio tempo. Cinque decisioni architetturali richiedono l’approvazione di un comitato che si riunisce ogni due settimane. Inoltre, le priorità sono state modificate dal management quattro volte in tre mesi.
La stessa realtà produce ora un’interpretazione differente.
Forse il problema non è la mancanza di autonomia dei team, maun sistema organizzativo che dichiara autonomia senza trasferire realmente le condizioni necessarie per esercitarla.
La decisione cambia.
Invece di introdurre ulteriore reporting, l’azienda riduce le dipendenze infrastrutturali, assegna Product Owner dedicati e delega alcune decisioni architetturali entro guardrail condivisi.
Tre mesi dopo il lead time migliora senza aumentare i livelli di controllo.
La Ladder of Inference non ha fornito la soluzione. Ha impedito cheuna conclusione plausibile diventasse prematuramente una diagnosi.
Il legame con Agile e le retrospettive
Il modello è particolarmente utile nei contesti Agile perché molte pratiche Agile dipendono dalla capacità di trasformare esperienza in apprendimento.
Una retrospective che produce frasi come «la comunicazione non funziona» o «il business cambia sempre priorità» è ancora in cima alla scala.
Il lavoro interessante comincia quando il team torna ai dati osservabili.
Che cosa è accaduto concretamente? Quante priorità sono cambiate? Chi le ha cambiate? In quale momento? Quale effetto hanno prodotto? Quale assunzione avevamo fatto sulla stabilità del backlog?
Questa disciplina evita che la retrospective diventi uno spazio nel quale si consolidano narrazioni organizzative invece di metterle alla prova.
Agile richiede feedback, ma il feedback produce apprendimento soltanto quando siamo capaci di distinguere osservazione e interpretazione.
Leadership e certezza
Per un leader la Ladder of Inference introduce una tensione particolarmente importante.
L’organizzazione chiede al management chiarezza e decisione. Questo può creare l’idea che un buon leader debba mostrare certezza.
Ma certezza e chiarezza non sono la stessa cosa.
Un leader può essere estremamente chiaro dichiarando: «questa è la decisione che prendo sulla base dei dati disponibili e di queste tre assunzioni».
Una formulazione di questo tipo mantiene l’accountability senza trasformare il ragionamento in dogma.
In contesti complessi questa capacità diventa decisiva. Più aumenta l’incertezza, più le decisioni dipendono da ipotesi. Nascondere quelle ipotesi dietro una comunicazione assertiva non rende la strategia più robusta:la rende soltanto meno falsificabile.
La leadership matura non consiste quindi nel rinunciare alle convinzioni, ma nel possedere convinzioni sufficientemente solide da orientare l’azione e sufficientemente aperte da poter essere corrette dall’evidenza.
Ladder of Inference e change management
Nei programmi di cambiamento il modello offre una seconda applicazione rilevante: comprendere la resistenza.
Quando una persona contesta una trasformazione, il management può salire rapidamente la propria scala:
«Non comprende il progetto.»
«Ha paura di perdere potere.»
«È resistente al cambiamento.»
Sono spiegazioni possibili, ma rimangono inferenze.
Se vengono trattate come fatti, orientano immediatamente le azioni: più comunicazione, formazione, pressione o escalation.
Se la diagnosi è sbagliata, queste azioni possono aumentare proprio la resistenza che intendono ridurre.
Scendere la scala significa invece tornare ai comportamenti osservabili e investigarne il significato. Una persona che contesta il nuovo processo potrebbe non opporsi al cambiamento; potrebbe possedere informazioni operative che il progetto non ha considerato.
Il dissenso diventa cosìuna fonte potenziale di informazione, non automaticamente un problema da correggere.
Dalle decisioni data-driven alle decisioni assumption-aware
Le organizzazioni contemporanee investono enormemente nei dati. Dashboard, KPI, analytics e intelligenza artificiale aumentano continuamente la quantità di informazione disponibile.
Ma più dati non eliminano automaticamente le inferenze.
Possiamo costruire una dashboard perfetta e interpretarla attraverso una convinzione sbagliata e possiamo selezionare KPI coerenti con ciò che vogliamo dimostrare. Possiamo, anche, confondere correlazione e causalità ed ignorare segnali che contraddicono la strategia.
La vera evoluzione non consiste quindi soltanto nel diventaredata-driven, ma nel diventareassumption-aware: consapevoli delle ipotesi che collegano i dati alle decisioni.
Ogni decisione strategica significativa potrebbe essere accompagnata da una domanda semplice:
Quali assunzioni devono essere vere perché questa decisione sia corretta?
Da questa domanda discende immediatamente la successiva:
Come possiamo verificarle?
Rendere il pensiero osservabile
La Ladder of Inference non elimina bias, conflitti o errori. Offre qualcosa di più pragmatico:un linguaggio per discuterli.
Il suo valore manageriale nasce dalla possibilità di interrompere, anche solo per qualche minuto, l’automatismo con cui trasformiamo osservazioni in certezze.
Nelle organizzazioni complesse molte decisioni sbagliate non derivano dalla mancanza di competenza. Nascono da persone competenti che osservano porzioni differenti della realtà, attribuiscono significati differenti agli stessi eventi e successivamente discutono le proprie conclusioni come se fossero fatti.
Rendere visibile la scala significa rendere visibile il ragionamento.
E quando il ragionamento diventa osservabile può essere discusso, verificato e migliorato.
Per un manager questa è una competenza meno appariscente della capacità di decidere velocemente, ma probabilmente più importante:sapere quando fidarsi della propria esperienza e quando fermarsi un gradino più in basso per chiedersi se ciò che appare evidente sia davvero un fatto o soltanto una conclusione diventata familiare.
Perché nelle organizzazioni il problema raramente è avere delle convinzioni.
Il problema nasce quando dimentichiamo il percorso attraverso il quale le abbiamo costruite.






