Non c’è stato un momento preciso. Nessuna epifania drammatica durante una consulenza particolarmente disastrosa. Piuttosto, una sensazione crescente, consulenza dopo consulenza, workshop dopo workshop: quando arrivava il momento di parlare di metriche e obiettivi per il Sustainable IT, qualcosa si inceppava.
Facevo domande che mi sembravano ragionevoli. Tipo: “Supponiamo di aver raggiunto il nostro obiettivo: come stabiliamo che è stato un successo?” Oppure: “Quali sono le metriche su cui dobbiamo lavorare per raggiungere questi obiettivi?” E ancora: “Che causalità c’è tra queste azioni che ci garantisce una riduzione degli impatti ambientali?“
E ottenevo… silenzio. O peggio: risposte vaghe, metriche di vanità del tipo “guardiamo quanti server virtualizziamo!“, numeri senza contesto. Non era malafede, né incompetenza. Era qualcosa di più sottile: mancava il linguaggio condiviso per connettere intenzioni e risultati.
Inizialmente pensavo fosse un problema di cultura aziendale. Poi di maturità sul tema sostenibilità. Poi, mentre studiavo per certificarmi come facilitatore per EN-Roads, mi sono imbattuto nella Theory of Change. E lì ho capito: non era un problema di cosa misurare, ma di come costruire la logica che porta dalla visione all’azione misurabile.
Theory of Change 101
La Theory of Change (ToC) è uno strumento di pianificazione strategica nato nel nonprofit sector negli anni ’90, ma tremendamente utile anche nel contesto aziendale. In sintesi: è la mappa esplicita che spiega come le tue azioni porteranno ai risultati desiderati.
La cosa interessante della ToC è che funziona al contrario di come pensiamo normalmente. Invece di partire da “cosa facciamo oggi” e sperare di arrivare da qualche parte, la ToC usa il backwards mapping: parti dal goal finale che vuoi raggiungere e poi, passo dopo passo, ti chiedi “cosa deve accadere immediatamente prima perché questo si realizzi?” È come risolvere un labirinto partendo dall’uscita invece che dall’entrata.
Il processo si articola in sei stage che ti costringono a pensare in modo strutturato.
Primo: identificare il long-term goal, l’impatto finale che vuoi generare. Secondo: fare backwards mapping connettendo tutte le precondizioni necessarie per raggiungere quel goal, spiegando perché queste precondizioni sono necessarie e sufficienti. Terzo: identificare le assunzioni base sul contesto in cui operi. Quarto: definire gli interventi specifici che la tua iniziativa metterà in campo. Quinto: sviluppare indicatori per misurare i tuoi outcomes e valutare le performance. Sesto: scrivere la narrativa che spiega la logica dell’intera iniziativa.
Il cuore del processo è quello che chiamano “pathway of change“: una sequenza connessa di outcomes che rappresenta graficamente il processo di cambiamento come lo intendono i pianificatori. E qui viene la parte cruciale: durante la creazione di questo pathway, devi articolare tutte le tue assunzioni sul processo di cambiamento, così puoi esaminarle e testarle per verificare se qualche assunzione chiave è difficile da supportare o addirittura falsa.
Ci sono tipicamente tre tipi importanti di assunzioni da considerare. Le asserzioni sui collegamenti tra outcomes a lungo termine, intermedi e iniziali sulla mappa. La sostanziazione della completezza, cioè la pretesa che tu abbia identificato tutte le precondizioni importanti per il successo. Infine, le giustificazioni dei link tra attività programmatiche e gli outcomes che ci si aspetta producano. E spesso c’è un quarto tipo: i fattori contestuali o ambientali che supporteranno o ostacoleranno il progresso verso la realizzazione degli outcomes.
Un esempio di ToC fatta male
Facciamo un esempio concreto che mi è capitato di vedere più volte nelle consulenze. Scenario tipico: un’azienda vuole “diventare carbon neutral”, decide di comprare crediti di carbonio, e misura il successo in “€ spesi in carbon credits”. Fine della storia.
Che cosa manca? Tutto il resto. Non c’è connessione causale tra l’acquisto di crediti e la riduzione effettiva delle emissioni. Non ci sono outcomes intermedi misurabili. Non ci sono assunzioni esplicite da validare. È un’azione disconnessa da una teoria del cambiamento. È aria fritta, diciamocelo.
Ora prendi lo stesso scenario con una ToC articolata attraverso backwards mapping.
Parto dal long-term goal: “Riduzione del 50% delle emissioni Scope 1-2-3 entro il 2030”.
Poi mi chiedo: cosa deve accadere immediatamente prima perché questo si realizzi?
Devo avere infrastruttura IT con intensità carbonica ridotta del 30% entro 18 mesi. E prima ancora?
Software re-architettato con metriche SCI implementate e misurate. E prima di quello?
Audit del codice esistente completato, team formato su Green Software, refactoring prioritizzato ed eseguito. E per fare tutto questo?
Budget per formazione, tempo dev allocato, tooling itegrare la misurazione SCI nel CI/CD configurato.
A questo punto emergono le assunzioni critiche da validare. Il team ha competenze base per apprendere Green Software? Esistono alternative tecnologiche a lower carbon intensity per i nostri use case? Il business è disposto a investire in refactoring che non porta feature visibili? Se una di queste assunzioni è falsa, tutta la tua ToC crolla, meglio scoprirlo prima di investire risorse.
Gli indicatori a questo punto diventano chiari e multi-livello. Non solo “emissioni totali ridotte” alla fine, ma SCI per servizio, percentuale di codice rifattorizzato, ore di training completate (e comprensione dei Green Pattern da parte dei dev), carbon savings misurati in ogni sprint. Vedi la differenza? Ora hai una mappa navigabile. Puoi contestare le assunzioni, verificare i collegamenti causali, misurare a ogni livello, e soprattutto: sapere durante il percorso se stai andando nella direzione giusta.
La connessione con Osterwalder e The Invincible Company
Qui c’è un parallelo interessante con il lavoro di Alex Osterwalder in The Invincible Company.
Osterwalder parla di come le aziende vincenti non si limitano a trovare “la prossima grande cosa“, ma costruiscono motori di innovazione continua che permettono di reinventarsi costantamente. Il suo concetto chiave è che i business models oggi sono come lo yogurt: hanno una data di scadenza ravvicinata. Non puoi più fare affidamento su un singolo modello che durerà decenni.
La Theory of Change è esattamente lo strumento che ti serve per costruire questo motore. Osterwalder distingue tra exploration (cercare nuove opportunità, crescita, mentalità imprenditoriale) ed exploitation (ottimizzare l’esistente, efficienza, cost-cutting). Le aziende invincibili fanno entrambe le cose contemporaneamente—sono “ambidestre”. Ho già approfondito questa distinzione in un articolo precedente su Invincible OKR, dove spiego come i due binari (Esplorazione e Miglioramento) richiedano metriche e OKR completamente diversi.
Ma per esplorare efficacemente, hai bisogno di una ToC chiara: quale impatto voglio generare con questo nuovo business model? Quali outcomes intermedi mi dicono se sto andando nella direzione giusta? Quali assunzioni sto facendo sul mercato, sui clienti, sulla tecnologia?
E qui si innesta un’altra connessione fondamentale. Quando costruisci la tua Theory of Change, stai essenzialmente definendo il tuo futuro desiderabile usando il concetto dei Futures Cone. Come ho spiegato nell’articolo su Futures Cone e OKR, il futuro non è un punto fisso ma un cono di possibilità che si allarga nel tempo. Il futuro preferibile, quello che vogliamo costruire, è esattamente quello che stiamo mappando quando articoliamo la nostra ToC attraverso backwards mapping.
Il long-term goal della ToC è l’apice del cono desiderabile. Gli outcomes intermedi sono le sezioni del cono che raggiungi in momenti specifici. Le assunzioni che validi sono il modo in cui restringi il cono dell’incertezza, passando dal “possibile” al “plausibile” al “probabile”. E le iniziative che implementi sono quei tronchi di cono che ti portano progressivamente verso il futuro che hai scelto di costruire.
Osterwalder introduce il Business Model Portfolio Map per gestire il portfolio di idee e miglioramenti. Ma senza una ToC per ogni iniziativa nel portfolio, stai solo accumulando speranze. La ToC ti dice perché quell’idea dovrebbe funzionare, quali sono le precondizioni necessarie, e come misurare se stai de-risking le assunzioni critiche. Esattamente quello che Osterwalder predica: test, measure, de-risk desirability, viability, feasibility.
E qui arriviamo al cuore del problema che vedevo nelle mie consulenze sul sustainable IT: le aziende volevano “innovare” sulla sostenibilità (exploration), ma senza una ToC articolata stavano solo facendo quello che Osterwalder chiama “innovation theater“, uno spettacolo che sembra innovazione ma non riduce il rischio né crea valore reale.
Questo è quello che mancava nelle mie consulenze. E questo è quello che mi ha portato a scrivere tre libri invece di uno.
Il percorso: tre libri, un’unica teoria del cambiamento
Quando ho iniziato a lavorare sul sustainable IT, partivo sempre dagli OKR. È la metodologia che uso da anni, quella su cui ho costruito corsi e interventi. Ma mi sono reso conto che non bastava.
Gli OKR sono potenti per collegare Objectives (qualitativi, aspirazionali) a Key Results (quantitativi, misurabili). Sono perfetti per creare alignment verticale e orizzontale in un’organizzazione. Ma per funzionare davvero, hanno bisogno di due fondamenta: una comprensione profonda di come si misurano le cose (non tutte le metriche sono uguali), e una logica causale esplicita che colleghi azioni a risultati (la Theory of Change, appunto).
E così, sfruttando le trascrizioni dei miei corsi e workshop, sì, perché questi temi li ho rodati sul campo prima di metterli nero su bianco anche qui sul blog, è nato un percorso in tre atti. In termini di Osterwalder, ho esplorato il dominio del sustainable IT sviluppando un framework che altri possano poi sfruttare (exploitation delle mie esperienze di exploration).
Atto 1: KPI, the right way
Il primo problema da risolvere era: “Come faccio a sapere se sto misurando la cosa giusta?” Questo libro nasce dalle domande ricorrenti nei miei workshop. “Ma questa metrica è buona? Come faccio a evitare le vanity metrics? Cosa rende una metrica actionable?” Domande legittime che meritavano risposte strutturate.
Ho scritto KPI, the right way per dare le fondamenta della misurazione. Dentro ci trovi i bias cognitivi che distorcono la scelta delle metriche—confirmation bias, availability bias, la famigerata Goodhart’s Law (“quando una misura diventa un target, smette di essere una buona misura”). Poi c’è la distinzione cruciale tra vanity metrics e metriche azionabili: la differenza tra “sembra bello nei report” e “mi dice cosa fare domani mattina per migliorare”. E infine framework pratici per validare i tuoi KPI, perché no, SMART non basta. È troppo generico, serve qualcosa di più strutturato.
Senza questo pezzo, gli OKR diventano pericolosi. Scegli Key Results sbagliati e ottimizzi per le cose sbagliate. Nel sustainable IT, dove le metriche sono ancora immature—SCI, PUE, carbon intensity e compagnia—questo rischio è altissimo. Non puoi permetterti di misurare la cosa sbagliata quando l’impatto ambientale è in gioco. In termini di ToC: se i tuoi indicatori sono mal costruiti, non saprai mai se stai davvero progredendo verso gli outcomes desiderati.
Atto 2: OKR, the right way
Una volta che sai misurare, serve un sistema per orchestrare quelle metriche in una strategia coerente. Gli OKR sono perfetti per questo, ma solo se li usi bene. E qui casca l’asino, perché ho visto fin troppe implementazioni di OKR che erano poco più di todo-list glorificate.
OKR, the right way introduce i principi di causalità: perché questo Key Result dovrebbe portare a quell’Objective? Non è una domanda filosofica, è il cuore della questione. È esattamente quello che la ToC ti costringe a fare quando mappi le connessioni tra outcomes. Poi c’è l’effetto-reazione: come validare che le tue azioni stiano davvero muovendo l’ago, e non solo creando l’illusione del progresso?
Dentro ci sono anche i coni del futuro per fare scenario planning e creare OKR resilienti in contesti incerti, e diciamocelo, il sustainable IT è un contesto incerto. E c’è Hoshin Kanri per l’allineamento strategico verticale e orizzontale, perché gli OKR che vivono in silos separati non servono a nessuno.
Questo è il cuore della Theory of Change applicata: gli OKR sono la struttura che connette vision (Objective) a execution (Key Results + Initiatives). Sono il “pathway of change” fatto strumento operativo. Ma senza una logica causale esplicita, senza chiederti “perché questo KR dovrebbe portare a quell’Obiettivo?”, rimangono solo wishful thinking ben formattato su un foglio Excel.
Atto 3: Sustainable IT, the practical way
Okay, so misurare e so pianificare. E adesso? Come lo applico al sustainable IT? Qui chiudo il cerchio con Sustainable IT, the practical way, che è l’applicazione pratica di KPI e OKR al dominio specifico della sostenibilità digitale.
Dentro trovi metriche specifiche come SCI, PUE, emissioni Scope 3 delle infrastrutture, user-centric metrics. Ci sono esempi di OKR concreti per capire come strutturare obiettivi di sostenibilità che siano ambiziosi ma realistici, perché “salvare il pianeta” non è un Key Result. C’è un approccio pragmatico totale: niente green-washing, solo azioni misurabili con impatto reale. E soprattutto c’è integrazione: come fare sostenibilità senza creare l’ennesimo silo separato dal resto del business.
Questo libro è anche una risposta diretta al problema che Osterwalder identifica: troppo “innovation theater” e troppo poco testing rigoroso delle assunzioni. Ogni pratica di sustainable IT nel libro è (sarà perché al momento ho scritto solo i primi capitoli) accompagnata da: quali metriche usare per validarla, quali assunzioni stai facendo, come de-riscare attraverso small experiments. È exploration disciplinata, non speranza vestita da strategia.
Non è un caso che sia arrivato per ultimo. Senza la base metodologica dei primi due, questo libro sarebbe stato solo un’altra lista di best practices disarticolate che trovi già in mille blog post. Invece è il pezzo finale di un puzzle più grande: la mia personale Theory of Change per portare le organizzazioni da “vogliamo fare sostenibilità” a “stiamo riducendo il nostro impatto in modo misurabile e continuo”.
La mia personale Theory of Change
Guardando indietro, cosa che di solito faccio troppo poco, ma ogni tanto è utile, mi sono reso conto che i tre libri sono esattamente la mia Theory of Change per portare le organizzazioni da “vogliamo fare sostenibilità” a “stiamo riducendo il nostro impatto in modo misurabile“.
Applicando il backwards mapping che ho descritto prima, parto dal long-term goal: organizzazioni che integrano sustainable IT in modo strutturato, misurabile e non performativo. Basta con i report di sostenibilità che sono puro marketing, voglio vedere azioni concrete.
Cosa deve accadere immediatamente prima perché questo si realizzi? Devo avere manager e team con le competenze giuste per definire strategie sostenibili azionate da metriche corrette. Non basta la buona volontà, serve il metodo. E prima ancora? Devo creare strumenti didattici accessibili che coprano l’intero percorso metodologico: misurazione, poi pianificazione, poi applicazione dominio-specifica.
E come produco questi strumenti in modo che siano davvero utili e non solo teoria astratta? Attraverso corsi, workshop e consulenze dove testo e affino questi contenuti. Le trascrizioni di quelle sessioni diventano il materiale grezzo per i libri—quindi no, non sono nati dalla pura teoria, ma da ore di facilitazione e discussioni con chi questi problemi li vive ogni giorno.
E cosa serve per fare tutto questo? 5 anni di esperienza sul campo, decine di clienti diversi, centinaia di ore di facilitazione. E pazienza. Tanta pazienza. Questo è il mio pathway of change personale, e ogni libro è un outcome intermedio verso l’impact finale.
Le assunzioni critiche che ho fatto lungo il percorso? Principalmente tre. Primo: le organizzazioni falliscono sul sustainable IT per mancanza di metodo, non di intenzioni. La maggior parte delle persone vuole fare la cosa giusta, semplicemente non sa come. Secondo: metriche e OKR sono linguaggi comprensibili trasversalmente, dal developer al C-level—non servono PhD in sustainability science per capirli. Terzo: un approccio pragmatico batte sempre quello ideologico. Le crociate verdi non funzionano, i piccoli passi misurabili sì.
E come valido queste assunzioni? Con indicatori di successo concreti che vedo nelle consulenze. Clienti che tornano e mi dicono “abbiamo implementato gli OKR sostenibili e funzionano, guarda i dati”. Richieste specifiche su come misurare X o strutturare Y, segnale che stanno adottando concretamente gli approcci, non solo leggendo per cultura personale. E soprattutto: meno “sguardi a triglia” quando parlo di metriche azionabili. Quello è il vero metro del successo.
L’ambidestria organizzativa applicata alla consulenza
Se penso al mio lavoro in termini del framework di Osterwalder, ho costruito un sistema ambidestro. Da un lato c’è exploitation: erogo corsi e consulenze su OKR e sustainable IT, ottimizzando continuamente il format basandomi sui feedback. Dall’altro c’è exploration: ogni cliente porta problemi nuovi che mi costringono a testare le assunzioni, raffinare gli approcci, esplorare nuovi collegamenti.
I tre libri sono il risultato di questo processo di esplorazione continua, cristallizzato in un format che altri possono sfruttare. Non sono il punto di arrivo, sono snapshot di un percorso in evoluzione. Come dice Osterwalder, i business models hanno una data di scadenza. Lo stesso vale per i framework metodologici: vanno continuamente testati, validati, e aggiornati basandosi su nuove evidenze.
La differenza tra fare “innovation theater” e fare vera innovazione sta proprio qui: nella capacità di articolare la tua Theory of Change, testare le assunzioni rigorosamente, e misurare se stai davvero creando l’impatto desiderato o solo l’illusione del progresso.
Costruisci la tua mappa prima di partire
Se stai lavorando su sustainable IT, o qualsiasi iniziativa di cambiamento complesso, in realtà, ti consiglio di partire dalla Theory of Change prima di buttarti su tools e framework. So che è meno sexy che installare l’ultimo tool di carbon monitoring, ma fidati: ti farà risparmiare un sacco di tempo e frustrazioni.
Il processo di backwards mapping è controintuitivo ma potente. Inizia identificando il long-term goal specifico che vuoi raggiungere. Non “fare sostenibilità” che non significa niente, ma “ridurre le emissioni del 30% entro il 2027 misurando per i nostri 10 servizi più usati“. Specifico, misurabile, temporizzato.
Poi fai il passo indietro e chiediti: cosa deve accadere immediatamente prima perché questo goal si realizzi? Magari devi avere “team formati su Green Software e processi di code review che includono criteri di efficienza energetica”. Okay, e prima ancora? “Documentazione interna su best practices Green Software e tooling per misurazione SCI integrato nella CI/CD pipeline”. Continua così fino ad arrivare alle azioni che puoi fare oggi.
Mentre costruisci questo pathway, identifica tutte le assunzioni che stai facendo. Il team sa già programmare in modo efficiente? Hai budget per cambiare infrastruttura? I fornitori hanno alternative low-carbon? Scrivi queste assunzioni nero su bianco e poi vai a validarle, una per una. Le assunzioni non verificate sono la tomba di ogni progetto—Osterwalder lo ripete in continuazione quando parla di de-risking.
Non dimenticare i fattori contestuali: cosa nel tuo ambiente organizzativo supporterà questo percorso? Cosa lo ostacolerà? C’è un executive sponsor che ci crede davvero? Il budget è stabile o a rischio al primo trimestre negativo? Questi fattori influenzano pesantemente la realizzabilità della tua ToC.
Infine, sviluppa indicatori per ogni livello del tuo pathway of change. Non solo i KPI finali tipo “emissioni totali ridotte”, ma metriche intermedie che ti dicono durante il percorso se sei on track o se devi correggere la rotta. Percentuale di team formati, numero di servizi migrati, SCI medio in miglioramento—indicatori che ti fanno capire se stai de-riskando le assunzioni critiche o solo raccontandoti storie.
Solo dopo aver fatto questo lavoro—e lo so che sembra laborioso, ma vale ogni minuto investito—gli strumenti come OKR, KPI, SCI e tutti i framework che trovi in giro diventano davvero utili. Perché sai perché li stai usando e cosa ti devono dire. Altrimenti sono solo l’ennesimo buzzword da mettere nelle slide per far contento il board.
Quello che ho imparato (e che forse ti può servire)
Scrivere tre libri invece di uno non è stata una scelta di marketing. Posso dirlo tranquillamente perché, diciamocelo, se volevo fare soldi con i libri avrei scelto un settore diverso. È stata una necessità metodologica, ogni libro risponde a una precondizione necessaria per quello successivo.
Non puoi parlare di OKR sostenibili se prima non hai spiegato come si valuta una metrica. Non puoi applicare KPI al sustainable IT se prima non hai costruito la logica causale che li connette agli obiettivi strategici. Ogni pezzo serve al successivo, e saltarne uno significa costruire una casa senza fondamenta.
E se vuoi approfondire come ho strutturato questo percorso in pratica, beh… ho scritto tre libri apposta. Non per venderteli, anche se ovviamente non mi dispiace se li compri, ma perché sono il modo più efficace che ho trovato per trasmettere anni di esperienza sul campo in formato utilizzabile. Sono il mio contribution a quel portfolio di innovation di cui parla Osterwalder: piccoli esperimenti che se funzionano diventano prodotti, se non funzionano insegnano qualcosa.
Quali sono le assunzioni implicite nel tuo progetto di sostenibilità? Hai già provato a mapparle esplicitamente usando il backwards mapping?
Se la risposta è no, questo weekend potrebbe essere un buon momento per iniziare. Ti garantisco che scoprirai cose interessanti, e probabilmente qualche assunzione che pensavi solida si rivelerà… meno solida di quanto speravi. Meglio scoprirlo ora che dopo aver investito sei mesi e mezzo budget annuale.