> ## Content Index
> Fetch the complete content index at: https://myagilestories.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Un board che reagisce non è un board che governa
- URL: https://myagilestories.com/un-board-che-reagisce-non-e-un-board-che-governa/
- Published: 2026-07-31T05:30:00.000Z
- Updated: 2026-09-02T19:49:24.000Z
- Description: Un board reattivo lavora molto: risponde alle crisi, rincorre i casi, interviene quando il problema è già evidente. Il limite non è la fatica, è da dove arriva la direzione.
- Author: Gaetano Frascolla
- Tags: Strumenti

> «Governare non significa prevedere tutto. Significa aver deciso, prima, abbastanza cose da non essere costretti a decidere tutto sotto pressione.»

Un management board reattivo, di solito, lavora molto. Non è un board fermo. Risponde alle crisi, rincorre i casi, interviene quando qualcosa diventa evidente. Visto da fuori sembra perfino efficiente: c'è sempre movimento, c'è sempre qualcuno che si occupa del problema del giorno. Il limite non è la quantità di lavoro. È **da dove arriva la direzione**.

Quando la direzione nasce dal segnale esterno, e non da un accordo interno, il board non sta governando. Sta *amministrando emergenze*. La differenza si vede nei tempi: le conversazioni importanti arrivano dopo. Dopo un blocco, dopo che il peso su una persona è diventato insostenibile, dopo una crisi in un team, dopo un conflitto ormai deflagrato. Il board vede molto, questo va detto. Ma fatica a trasformare ciò che vede in regole del gioco, aspettative e decisioni tracciabili.

## Vedere non è decidere

C'è una qualità quasi seducente nel board reattivo: la diagnosi. In una stanza di persone esperte le analisi sono spesso brillanti. Ognuno legge bene il sistema, nota i pattern, capisce cosa non va. Il problema è che la *diagnosi individuale* non diventa quasi mai *responsabilità collegiale*. È il passaggio su cui Esther Derby e Diana Larsen costruiscono *Agile Retrospectives*: una retrospettiva che si ferma a cosa si è visto, senza decidere cosa si fa, non ha ancora finito. Ci si ritrova a dire, uno dopo l'altro, cosa si pensa del sistema. Raramente ci si ferma a decidere insieme cosa si fa quando quel pattern ricompare.

E i pattern ricompaiono. È la loro natura. Ma se ogni volta li affrontiamo da capo, come se fossero notizie, restiamo dentro un ciclo: crisi, diagnosi, intervento, sollievo, e di nuovo crisi. La reattività ha questo di infido, che dà soddisfazione. Ogni intervento riuscito conferma che il board serve. Peccato che confermi anche il fatto che senza la crisi non ci si sarebbe mossi.

## Il contrario non è la rigidità

Attenzione, però, a non correre verso l'estremo opposto. Il contrario di un board reattivo non è un board rigido, che decide tutto in anticipo e poi applica regole a prescindere. Sarebbe un altro modo di non governare, solo più cieco.

Il contrario di un board reattivo è un board capace di nominare prima i criteri. Di dire, mentre le acque sono calme, cosa faremo quando vedremo tornare quel segnale. Chi prende quale decisione. Quali conseguenze dichiariamo apertamente, così che non arrivino a sorpresa. Non è pianificare ogni mossa. È spostare una parte della conversazione dal momento della crisi al momento in cui si può ancora ragionare a mente fredda.

Per me la formula è semplice da dire e scomoda da praticare: meno "cosa penso io di questo caso", più "cosa decidiamo di fare insieme quando vediamo questo pattern". La prima frase mette al centro l'acume di chi parla. La seconda mette al centro un impegno che regge anche quando chi parla non c'è.

## Dalla diagnosi individuale alla responsabilità collegiale

Il passaggio è dallo sguardo alla mano. Uno sguardo acuto sul sistema è prezioso, ma resta privato finché non si trasforma in qualcosa che vincola il gruppo. Un board matura quando accetta che le sue letture, per contare, devono diventare accordi. E un accordo, per essere tale, deve dire chi fa cosa, con quali criteri, e cosa succede se non accade. Nel lavoro dei team un patto di questo tipo ha un nome, *working agreement*, e vale anche quando a prenderlo è un board.

Questo non toglie spazio all'intuizione. La libera. Perché un board che ha già nominato i propri criteri può permettersi di dedicare l'intelligenza ai casi davvero nuovi, invece di consumarla ogni volta a rincorrere l'ennesima variante di un problema noto. Alla fine, governare non significa prevedere tutto. Significa **aver deciso, prima**, abbastanza cose da non essere costretti a decidere tutto sotto pressione.

Vale la pena dire da dove nasce, di solito, la reattività: non da pigrizia, ma da un eccesso di fiducia nelle persone. Un board fatto di individui capaci si convince che, quando arriverà il problema, sapranno gestirlo. E in effetti spesso è vero. Solo che questa fiducia ha un costo nascosto: rende superfluo l'accordo. Perché prendersi la briga di nominare i criteri prima, se tanto poi ce la caviamo sempre? Il risultato è che il board lavora sugli eventi invece che sulla struttura che li produce, la distinzione al centro di *Pensare per sistemi* di Donella Meadows: diventa bravissimo a spegnere incendi e lentissimo a costruire *l'impianto antincendio*. E ogni incendio spento rimanda ancora la conversazione noiosa su come evitare il prossimo.

La prova del nove è onesta e un po' spietata. Guarda le ultime decisioni importanti prese dal tuo board. Quante sono nate da un accordo preso a mente fredda, e quante da una crisi che ha costretto la conversazione? Se la seconda colonna è molto più piena della prima, il board sta lavorando. Ma **non sta ancora governando**.

Non serve ribaltare tutto in una volta. Basta cominciare da un pattern solo, il più ricorrente, quello che torna ogni due mesi con una faccia diversa. Fermarsi, mentre le acque sono calme, e decidere insieme cosa faremo la prossima volta che lo vediamo arrivare. Chi lo intercetta, chi decide, cosa comunichiamo. Un pattern nominato in meno è una crisi in meno da rincorrere. E, quasi sempre, è anche una persona in meno lasciata a reggere da sola finché il costo non diventa personale.

## Riferimenti

- Donella Meadows, *Pensare per sistemi*
- Esther Derby, Diana Larsen, *Agile Retrospectives*