Decidere bene è una questione di condizioni

Capita più spesso di quanto ci piaccia ammettere: un team capace, con un metodo solido e anche con gusto, prende una decisione che si rivela sbagliata. Non per una questione di distrazione o incompetenza e spesso capita anche il contrario, dove le stesse persone, in un altro progetto, decidono benissimo.

Se la qualità di una decisione dipendesse soprattutto da chi la prende - dal talento, dalla seniority, dal "fiuto" - questa oscillazione non dovrebbe esistere. Le stesse persone dovrebbero decidere con la stessa qualità ovunque, e il fatto che non sia così ci dice qualcosa di scomodo: a fare la differenza, da un progetto all'altro, sono le condizioni in cui si decide, più ancora di chi decide.

È uno spostamento piccolo nella formulazione e grande nelle conseguenze.
La domanda interessante smette di essere "chi sa decidere bene?" e diventa "cosa rende adeguata una decisione?".
E, soprattutto: “quelle condizioni si possono progettare?”

Perché la domanda diventa urgente adesso

La domanda non è nuova. È diventata urgente adesso, per una ragione precisa.

Con l'AI il costo di eseguire è crollato, e prototipare, generare varianti, produrre artefatti richiede sempre meno tempo e fatica.
La conseguenza la conosciamo: quando eseguire è facile, il peso del lavoro si sposta a monte, sulle scelte che orientano l'esecuzione. È quello che intendevamo dicendo che scegliere è già progettare.

Lì però parlavamo di una persona che sceglie: dove ha senso introdurre l'AI e con quale ruolo nel processo. C'è un secondo movimento, meno discusso, in cui quella persona esce dall'istante della decisione.
L'AI comincia a decidere in autonomia e ci sono sistemi che selezionano, ordinano, raccomandano, agiscono senza che qualche persona sia presente nel momento in cui la scelta avviene.

E qui salta il modello a cui siamo abituati. Finché a decidere è una persona, possiamo affidarci al suo giudizio nell'istante della decisione. Se in quell'istante non c'è una persona, il giudizio non può essere inserito lì, ma deve essere stato predisposto prima, nelle condizioni che il sistema eredita. L'oggetto da progettare smette di essere la singola scelta e diventa il contesto che la rende adeguata anche quando nessuno è nel loop.

Cosa rende adeguata una decisione

Vale la pena fermarsi su cosa intendiamo per "adeguata".

Una decisione adeguata non è quella che, col senno di poi, si è rivelata giusta. Il senno di poi non è progettabile. È adeguata una decisione presa in condizioni che rendevano possibile una buona scelta e recuperabile una cattiva. Il metro si sposta dall'esito al contesto: la domanda diventa se ci eravamo messi nelle condizioni per decidere bene, prima ancora di sapere se abbiamo azzeccato.

Quali sono queste condizioni? Una prima articolazione, da mettere alla prova:

• il problema è inquadrato, così da non spendere energia su una domanda sbagliata
• la posta in gioco e la reversibilità sono esplicite, perché una scelta costosa e difficile da correggere chiede cautele che una leggera non giustifica
• è chiaro chi risponde della decisione, dato che una responsabilità diffusa è solo un altro modo di dire nessuna
• le informazioni rilevanti sono disponibili e leggibili, anche dal sistema che eventualmente decide
• esistono vincoli intenzionali che contengono lo spazio delle scelte, invece di lasciarlo aperto all'infinito

Sono volutamente condizioni, non regole. Una regola dice cosa fare; una condizione dice cosa deve essere vero perché il fare abbia senso. È una distinzione che, lavorando su sistemi complessi, abbiamo imparato a non dare per scontata.

Decisione come capacità organizzativa

C'è una tentazione, a questo punto: leggere tutto questo come una questione di competenza individuale. Insegniamo alle persone a decidere meglio, a riconoscere le condizioni, a fermarsi al momento giusto. È utile, ma è il livello sbagliato.

Se l'adeguatezza di una decisione dipende dalle condizioni, allora il lavoro vero è progettare quelle condizioni a livello di organizzazione, non sperare che il singolo senior, nel momento giusto, abbia la lucidità di crearle da sé. Una capacità di decisione che dipende dall'eroismo di poche persone è in realtà un punto di fragilità. La differenza tra un'organizzazione che decide bene e una che decide bene per caso sta tutta qui.

È anche il punto in cui si accumula, silenziosamente, un debito. Di solito lo si legge come effetto della velocità, dell'esecuzione che corre più del giudizio, e ne abbiamo scritto altrove. Quello che ci interessa qui sta più a monte: le condizioni di decisione che un'organizzazione non ha mai progettato, e che fino a ieri restavano invisibili perché c'era sempre qualcuno, nel punto giusto, a supplire con il proprio giudizio. Gli strumenti che abbattono il costo di eseguire non sono la causa di quel debito. Lo rendono esigibile, togliendo il tempo e le persone che lo tenevano coperto.

E poi c'è l'accountability, che a questo livello è una condizione molto concreta, prima che un principio.
Quando un sistema decide in autonomia, la domanda "chi risponde?" non ha una risposta ovvia. Se la responsabilità non è stata progettata dentro le condizioni (assegnata, resa tracciabile, collegata a chi ha predisposto il sistema), l'autonomia non distribuisce potere decisionale: apre un vuoto in cui, quando qualcosa va storto, non risponde nessuno.

È una domanda che abbiamo messo alla prova anche in contesti pratici. A giugno, in un workshop a NobilitaLab, l'abbiamo affrontata su una challenge reale: come ricostruire responsabilità ed escalation quando a decidere entra un sistema.

Predisporre le decisioni

Torniamo all'inizio. Se la qualità di una decisione vive nelle sue condizioni, e se quelle condizioni si possono progettare, allora predisporle è a tutti gli effetti un atto di design, diverso dal decidere, e spesso altrettanto rilevante, nel momento in cui eseguire è diventato la parte facile.

È una direzione che stiamo esplorando: progettare le condizioni organizzative perché le decisioni di prodotto siano di qualità, soprattutto quando la fretta di rilasciare spinge a saltare le fasi, o quando a decidere è il prodotto stesso, in autonomia. La chiamiamo, per ora, Decision-enabling Design. Conta meno il nome della domanda che apre, ed è una domanda che vale la pena lasciare aperta: quando il prodotto decide da solo, le condizioni di quella decisione, chi le ha progettate?