BOLLETTINO OPERATIVO · GIO 18 GIU 2026 · 00:47 CET EN / IT / RSS / NEWSLETTER

Decostruzione, ingegneria e il malinteso del feedback

Esiste una postura mentale che premia chi sa smontare piu' di chi sa costruire. Il decostruttivismo da scrivania al lavoro, l'aneddoto del bike shed di Parkinson e cinque strategie per chi presenta progetti complessi.

Esiste una postura mentale che premia chi sa smontare più di chi sa costruire. La chiamerei decostruttivismo da scrivania, alla larga dal Derrida serio degli anni Sessanta. Quello vero — la decostruzione come pratica filosofica — voleva scovare contraddizioni interne, gerarchie implicite, presupposti taciti. Era un mestiere intellettuale duro, che richiedeva di leggere a fondo prima di smontare. La versione degradata che gira oggi negli uffici è il riflesso opposto: trovare un difetto qualsiasi, dichiararlo rivelatore del tutto, considerare quella mossa una prova di pensiero critico.

Non è critica. È un modo per partecipare alla discussione senza dover capire il sistema di cui si parla.

L’aneddoto del bike shed

Nel 1958 lo storico britannico C. Northcote Parkinson racconta una commissione direttiva chiamata a deliberare su tre punti: la costruzione di una centrale nucleare, la costruzione di una tettoia per le biciclette, l’acquisto del caffè per le riunioni. Il reattore viene approvato in pochi minuti — nessuno dei membri lo capisce abbastanza per discuterlo. La tettoia delle biciclette occupa quasi tutto il tempo restante: ognuno ha un’opinione sul materiale, il colore, le dimensioni. Tutti sanno cos’è una tettoia.

Da questo aneddoto la cultura tecnologica ha estratto un termine che oggi gira in tutto il mondo: bikeshedding. Indica il fenomeno per cui il tempo dedicato a un argomento è inversamente proporzionale alla sua importanza, perché chi non padroneggia un sistema discute il dettaglio visibile.

Come si manifesta sul lavoro

Lo vedo regolarmente. Presento un’architettura complessa — un sito che integra fonti dati eterogenee, gestisce errori, fa caching, espone API, regge picchi di traffico. Il primo commento è sul colore di un pulsante. Mostro una proposta di processo con quindici passaggi pensati a lungo: la discussione si arena sulla denominazione di una casella. Distribuisco una relazione tecnica densa: la prima osservazione riguarda la virgola di una slide di chiusura.

Il dettaglio non è mai sbagliato in sé. La tettoia delle biciclette esiste davvero, il colore va scelto. Il problema è la proporzione: quando il dettaglio mangia la discussione, il progetto perde il suo punto di gravità. Si esce dalla riunione con tre ore di osservazioni sui font e zero decisioni sui meccanismi.

Perché succede

Le ragioni sono tre, e sono umane prima che tecniche.

La prima è l’asimmetria di competenza. In una stanza con cinque persone di profili diversi, il numero di interlocutori in grado di valutare l’architettura è basso. Il numero in grado di valutare un colore è alto. La discussione si sposta dove c’è più traffico.

La seconda è il bisogno di partecipare. Stare in silenzio per quaranta minuti durante una presentazione tecnica è socialmente costoso. Se non si ha niente da dire sul sistema, si dice qualcosa sul dettaglio. È un modo legittimo di esserci, e va capito prima di essere disinnescato.

La terza è che il dettaglio funziona come territorio sicuro. Il colore di un pulsante è un campo dove tutti si sentono titolati. L’errore di percezione è considerare l’opinione su un campo dove tutti opinano altrettanto autorevole dell’opinione su un campo dove pochi possono opinare.

Come si difende chi costruisce

Non si elimina il bikeshedding, ma lo si governa. Ho imparato cinque cose, in ordine di utilità decrescente.

Dirigere lo sguardo prima di iniziare. Una presentazione che dice in apertura “oggi decidiamo X, Y, Z” e ricorda quali argomenti sono fuori scope risparmia ore. Il dettaglio resta possibile, ma chi lo introduce sa di farlo fuori traccia.

Separare i canali di feedback. La sostanza si discute in riunione, la forma si raccoglie per iscritto e si processa dopo. Mettere i due livelli sullo stesso tavolo è la condizione ideale perché il secondo divori il primo.

Presentare per livelli di astrazione. Prima il problema, poi l’architettura, poi i dettagli. Chi vuole opinare sul colore deve almeno aver sentito la spiegazione del sistema. Si sposta il punto di ingresso, non si chiude la porta.

Prendere sul serio l’osservazione superficiale, ma ricondurla. “Buon punto sul colore. Lo segniamo nella lista form. Tornando al sistema: cosa pensiamo del meccanismo di failover?” È rispettoso, non sprezzante, e riporta il timone.

Scegliere il pubblico. Non tutte le decisioni vanno prese davanti a tutti. Una scelta architetturale si discute con chi può valutarla; il colore con chi userà l’interfaccia. Confondere i due tavoli è la radice di molti bikeshedding.

Una nota finale

C’è una tentazione, in chi costruisce, di disprezzare chi smonta. È un riflesso comprensibile e quasi sempre controproducente. Il decostruttivismo da scrivania non si combatte con il sarcasmo, perché il sarcasmo conferma il copione: tu sei l’esperto arrogante, lui è il critico libero. Funziona meglio fare l’opposto: rendere la sostanza accessibile, raccontare il sistema in modo che chi vuole partecipare possa farlo a un livello che conta. La tettoia delle biciclette è un argomento legittimo. Va solo discussa al momento giusto, con le persone giuste, dopo aver deciso del reattore.