Theory of Change e unknown unknowns

TL;DR: Durante un workshop per costruire una ToC su sostenibilità digitale, mi è stata fatta una domanda molto intelligente: “E se cambia tutto?” La risposta non è nella precisione del piano, ma nel distinguere cosa non cambia mai (l’Impact) da cosa deve essere flessibile (tutto il resto). Gli unknown unknowns non si prevengono, si navigano.

Quando la mappa incontra la realtà

Workshop di due giorni con il team di un’azienda per costruire una Theory of Change su un progetto di sostenibilità digitale. Avevamo fatto tutto bene: backwards mapping preciso dal goal a lungo termine (“riduzione del 40% dell’impatto ambientale delle infrastrutture IT per utente entro 2 anni“), outcomes intermedi chiari, assunzioni esplicitate, metriche definite a ogni livello. Sulla lavagna di Miro c’era una prima versione della ToC che sembrava perfetta.

Poi è arrivata la domanda.

Uno delle persone del team, quello che di solito sta zitto e ascolta, alza la mano: “Scusa Fullo, ma questa roba funziona fino a quando non cambia niente, giusto? Tipo, noi abbiamo mappato tutto assumendo che la nostra architettura resti quella. Ma se tra sei mesi il CTO decide di migrare tutto su una piattaforma diversa? O se esce una tecnologia che rende obsoleto quello che stiamo ottimizzando? O se il fornitore cloud cambia le sue metriche di sostenibilità e non possiamo più misurare nello stesso modo?“

Silenzio in stanza. Perché aveva ragione. Nella testa delle persone si era formata una mappa bellissima di un territorio che poteva cambiare completamente sotto i nostri piedi.

“Esatto,” gli ho risposto. “Questa ToC non ti protegge dagli unknown unknowns. Non può farlo. Ma ti dà qualcosa di più importante: la struttura per navigarli quando emergono senza andare nel panico o buttare via tutto.“

Da lì è partita una discussione di un’ora che ha cambiato completamente il modo in cui quel team guardava la loro ToC. Non come un piano rigido (“se succede X facciamo Y“), ma come una bussola (“vogliamo arrivare lì, e quando cambia qualcosa troviamo una strada diversa mantenendo la direzione“).

Quella discussione mi ha fatto capire che è importante, nel far utilizzare concetti come quelli della Theory of Change, di evitare semplificazioni che portano a ragionare come se ci fosse una precisione assoluta nelle assunzioni originali ma nel dare gli strumenti per distinguere cosa non cambia mai (l’Impact che si vuole creare) da cosa deve essere flessibile (le Activities per arrivarci).

La ToC e il suo punto cieco strutturale

Parliamoci chiaro: la Theory of Change ha un punto cieco gigantesco.

Si basa su backwards mapping da un futuro che immagini. Ma per definizione, gli unknown-unknowns sono fuori dalla tua immaginazione. Non puoi mapparli a ritroso se non sai che esistono.

Facciamo una distinzione fondamentale:

Known unknowns (rischi mappabili nella ToC):

• “Non so se il budget reggerà per tutti i 24 mesi” ? questa è un’assunzione che la ToC ti costringe a esplicitare e validare
• “Non so se i manager accetteranno davvero il cambiamento” ? altra assunzione da testare con pilot
• “Non so se avremo abbastanza formatori qualificati” ? ancora un’assunzione, la metti nero su bianco e la verifichi

Questi li gestisci bene con la ToC standard. Li elenchi, li testi, li monitori.

Unknown unknowns (cigni neri che nessuno vede arrivare):

• Una pandemia globale che rende impossibile la formazione in presenza
• Una tecnologia che rende obsoleto quello che stai ottimizzando mentre lo ottimizzi
• Un cambio improvviso di leadership che stravolge tutte le priorità aziendali
• Un fornitore che cambia le sue API o le sue metriche di sostenibilità
• Una normativa che cambia le regole del gioco a metà percorso
• Una migrazione infrastrutturale non pianificata che azzera il tuo baseline

Questi non puoi mapparli. Non puoi validarli. Non puoi prevederli.

La domanda che può emergere da questa situazione è quindi “a cosa serva la ToC se la realtà la stravolge comunque?“

Serve eccome, ma non come si pensa. Non protegge dagli unknown unknowns (niente può farlo), ma rende resilienti quando emergono. Dà la struttura per adattarsi intelligentemente invece di andare in panico o insistere stupidamente sul piano originale.

La differenza è tutta lì. Un piano rigido ti dice “fai questo, poi quest’altro, poi quest’altro ancora” e quando arriva l’imprevisto sei bloccato. Una ToC ben costruita ti dice “vuoi arrivare qui, queste sono le condizioni necessarie, ora trova il modo migliore per crearle con le carte che hai in mano oggi.“

Impact vs Activities

Per comprendere meglio il concetto facciamo questo esercizio, dividiamo un foglio in due colonne:

FISSO (non negoziabile):

• Impact finale: “ie. Riduzione del 40% dell’impatto ambientale delle infrastrutture IT“
• Outcomes intermedi: “ie. Team che misura SCI per ogni servizio”, “Architettura che privilegia efficienza energetica”, “Decisioni di deployment basate su carbon intensity“

FLESSIBILE (negoziabile e adattabile):

• Activities: Workshop su Green Software, refactoring di servizi specifici, migrazione a cloud region a bassa carbon intensity
• Tools: quale strumento di misurazione, quale piattaforma cloud, quale framework
• Tempi specifici: quale mese fai cosa
• Ordine delle attività: cosa viene prima e cosa dopo
• Team allocation: chi lavora su quale pezzo

L’Impact è la stella polare. Le Activities sono le vele che aggiusti in base al vento.

Questa distinzione è TUTTO. Una ToC rigida sulle Activities è solo un piano tradizionale travestito con un nome “figo”. Una ToC che distingue chiaramente Impact/Outcomes (fissi) da Activities (flessibili) è una mappa navigabile quando arriva la tempesta.

Esempio concreto:

ToC rigida (possibile fallimento)	ToC flessibile
Piano: “Migreremo 20 servizi su AWS region europea a bassa carbon intensity nei prossimi 6 mesi” -> Arriva un unknown unknown (AWS cambia pricing, o il servizio non è compatibile, o emerge una security issue) -> Risultato: “Beh, il piano dice AWS region europea, quindi aspettiamo che risolvano il problema anche se ci vogliono mesi”	Impact: “Riduzione dell’impatto ambientale dei nostri servizi” Outcome: “Servizi che girano su infrastrutture a bassa carbon intensity” Activities: AWS region europea… oppure Azure in Svezia… oppure on-premise con energia rinnovabile… oppure comunque ci arrivi

L’unknown unknown può farti cambiare le Activities. Non può (non dovrebbe) farti cambiare l’Impact. E se l’Impact stesso diventa irrilevante per l’unknown unknown… beh, quella è un’altra storia e ti serve una ToC nuova, non aggiustare quella vecchia.

Ma nella maggior parte dei casi, l’Impact resta valido. Cambiano le strade per arrivarci.

Strategie pratiche per l’antifragilità

Okay, abbiamo capito che la ToC non previene gli unknown unknowns. Come la si può usare per essere resiliente quando emergono?

1. Checkpoint time-boxed

La ToC non è una tavola di pietra scolpita sul Sinai. È un documento vivo che va revisionato regolarmente.

Ogni 3-6 mesi (e guarda caso, è esattamente il ritmo trimestrale degli OKR), fai una revisione esplicita:

• Quali assunzioni si sono rivelate false?
• Cosa è emerso che non avevamo previsto?
• L’Impact è ancora l’Impact che vogliamo?
• Gli Outcomes intermedi sono ancora quelli giusti?
• Serve cambiare le Activities?

Se si continua per 18 mesi dritto senza mai guardare la mappa, quando si scopre che si è completamente fuori strada si è troppo lontano per recuperare. I checkpoint frequenti permettono di correggere la rotta quando sei ancora abbastanza vicino (nb. gli agilisti lo dicono tipo da 20 anni).

Nel caso del team sulla sostenibilità digitale, abbiamo stabilito checkpoint trimestrali espliciti dove riunire tutti i stakeholder e chiedersi: “È ancora vero quello che pensavamo tre mesi fa? Cosa è cambiato? Dobbiamo aggiustare qualcosa?“

Questo ha permesso loro di adattare continuamente invece di arrivare al mese 18 e scoprire che avevano seguito fedelmente una mappa di un territorio che non esisteva più.

2. Health metrics

Oltre alle metriche standard della tua ToC (Input ? Output ? Outcome ? Impact), aggiungi delle health metrics (chiamate in alcuni testi anche Sentinel Metrics), come i canarini nelle miniere di carbone, ti avvisano quando qualcosa di anomalo sta emergendo.

Esempio progetto sostenibilità:

• Metriche ToC: “SCI medio per servizio”, “% di deployment su low-carbon infrastructure”, “riduzione emissioni totali”
• Health metrics: “varianza nei costi cloud mese su mese”, “frequency of infrastructure changes”, “time to deploy aumentato inspiegabilmente”, “developer satisfaction score”

Se una health metric si muove in modo strano, potrebbe essere un unknown unknown che sta emergendo. Non è ancora nella tua ToC, ma sta bussando alla porta.

Nel workshop è emerso dal gruppo che se si vede che i costi cloud iniziano a oscillare molto più del normale, potrebbe essere un segnale che il fornitore sta cambiando qualcosa. Allo stesso tempo se il time to deploy aumenta improvvisamente, forse ci sono friction che non erano state previste.

3. Optionality nei branch point

Invece di costruire un pathway lineare (“faccio A, poi B, poi C”), è opportuno definire dei fork esplicite nella ToC con validazioni che dicono quale strada prendere.

Schema tipo:

Mese 6: Team acquisisce competenze Green Software
  ?
Checkpoint: "L'architettura attuale permette ottimizzazioni significative?"
  ?? SE SÌ ? Refactoring incrementale dei servizi esistenti
  ?? SE NO ? Redesign architetturale prima di ottimizzare

Questo non previene l’unknown unknown, ma dà gradi di libertà quando emerge. Avere scenari alternativi, permette di analizzare il tema da diverse angolazione e di non doverli inventare sotto pressione.

Durante il workshop abbiamo identificato 3-4 fork critici nella loro ToC. “Se a questo checkpoint scopriamo X, facciamo Y. Se scopriamo Z, facciamo W.” Non va intesa come previsione, ma preparazione.

4. Diversity nel team di design della ToC

Più prospettive diverse, meno blind spots e quindi più possibilità di catturare i segnali deboli degli unknown unknowns prima che diventino problemi grossi.

Un team omogeneo (tutti developer, tutti dalla stessa funzione, tutti con lo stesso background) vede gli stessi unknowns. Un team eterogeneo (ruoli diversi, seniority diverse, esperienze diverse) vede più aspetti (Eventstorming, nella sua modalità Reverse Roadmapping, offre un formato molto utile per fare brainstorming).

Pratica concreta: quando si disegna una ToC su sostenibilità digitale (o qualsiasi altro tema), non bisogna coinvolgere solo i technical lead.

Invece è utile coinvolgere:

• Chi lavora operativamente sull’infrastruttura e vede i problemi veri
• Chi gestisce i costi e vede le variazioni economiche
• Chi fa procurement e sa cosa dicono i fornitori
• Qualcuno che ha visto progetti simili fallire altrove
• Un outsider (che reputato intelligente) che fa domande naive

Nel workshop in questione, chi ha fatto la domanda sugli unknown unknowns era junior. Ma proprio perché non aveva “investito” nella ToC iniziale, ha visto quello si stava dando per scontato.

5. Abduzione come antenna continua

L’abduzione non serve solo all’inizio per formulare l’ipotesi iniziale. Serve continuamente per catturare i segnali deboli.

Quando si osserva qualcosa di strano che non quadra con la tua ToC:

• Non bisogna forzarlo nella mappa esistente (“Beh, è un outlier, ignoriamo“)
• Non va ignorato (“Non è previsto, quindi non esiste“)
• Bisogna fermarsi e chiedere: “E se fosse il segnale di qualcosa che non avevo previsto?“

Gli unknown unknowns diventano known unknowns nel momento in cui si osserva il primo segnale debole. L’abduzione è l’antenna che permette di captarlo.

Esempio pratico dal workshop: uno degli engineer aveva notato che un servizio particolare consumava molto più del previsto dopo un’ottimizzazione. La prima reazione del team era “beh, è un caso particolare, andiamo avanti.” La reazione abduttiva: “E se fosse il segnale che il nostro approccio di ottimizzazione ha un effetto collaterale che non avevamo previsto?“

Hanno investigato. E hanno scoperto che l’ottimizzazione spostava il carico su un altro componente che loro non stavano monitorando. Unknown unknown diventato known unknown grazie all’abduzione su un segnale debole.

Un esempio pratico

Esempio pratico che tutti capiamo perché l’abbiamo vissuto.

Scenario: Gennaio 2020, costruisci una ToC formativa per “sviluppare competenze di teamwork attraverso workshop in presenza nei prossimi 18 mesi”. Backwards mapping fatto bene, assunzioni esplicitate, metriche multi-livello, tutto perfetto.

Unknown unknown: Marzo 2020, pandemia globale. Gli spazi fisici chiudono. Gli incontri in presenza diventano impossibili.

Come una ToC rigida sulle Activities fallisce: “Il nostro piano dice ’10 workshop in presenza da 2 giorni ciascuno’. Non possiamo farli. Blocchiamo tutto. Aspettiamo che finisca. O peggio: li facciamo comunque in presenza e ci ammaliamo tutti.”

Come una ToC flessibile sulle Activities naviga:

1. L’Impact resta valido: “Team che collaborano efficacemente” è ancora il goal, pandemia o no
2. Gli Outcomes restano validi: “Developer che si aiutano reciprocamente”, “Manager che supportano la collaborazione”
3. Le Activities cambiano completamente:
   • Da workshop in presenza ? mentoring remoto 1-1
   • Da esercizi di gruppo fisici ? pair programming online
   • Da retrospettive in stanza ? retrospettive async su Miro
4. Le assunzioni esplicitate ti fanno capire subito cosa è saltato: “Disponibilità di spazi fisici per 50 persone” era un’assunzione. Ora è falsa. Ok, cambio strada.
5. I checkpoint trimestrali ti fanno pivotare a Marzo 2020, non a Dicembre 2020: Se il tuo piano rigido dice “prima revisione tra 12 mesi”, arrivi a Gennaio 2021 e scopri di aver perso un anno. Se hai checkpoint ogni 3 mesi, a Giugno 2020 hai già cambiato tutto e stai andando avanti.
6. Le metriche di Outcome (non Output) ti dicono se stai ancora andando verso l’Impact: Non misuri “numero di workshop fatti” (Output, che è zero), misuri “frequenza di code review costruttive” (Outcome, che può essere alta anche in remoto). Se l’Outcome si muove, stai ancora andando verso l’Impact.

Se fosse stato solo un piano tradizionale “10 workshop in presenza, punto”, il progetto sarebbe rimasto bloccato per mesi. Con una ToC che distingue Impact da Activities, pivot e vai avanti.

E non è teoria: ho visto aziende fare esattamente questo durante COVID. Quelle con piani rigidi si sono fermate. Quelle con ToC flessibili hanno cambiato tutto e sono andate avanti.

Futures Cone e antifragilità

C’è un collegamento profondo con il Futures Cone che avevo già esplorato in un articolo precedente.

Il cono del futuro si allarga man mano che guardi lontano nel tempo. Perché? Perché ci sono sempre più unknowns. A 3 mesi vedi abbastanza chiaramente, a 24 mesi il cono è larghissimo perché le possibilità sono infinite.

La ToC definisce il tuo futuro preferibile, l’apice del cono, quello che vuoi costruire. Ma navighi dentro un cono che si allarga. Gli unknown unknowns non sono un bug del tuo metodo, sono nella natura del cono. Fanno parte del territorio.

E qui entra Nassim Taleb con il concetto di antifragilità: non puoi prevedere i cigni neri (unknown unknowns per definizione), ma puoi costruire sistemi che beneficiano dal disordine invece di esserne distrutti.

Una ToC antifragile ha queste caratteristiche:

• Distingue chiaramente cosa cambiare e cosa no quando arriva il cigno nero (Activities flessibili, Impact fisso)
• Ha optionality nei branch point, quindi hai alternative già pensate
• Ha checkpoint frequenti per adattarsi velocemente invece di scoprire il disastro troppo tardi
• Ha metriche multi-livello che ti dicono se sei ancora on track anche se il path è completamente cambiato
• Ha un team diversificato che vede più segnali deboli

Non è che la ToC ti protegge dagli unknown unknowns. È che la ToC ben costruita ti rende antifragile: quando l’unknown unknown emerge, hai la struttura per adattarti senza andare in panico.

Nel caso del team sulla sostenibilità digitale, l’antifragilità era avere chiari gli Outcomes (non solo le Activities), avere checkpoint trimestrali espliciti, avere sentinel metrics (varianza costi, developer satisfaction), e soprattutto avere la mentalità di “l‘Impact è fisso, tutto il resto è negoziabile.“

La mappa non è il territorio, ma senza mappa sei perso

Torniamo al workshop. Quel developer junior che ha fatto la domanda scomoda sugli unknown unknowns.

Alla fine delle due giornate, mi ha detto: “All’inizio pensavo che la ToC fosse un esercizio inutile. Tipo, costruiamo ‘sta mappa sapendo che tanto cambia tutto. Ma ho capito che senza mappa sono proprio perso quando cambia. Almeno con la ToC so dove voglio andare, anche se devo cambiare strada.“

Esattamente.

Le aziende che costruiscono ToC rigide sulle Activities falliscono quando arriva l’imprevisto. Si bloccano. Insistono sul piano anche quando è evidente che non funziona più. “Ma abbiamo già allocato il budget!” “Ma il contratto dice così!” “Ma il board ha approvato questo piano!”

Le aziende che costruiscono ToC flessibili sulle Activities ma ferme sull’Impact… quelle navigano i cigni neri. Quando arriva COVID, non si fermano, cambiano strada. Quando cambia una tecnologia, non insistono a ottimizzare quella vecchia, aggiornano le Activities mantenendo l’Outcome. Quando il fornitore cloud cambia le sue metriche, non aspettano mesi per “tornare al piano”, adattano il loro approach di misurazione.

La differenza tra le due non è fortuna. È metodo.

La ToC non è una profezia che predice il futuro. È una bussola che ti dice dove stai andando e ti permette di correggere la rotta quando il vento cambia.

E quando arriva la tempesta, e arriva sempre, fidatevi, preferisco avere una bussola che funziona piuttosto che una mappa perfetta di un territorio che non esiste più.

Gli unknown unknowns non si prevengono. Si navigano. E la Theory of Change, se costruita bene, è lo strumento che ti permette di farlo senza andare a sbattere o perderti completamente.