L’Universo, la termodinamica e il team management

“Il secondo principio della termodinamica è un principio secondo il quale molti eventi termodinamici, come ad esempio il passaggio di calore da un corpo caldo ad un corpo freddo, sono irreversibili.” 

La seconda legge della termodinamica è un’ottima ed elegantissima spiegazione del perché le cose del mondo tendono a essere inevitabilmente una rottura di scatole da risolvere. 

Le cose nell’Universo tendono spontaneamente ad aumentare la loro entropia, ovvero il livello di disordine. Se quindi le cose tendono spontaneamente a passare da uno stato di “ordine” a uno di “disordine”, per tenerle in “ordine” bisogna applicare “lavoro”, dove lavoro può essere tradotto con energia spesa – o appunto rotture di balle.

E che ci azzecca quindi con la pratica manageriale? 

Ecco, di base, il contesto dei sogni per il professionista manager medio è quello zero sbatti in tutti i sensi e i modi possibili. Ma se sei qui è perché non sei un professionista medio, e dobbiamo intenderci anche sulla definizione di “sbatti” che vogliamo avere.

È sbatti qualunque cosa provochi un importante livello di disagio del tutto fine a se stesso, anche se non necessariamente come unico risultato della cosa stessa. Esempio stupido: leggere un paper accademico di solito richiede un dispendio di risorse monetarie (costa) e mentali (è scritto in aramaico e nel modo più noioso possibile) che impattano seriamente sulla riuscita dell’azione in termini di generazione della conseguenza desiderata – che è, fuor di metafora, saperne di più su qualcosa. 

Non è, di contro, sbatti qualunque cosa che provochi un certo livello di disagio come prodotto di scarto in un contesto complesso che non è ancora domato e ristrutturato per essere funzionale al suo massimo – ma che insomma produce disagi non del tutto fini a se stessi. 

Esempio interessante: le normali fasi del team development. Parliamone.

Ora, il concetto originale è ovviamente accademico e risale al 1965, quando il Dottor Tuckman ha pubblicato l’articolo fondativo dell’idea, che se ti vuoi leggere trovi qui – a proposito di sbatti, auguri ad arrivare alla fine. 

Quella che ti propongo ora è invece la versione crash course dell’idea, togliendo il rumore di fondo del rigore accademico e concentrandoci su quel che ci deve trasmettere.

Secondo Tuckman, ci sono delle fasi necessarie ed inevitabili affinché un team di progetto si sviluppi, affronti le sfide ed i problemi di convivenza, trovi le soluzioni, progetti il lavoro e cominci a raggiungere i risultati attesi. 

Le fasi che consentono di costruire e sviluppare il team di progetto e di analizzarne il comportamento sono:

1. Forming – quando i membri del team si ritrovano effettivamente nel team, iniziano a prendere le misure gli uni con gli altri in modo piuttosto timido, tastano la temperatura delle acque in cui dovranno nuotare creandosi delle aspettative.
   
2. Storming – quando i membri del team si rendono conto, inevitabilmente, di aver tarato male le proprie aspettative rispetto alle dinamiche di team e alle task del progetto. Qui è quando possono volare i coltelli nella stanza, per intenderci, e dove un team può morire ancor prima di nascere davvero.
   
3. Norming – quando i membri del team trovano un nuovo modo di stare dentro il contesto e renderlo funzionale al raggiungimento dell’obiettivo comune. Qui è quando iniziano gli inside joke e i soprannomi tra membri del team, sintomi dell’atmosfera più rilassata e funzionale.
   
4. Performing – quando le cose funzionano davvero, si conoscono i limiti e i punti di forza degli altri, si contribuisce attivamente al raggiungimento dell’obiettivo e si inizia a credere davvero che il gruppo sia diventato più della somma delle sue parti. Qui è quando stai davvero bene mentre fai il tuo lavoro di manager.
   

Ora, il processo viene presentato spesso anche con una fase di termination che, anche se comunque critica, va un po’ fuori dall’idea di questo articolo. Quindi la ignoriamo. Per il resto, ti torna familiare ‘sta mappa? Al netto delle raccomandazioni specifiche che vengono fatte per una fase o per l’altra, ci sono due punti che vorrei evidenziare. 

Il primo punto è che la monodirezionalità del processo è una semplificazione. 

Non è che un performing team sia immune al variare delle condizioni esterne, o immutabile nelle sue condizioni interne. Una nuova risorsa, una risorsa in meno, una deadline in più, un progetto profondamente distante dalle competenze interne del team… Tutto può portare fuori dalla fase di performing, potenzialmente. Non c’è linearità in questo processo, spesso si opera in un messy middle come quello dei purchase journey di Google. Devi essere bravo a navigarci, quindi, in questo infinito disequilibrio; la natura tende al disordine, all’aumento dell’entropia, il tuo lavoro è mettere ordine e senso nei sistemi.

Secondo punto e conseguenza di ciò: un team non funziona spontaneamente perché un sistema non passa dal disordine all’ordine spontaneamente; un team, come un sistema in fisica, non ha un innato disegno intelligente a orientarlo, ma ti dà l’occasione di darglielo, di farlo funzionare. E quindi? E quindi preoccupati quando non c’è una fase di storming, non quando c’è.

Preoccupati quando ti sembra di avere a che fare con un team di robot distaccati emotivamente e intellettualmente dal progetto che hai per le mani, perché con ogni probabilità è così. 

Lo storming, il confronto anche spiacevole, la tensione, il disaccordo… Tutti pungoli che spingono il team verso la fase di performing, perché senza lo scontro tra le diversità interne al team non ci può essere aggiustamento, e quindi funzionamento. 

La quiete che non è frutto di un norming è solo un disordine travestito, a cui manca il disegno intelligente – e che quindi, se proprio funziona, funziona per grazia divina.

Riconoscere il disordine e quindi entrare nello storming è sano, è funzionale, non è uno sbatti perché ti aiuta a fare il tuo lavoro di leader – leader, ancor prima che manager, perché non devi necessariamente essere a capo di un team di direct report per vedere queste fasi e influire sulla corretta evoluzione dell’efficacia del team. 

Ogni progetto di team, se non controllato e gestito tende spontaneamente ad aumentare l’entropia (come l’universo e la termodinamica), e da qui si differenzia un “gran” manager da un manager, ovvero dalla capacità di mettere ordine e guidare in modo scientifico (le fasi di Tuckman ne è da esempio) il processo di sviluppo del lavoro nel team.