Contenuto articolo
Il team di Marco non funziona. Lo sanno tutti. La diagnosi arriva in fretta: “Marco non è motivato”. “Sara non comunica”. Si decide: un one-on-one con Marco per capire cosa lo blocca, un workshop di team building, e se le cose non migliorano si cambia qualcuno.
Tre mesi dopo, Marco se n’è andato. È arrivato Luca. Il team non funziona ancora.
La scena si ripete perché la diagnosi è sbagliata. Non sbagliata in modo ovvio — sbagliata in modo plausibile, che è peggio. “Marco non è motivato” suona ragionevole. Tutti annuiscono. Peccato che il problema non sia Marco.
La psicologia sociale ha un nome per questo: fundamental attribution error. Ross lo ha descritto nel 1977: quando osserviamo un comportamento, tendiamo ad attribuirlo a tratti della persona (pigrizia, scarsa collaboratività) sottovalutando il peso della situazione in cui quella persona si trova.
J. Richard Hackman ha studiato team per quarant’anni: equipaggi di volo, orchestre, squadre di intelligence. Il punto fermo della sua ricerca: le condizioni strutturali in cui un team opera spiegano fino all’80% della varianza nella sua efficacia (Wageman, Hackman & Lehman, 2005). Quando un team non funziona, il problema più probabile non è chi ci lavora dentro. È come è stato progettato.
Prima di cambiare le persone, conviene verificare le condizioni.
Le cinque condizioni: una checklist, non una teoria
Hackman non ha prodotto un modello astratto. Ha prodotto una checklist. Cinque condizioni che, se presenti, rendono probabile che un team funzioni. Se assenti, rendono probabile il contrario. Le ha validate empiricamente su centinaia di team in contesti diversi, e funzionano come strumento diagnostico molto prima che come teoria.
Le riassumo con una traduzione rapida nel contesto software. Chi vuole il quadro completo può partire dal pezzo precedente su Hackman e la distinzione team/gruppo di lavoro.
1. Essere un team reale. Confini chiari, composizione stabile, interdipendenza reale. Se manca anche solo una di queste tre, non hai un team. Hai un gruppo di persone con un manager in comune.
2. Una direzione convincente. Un obiettivo chiaro, sfidante e significativo. Non “chiudere le story dello sprint”, che è un’unità di misura, non una direzione. Una direzione convincente risponde alla domanda: perché questo lavoro conta?
3. Una struttura abilitante. Ruoli, norme, competenze. Il minimo di infrastruttura perché le persone non debbano rinegoziare tutto da zero ogni settimana.
4. Un contesto organizzativo che supporta. Il team ha le informazioni che gli servono? Le risorse? Il sistema di reward incentiva il risultato di gruppo o la performance individuale? Questa è la condizione che il team non può darsi da solo. Dipende dall’organizzazione intorno.
5. Un coaching competente sul processo. Non mentoring tecnico: qualcuno che aiuta il team a lavorare meglio insieme. Come prendono decisioni, come gestiscono i disaccordi, come distribuiscono il lavoro. È la condizione che conta meno delle altre quattro (il 10% del 60/30/10 di Hackman), ma è quella su cui tutti si concentrano.
L’istinto di chi gestisce team è partire dal fondo: coaching, facilitazione, dinamiche interpersonali. Hackman dice: parti dall’alto.
La tabella che ribalta la diagnosi
Ecco il nucleo del discorso. Sei frasi che sento ripetere in continuazione, e per ciascuna la diagnosi abituale, la causa strutturale più probabile, e dove conviene guardare.
Alcune di queste mappature sono ancorabili direttamente alla ricerca di Hackman. Altre sono la mia traduzione nel contesto software, e le segnalo.
”Marco non è motivato”
È un problema di Marco, si dice. Manca di drive, di ownership, forse non è la persona giusta per il ruolo.
Più probabilmente manca una direzione convincente (condizione 2). Se l’obiettivo del team è vago, puramente gestionale o cambia ogni due settimane, la motivazione non è un tratto di Marco. È una risposta razionale a un contesto che non dà ragioni per investire energia. Ho visto sviluppatori brillanti sembrare svogliati perché il mandato del loro team era “supportare il prodotto”, che in pratica significava rispondere a ticket senza fine e senza una visione di dove si stava andando.
Non guardare a Marco. Guarda al mandato del team. Se non riesci a spiegare in una frase perché quel lavoro conta, il problema è lì.
”Sara non comunica”
Dove guardare, in questo caso, è al design del lavoro. Se ogni persona lavora su una feature separata e le interazioni si limitano a qualche commento su una pull request, non c’è motivo strutturale per comunicare di più. Sara non è poco collaborativa. È razionale: perché dovrebbe aggiornare gli altri su un lavoro che non li riguarda?
La causa è la mancanza di interdipendenza reale (condizione 1). Puoi organizzare tutti i workshop di comunicazione che vuoi: se la struttura del lavoro non genera dipendenze reciproche, la comunicazione resterà un rituale vuoto.
”Il team non si fida”
La reazione classica: team building, esercizi di vulnerabilità, un offsite per conoscersi meglio.
La fiducia in un team non nasce da un workshop di un pomeriggio. Nasce dal lavorare insieme abbastanza a lungo da poter prevedere come si comporterà l’altro. Hackman lo ha visto con gli equipaggi di volo: quelli che volavano insieme da tempo commettevano meno errori di quelli appena formati, anche con piloti meno esperti. Il problema più probabile è la composizione instabile (condizione 1). Se ogni trimestre ruoti le persone tra team, riparti da zero ogni volta.
Quante volte è cambiata la composizione nell’ultimo anno? Se la risposta è “spesso”, il deficit di fiducia non è un problema relazionale. È turnover strutturale.
”Le retro non producono nulla”
Qui la domanda viene prima della risposta: c’è un processo condiviso da migliorare? Le retrospettive presuppongono un team che collabora su un risultato comune e vuole migliorare il modo in cui lo fa. Se ognuno ha il suo flusso, le sue priorità e i suoi blocchi, la retro non ha un oggetto. Il formato non c’entra. La causa è che il gruppo non è un team reale (condizione 1).
”Il lead non riesce a guidare il team”
La diagnosi abituale: mancano le soft skill. Mandiamolo a un corso di leadership.
Il lead può essere bravissimo, ma se il team non ha accesso alle informazioni che gli servono, se le risorse vengono tagliate senza preavviso, se il sistema di valutazione premia la performance individuale e ignora quella di gruppo, il lead è in una posizione impossibile. È come chiedere a un pilota di atterrare bene con un aereo progettato male — puoi mandarlo a tutti i corsi di volo che vuoi, ma se i flap non funzionano, il problema non è la sua tecnica.
La causa è il contesto organizzativo (condizione 4). Il lead ha l’autorità per prendere decisioni? Le priorità sono stabili abbastanza da permettere un piano? Se no, la leva è nell’organizzazione, non nella persona.
”Troppi conflitti”
Qui la risposta è meno lineare. Il conflitto in un team può essere un buon segno: se il team è reale e sta negoziando le norme su come lavorare insieme (condizione 3), un certo grado di attrito è fisiologico. Hackman lo dice chiaramente: i team migliori non sono quelli senza conflitti, sono quelli che hanno imparato a gestirli.
Ma il conflitto può anche essere il sintomo di confini poco chiari (condizione 1): chi decide cosa? Chi ha autorità su quale parte del sistema? Se due persone pensano entrambe di essere responsabili della stessa area, il conflitto non è relazionale. È strutturale.
La distinzione utile: se il conflitto è su come fare le cose, probabilmente è sano. Se è su chi dovrebbe fare cosa, è un problema di confini. E se è cronico nonostante le buone intenzioni di tutti, quasi certamente non è un problema di persone.
Perché continuiamo a sbagliare diagnosi
Se le condizioni strutturali contano così tanto, perché il default è sempre “colpa di qualcuno”?
La prima ragione è che la struttura è invisibile. Le persone le vedi. I comportamenti li vedi. Le condizioni in cui quei comportamenti emergono, no. Hackman ha insistito su questo punto nell’ultimo paper della sua carriera, “From causes to conditions” (Hackman, 2012): la ricerca sui team si è concentrata troppo sulle cause interne (chi fa cosa, come si comportano) e troppo poco sulle condizioni esterne (come il team è progettato, in che contesto opera). Lo stesso vale per chi gestisce team nella pratica.
La seconda è che cambiare le persone sembra più facile. Dare un feedback a Marco, mandare Sara a un workshop, sostituire il lead: sono tutte azioni che un manager può fare domani mattina. Ridisegnare il mandato del team, stabilizzare la composizione, cambiare il sistema di incentivi richiedono tempo, autorità e spesso negoziazione con chi sta sopra. La diagnosi interpersonale è attraente perché ha soluzioni a portata di mano. Peccato che siano le soluzioni sbagliate.
La terza è più insidiosa, e l’ho vista da vicino: l’organizzazione incentiva la diagnosi individuale. Le performance review valutano le persone, non le condizioni. I PIP si applicano alle persone. Il “fit culturale” è un attributo delle persone. L’intero apparato di gestione è costruito attorno all’idea che la performance sia un tratto individuale. Ammettere che il problema è strutturale significa ammettere che il sistema è progettato male, e chi ha progettato il sistema è spesso chi sta facendo la diagnosi.
La prossima volta che qualcuno dice “il problema è Marco”, fermati un momento. Non perché Marco sia necessariamente innocente: a volte il problema è davvero la persona. Ma è meno frequente di quanto pensiamo, e la diagnosi interpersonale è così intuitiva che ci arriviamo sempre per prima.
Prova a riformulare. Non “chi non funziona?” ma “cosa nella struttura non funziona?”. Passa dalla persona alla condizione. Poi chiediti: questa condizione è sotto il mio controllo? Se sì, è lì che va l’energia. Se no, almeno sai che nessun workshop di team building la risolverà.
Non è una differenza da poco. È la differenza tra debuggare il codice e debuggare il compilatore.
Fonti
- Hackman, J.R. (2002). Leading Teams: Setting the Stage for Great Performances. Harvard Business School Press.
- Hackman, J.R. (2011). Collaborative Intelligence: Using Teams to Solve Hard Problems. Berrett-Koehler.
- Hackman, J.R. (2012). From causes to conditions in group research. Journal of Organizational Behavior, 33, 428-444.
- Wageman, R., Hackman, J.R. & Lehman, E.V. (2005). Team Diagnostic Survey: Development of an Instrument. Journal of Applied Behavioral Science, 41(4), 373-398.
- Ross, L. (1977). The intuitive psychologist and his shortcomings: Distortions in the attribution process. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology (Vol. 10, pp. 173-220). Academic Press.
