Recensioni Killing 360: come abbiamo smesso di valutare le persone e abbiamo iniziato a gestire il lavoro
Ciao! Mi chiamo Vitalina e sono un account manager presso SToFU Systems.
Siamo quel tipo di azienda in cui i processi nascono in movimento e solo dopo ottengono nomi, regole e supervisione di adulti. All'inizio non avevamo una nostra scuola di management, quindi copiavamo quello che "tutti copiano". Una di queste abitudini di gestione prese in prestito era il feedback a 360 gradi.
Sulla carta, il 360 sembra qualcosa di giusto e maturo. Molte fonti. Meno pregiudizi. "Obiettività". Mmm!
In pratica si è trasformato in qualcos'altro. Per noi 360 non è stato uno strumento che ha rafforzato la squadra. È stato uno strumento che ha silenziosamente diviso la squadra. Formalmente sembrava corretto, ma nella realtà lavorativa spingeva nella direzione sbagliata. Quindi lo abbiamo tagliato fuori. Andiamo passo dopo passo.
Cos'è 360?
360 è quando raccogli feedback su una persona "da tutte le parti": dal manager, dai colleghi, dai compagni di squadra adiacenti e talvolta dai clienti. Generalmente è un questionario con valutazioni e domande come "cosa va bene", "cosa ostacola", "cosa dovrebbe essere cambiato".
Anche noi lo abbiamo fatto. Abbiamo inviato un questionario, raccolto risposte, aggregate e scritto raccomandazioni. Formalmente tutto sembrava in ordine. C'erano punti dati. Ci sono state delle conclusioni. C'era un "piano di sviluppo".
Per rendere più chiaro di che tipo di “questionario” stiamo parlando, farò un esempio molto semplificato di quello che solitamente viene chiesto in 360. Questa non è una citazione parola per parola dal nostro modulo, ma una logica tipica.
Ad esempio: "Cosa dovrebbe continuare a fare una persona?". Poi: "Cosa dovrebbe cominciare a fare una persona?". Poi: "Cosa dovrebbe smettere di fare una persona?". E un'altra domanda che sembra sempre innocente: "Descrivi una situazione in cui l'interazione è stata difficile e perché".
E il riassunto spesso sembra un piccolo resoconto di un occhio collettivo che tutto vede. Più o meno così:
Punti di forza: accetta rapidamente i compiti, aiuta gli altri, non scompare dal radar. Rischi: "pronto" a volte significa "quasi pronto", la discussione nelle riunioni può essere tagliente, in chat si risponde frammentariamente. Cosa fare dopo: concordare la Definizione di Fatto, sincronizzare le aspettative, concordare il formato dell'escalation.
Sulla carta va tutto bene. Bellissimo, addirittura. Ma c'è un dettaglio. È scritto da persone che lavorano insieme ogni giorno. E una volta aggiunto l'anonimato, o ritardato feedback "per dopo", smette di essere uno strumento di sviluppo e inizia a vivere una vita propria. Immagina un team di progetto di cinque persone. Poi qualcuno dice: "Ecco il feedback anonimo". Anonimo. In una squadra di cinque. E in questa realtà 360 comincia a mostrare il suo vero volto.
Perché 360 è diventato uno strumento per separare il team
1. Punto uno. Lode - una riga, critica - un romanzo in tre volumi
Quando le cose vanno bene, le persone scrivono brevemente. "Va tutto bene." "Lavoro comodo." "Ben fatto". Questo è un feedback al livello di un adesivo su un quaderno di scuola. Quando qualcosa non va, inizia la letteratura. Con i dettagli, con esempi, con emozioni. E tecnicamente questo è normale: il negativo è più facile da specificare che il positivo. Ma in 360 c'è il problema: l'intero "romanzo" poi ritorna a una persona come generalizzato verdetto della squadra
Anche se lo dici nel modo più gentile possibile, il cervello umano si legge così: "Ci siamo riuniti tutti e abbiamo scritto cosa c'è che non va in te." E questo è tutto. Dopodiché, ogni tentativo di Il "feedback costruttivo" sembra un'udienza in tribunale. Volevi uno strumento di sviluppo e abbiamo ottenuto un tribunale collettivo.

Ci siamo chiesti onestamente: cosa stiamo cercando di fare veramente questa pratica? Disciplina il formato, sì, ma distrugge la fiducia.
Dalla vita sembra così. Un rapporto arriva a una persona, dove ce ne sono tre frasi "va tutto bene", e due tele "ecco perché non va bene". E il cervello, ovviamente, ricorda non tre "ok", ma due "non va bene". Perché l'attenzione è organizzata così: fa male, quindi è importante! E da quel momento in poi, la persona non si muove verso lo sviluppo, ma verso l'autodifesa. Essi iniziare a dimostrare che "non è vero", oppure che «era il contesto», oppure che «nemmeno voi siete santi». E in questo momento 360 si trasforma in un rituale dove tutti come se volessero bene, ma è andata come al solito.
2. Punto due. L'anonimato in una piccola squadra è un autoinganno
Esiste una favola manageriale familiare: "Il feedback anonimo rimuove la paura". Anonimato? Veramente? In piccoli team di progetto? In realtà significa quasi sempre "indovinerò chi ha scritto questo!".
Una persona riceve diverse osservazioni spiacevoli, e poi arriva alla prossima riunione di progetto dove sono sedute quelle stesse 3-5 persone. Non pensano allo "sviluppo organizzativo". Pensano: "Quale uno di voi era?" E questo avvia un processo molto tossico: tutti rimane esteriormente educato, ma sotto c'è uno strato nascosto di sfiducia.
Non sempre esplode in un conflitto aperto. Semplicemente rende la squadra più fredda. Meno coeso. Meno disposto ad aiutare. E poi ci chiediamo perché le persone non condividono i loro problemi "nelle fasi iniziali". Ma perché lo sono già una volta condiviso - ed è stato restituito loro in modo anonimo un elenco di rivendicazioni.
3. Non appena 360 influenza le decisioni sulla promozione, i giochi iniziano
Ecco la cosa più interessante. E la cosa più triste.
In una delle nostre discussioni di coordinamento, lo abbiamo notato qualcosa di strano. Una persona può essere educata, solidale e con cui è facile lavorare durante le chiamate. All'interno della squadra possono sembrare dei veri innamorati. Poi gli dai un questionario "anonimo" dove possono "valutare gli altri", e all'improvviso il punteggio cala o le critiche diventano eccessive. Abbiamo visto questo effetto noi stessi. Ha funzionato direttamente contro l’integrità.
Immagina la situazione. Dici al team: "360 valutazioni contano ai fini del promozione." E nello stesso secondo, giri parte del squadra in giocatori, non in colleghi. Perché se il pulsante "influenza" appare nel sistema, qualcuno lo premerà. Non sempre dal male. A volte semplicemente sentendo ingiustizia ("e perché viene promosso, è..."). A volte dalla concorrenza. A volte perché "è così che funziona il mondo". E in quel momento ottieni ciò che volevi evitare: politica, giochi, voti "per ogni evenienza più bassi".
Questo, tra l'altro, è uno dei motivi per cui molti ricercatori e si consiglia ai professionisti di condividere feedback per lo sviluppo e decisioni amministrative (denaro, voti, promozioni). Il CIPD lo dice senza mezzi termini: se ne parla è meglio separare le valutazioni/decisioni amministrative dalle conversazioni, dove viene fornito feedback ai fini dello sviluppo. Ecco un PDF dalla loro revisione delle prove (riepilogo della pratica): www.cipd.org/...e-review_tcm18-111378.pdf
4. Punto quattro (la nostra dolorosa intuizione). 360 sostituisce spesso il lavoro del manager
Dopo diversi cicli, ci siamo ritrovati con una frase che prima suonava come un insulto e poi suonava come la verità.
Se un manager ha bisogno di una visione a 360 gradi per capire come lavorano le persone e dove sono i problemi, quel manager non ha un sistema di segnali osservabili. Non ci sono metriche. Non ce ne sono conversazioni regolari. Non c'è ritmo. Oppure tutto ciò esiste "da qualche parte", ma non viene effettivamente utilizzato.
E 360 diventa una stampella: "ora raccoglieremo il questionario e finalmente impareremo la verità." E poi non ottieni la "verità" e un'immagine emotiva, moltiplicata per l'anonimato e le congetture e giochi politici.
Quindi non suona come "ci è andata male, quindi 360 è il male", aggiungerò un riferimento.
Esiste uno studio sul feedback multifonte. La sua conclusione è sostanzialmente: "non aspettatevi la magia". In una meta-analisi di 24 studi longitudinali, Smither, London e Riley scrivono che il miglioramento è avvenuto dopo Il feedback a 360 gradi è generalmente modesto e non dovresti aspettarti grandi risultati "aggiornamento di massa" dopo un'ondata di feedback. La possibilità di miglioramento aumenta quando una persona vede una reale necessità di cambiare, accetta il feedback, crede che possano cambiare, fissa obiettivi concreti, e in realtà fa qualcosa, invece di limitarsi a "leggere un PDF e andare avanti." Ecco il testo stesso (PDF): www.bauer.uh.edu/...ngs/SmitherLondon2005.pdf
Ok, abbiamo rimosso 360. Cosa lo ha sostituito?
Abbiamo smesso di misurare le persone in base al numero di biglietti
Un biglietto può contenere una settimana di ricerca, una decisione difficile, dieci chiamate e solo 20 righe di codice. In un altro - 50 funzionalità effettivamente emerse da un'esecuzione dell'agente AI. tra 20 minuti.
Se stai solo misurando i biglietti, stai effettivamente misurando non il lavoro, ma il modo in cui il tuo processo riduce il lavoro a pezzi
Ecco perché abbiamo cambiato la domanda. Non "quante attività ho chiuso?" Ma: Cosa è stato fornito, quale valore ha creato, qual era la qualità, era prevedibile e gli status erano onesti?
Come abbiamo definito il "risultato" senza il teatro gestionale
Siamo convergenti su un quadro semplice.
Un risultato si ha quando viene fornito valore, la qualità è accettabile, il team è prevedibile e il progresso è trasparente.
Il valore non è "il codice è scritto". Significa che "l'utente o il cliente ha ottenuto un risultato migliore" o "è diventato più facile per il team sostenere il sistema”.
La qualità non è "mi piace il tuo codice". Queste sono le conseguenze: bug nel prodotto, incidenti, revisioni.
La prevedibilità non è "ce la facciamo sempre". È: "comprendiamo onestamente per cosa abbiamo tempo e per cosa no, e non mentiamo a noi stessi al riguardo."
La trasparenza è quando il “quasi finito” non si trasforma in una filosofia di vita.
Metrica
Quando le persone sentono la parola "metriche", molti immediatamente ricorda il lavoratore leggermente traumatizzato dall'esperienza passata: quello che è stato picchiato in testa con i numeri.
Le metriche non dovrebbero essere una frusta. Dovrebbero essere occhiali. Senza di essi, un manager è spesso cieco. E quando il manager è cieco, inizia a cercare "obiettività" nei questionari. Bene, hai capito.
Abbiamo lasciato i parametri a livello di squadra, perché la maggior parte dei problemi sono sistemici! E se non vogliamo cercare i colpevoli, ma correggere il processo, allora dobbiamo misurarlo!
Onestamente qui non abbiamo inventato nulla. DORA (DevOps Ricerca e valutazione) promuove già un approccio molto pratico insieme di parametri di consegna: quanto velocemente fornisci il cambiamento e quanto sono dolorosi i fallimenti quando i cambiamenti vanno male. Ecco la loro guida rapida: dora.dev/guides/dora-metrics.
C'è anche un'osservazione importante che vorrei precisare sul muro a chiunque abbia mai desiderato creare metriche KPI: "non fare della metrica l'obiettivo"! Perché non appena dici "dobbiamo distribuire N volte al giorno", parte di il team inizia a distribuire non un valore, ma un numero. Questo è il vecchio storia che una volta che una metrica diventa l'obiettivo, smette di esserlo un indicatore. DORA fa esplicito riferimento alla legge di Goodhart e descrive le tipiche insidie. Ecco la pagina sulle "quattro/cinque chiavi" in parole semplici: dora.dev/...s/dora-metrics-four-keys
E un'altra cosa importante che DORA normalmente sottolinea: il contesto è importante Questi parametri vengono visualizzati al meglio all'interno di uno squadra o servizio e nel tempo, non tramite confronti un'applicazione mobile con un mainframe o un piccolo team con una piattaforma per 200 persone.
Se non sei un team tecnico, la logica è la stessa. Invece di "deploy" potresti avere "il cliente ha accettato il risultato"; invece di "incidente" potresti avere "escalation"; invece di "rollback", "rielaborazione dopo l'allineamento". Il punto è sempre lo stesso: quanto velocemente muoviamo il valore attraverso il sistema e quanto ci costa l’errore.
E ora - l'importantissimo "non farlo". Non convertire queste metriche in KPI individuali! Perché allora le persone iniziano a ottimizzare non il prodotto, ma il numero. KPI sulle "distribuzioni" e all'improvviso si hanno distribuzioni fine a se stesse. KPI sul "tempo di ciclo" e le attività vengono suddivise fino al punto di assurdità solo per "chiuderle rapidamente", mentre le parti difficili scompaiono silenziosamente nell'ombra. I KPI sugli "incidenti" e gli incidenti iniziano a essere rinominati come "peculiarità" o "scenari utente imprevisti".
La prima cosa che ci ha aiutato è stata la prevedibilità. Semplice domanda: cosa abbiamo promesso nella pianificazione e cosa è stato effettivamente dato. Non per vergogna. Per capire. Perché se prometti costantemente 10 e ne fai 6, allora il problema non sono i "pigri". Il problema è nella stima priorità, WIP, bloccanti, cambio di contesto. In altre parole, nella gestione.
Il secondo è il tempo di consegna. Quanto tempo richiede l'attività? nel percorso dal "portato al lavoro" al "realmente consegnato". È molto deludente. Perché spesso si scopre che "scriviamo codice" rapidamente, ma "consegniamo" lentamente. E poi puoi vedere dov'è il collo di bottiglia: revisione, test, liberazione, riconciliazione, dipendenze.
Il terzo è WIP. Se la squadra è "al lavoro" allo stesso tempo dieci problemi contemporaneamente, poi nessuno fa davvero nulla. Più precisamente, tutti fanno tutto in una volta. E poi ci chiediamo perché il progresso si sente lento e nervoso. Quando il cervello è steso in uno strato sottile attraverso dieci attività, non diventa più produttivo. Diventa semplicemente più stanco.
Un’altra cosa che ci ha aiutato a pensare più chiaramente è stata questa: se si vuole che il lavoro si muova più velocemente attraverso il sistema, spesso la risposta non è quella di spingere di più sulle persone. È quello di ridurre le dimensioni del lotto. Le modifiche più piccole sono più facili da rivedere, testare, rilasciare ed eseguire il rollback. DORA sottolinea direttamente lo stesso punto: lotti più piccoli di solito migliorano sia la velocità che la stabilità. Sembra ovvio finché una squadra non prova effettivamente a conviverci per un mese.
Qualità: abbiamo smesso di discutere "mi sembra" e abbiamo iniziato a guardare alle conseguenze
Valutare la "qualità" con i questionari è una cattiva idea. Perché la "qualità" nel questionario si tratta spesso di simpatia, stile e gusto.
Siamo passati alle conseguenze.
Quanti difetti hanno raggiunto la produzione. Quanto erano seri? Come sta cambiando la tendenza?
Quanti incidenti abbiamo avuto. Quanto tempo ci è voluto per riprenderci? Si ripetono gli stessi motivi?
Quante revisioni. How many tasks were "passed" and then returned. Because "ready" turned out to be not ready.
Non stai più discutendo su "chi è il migliore". Vedi cosa sta realmente accadendo con il prodotto.
Una conclusione controintuitiva: perché valutare una persona?
Più a lungo scavavamo, più spesso ci imbattevamo in una strana domanda.
Perché valutiamo una persona? Rifiutare una promozione? Per mostrare chi è la "stella"? Per confrontare le persone?
E quando ne abbiamo parlato onestamente, si è scoperto che la maggior parte dei nostri bisogni reali non riguardava il posizionamento persone. Riguardavano le prestazioni della squadra: stiamo facendo cosa? abbiamo promesso, la qualità è buona, il lavoro è prevedibile, stiamo esaurendo e il cliente ottiene cosa? si aspettano?
Cioè, riguardo al sistema.
E se è così, allora il primo oggetto di valutazione è il team e il processo. E non una persona come bersaglio.
La squadra sta sottoperformando, quindi rivediamo il tutto catena: assunzione, onboarding, definizione delle attività, pianificazione, revisione, test, rilascio, comunicazione, dipendenze. Questo è manageriale più difficile, sì. Ma è più onesto.
A volte sembra molto semplice. Ad esempio, quando "non abbiamo avuto ancora tempo", la prima domanda non è "chi sta rallentando", e "dove è scomparso il tempo". Perché il tempo può scomparire non nel "lavoro", ma nell'attesa: i compiti stanno in revisione, stare in prova, bloccato previo accordo, o ce ne sono semplicemente troppi in parallelo.
Quando qualcuno è in difficoltà, cosa controlliamo prima
A volte vediamo anche situazioni in cui qualcuno "non tira". Ma invece di un questionario, facciamo una semplice diagnosi.
Questo problema c'è sempre stato? Se è così, il problema è probabile nell'assunzione o nell'onboarding. In tal caso, correggi il processo di assunzione, non la persona con i questionari.
Prima era normale e poi è peggiorato? Poi può essere il contesto: burnout, cambio di compiti, conflitto di ruoli, circostanze personali. Questa è la zona del normale lavoro manageriale: scoprire cosa è successo, ridurre il carico, aiutare la persona a riconquistare controllo e costruire un breve piano di recupero di 2-4 settimane.
La persona ha una chiara comprensione di cosa sia il successo sembra nel prossimo futuro? Perché spesso il problema non lo è che la persona è "debole". È che li abbiamo messi nella nebbia e le chiamava aspettative.
E un'altra sfumatura che avevamo anche noi. Se una persona fallito più volte, il manager a volte può rilanciare soggettivamente bar: "ora dimostra che non sei un fallito." Questo spesso funziona a livello subconscio e funziona male per la squadra. Di solito è meglio fare il contrario: ridurre la portata, ridurre i compiti, rimuovere il rumore, dare a una persona la possibilità di fare costantemente alcune cose bene e ritrovare la fiducia in se stessi. Questo è un compito difficile per gestori. Ed è proprio per questo motivo che guardiamo molto da vicino ai manager che assumiamo.
Conclusioni
Ovviamente il 360 può funzionare. Nelle grandi aziende, dove l’anonimato è davvero possibile.
Quando il team ha già una cultura del feedback diretto, e 360 è un segnale aggiuntivo, non quello principale "verità".
Non lo avevamo. Avevamo squadre piccole, un ritmo veloce e un alto costo di sfiducia.
Sulla carta il 360 sembrava uno strumento adulto. Nel nostro realtà, è diventato un meccanismo che raccoglie la paura in un unico posto, congetture, competizione e "giudizio collettivo".
Abbiamo eliminato 360 e siamo tornati alle origini: semplici metriche del team, conversazioni aperte e stati trasparenti.
Materiali e link (se vuoi approfondire)
DORA — software delivery performance metrics. Una spiegazione fondata dei cinque parametri e delle trappole in cui cadono i team quando ne abusano.
DORA — DORA’s software delivery performance metrics. Versione breve con lo storico "perché quattro/cinque" e un avvertimento sui giochi con metriche.
DORA Research: 2024 — DORA Report. Rapporto completo (scarica PDF in varie lingue).
Smither, London (2005) — meta-analysis on multisource feedback. Perché non dovresti aspettarti un effetto magico da un'onda a 360 gradi.
CIPD — Performance feedback: an evidence review (PDF). Su come funziona/non funziona il feedback e perché confondere "valutazione" con "sviluppo" è spesso dannoso.
CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Se fai ancora un 360, c'è qualcosa a cui pensare prima della partenza, non dopo l'incendio.
CCL — SBI feedback model. Un quadro molto semplice per un feedback "senza scorciatoie".
Google SRE — Postmortem Culture: Learning from Failure. Sulle autopsie irreprensibili e sul perché la cultura della vergogna sta uccidendo l'apprendimento.
Amy Edmondson (1999) — Psychological Safety (PDF). Fonte primaria sulla sicurezza psicologica nei team.
WEF — Feedforward technique. Su come spostare il feedback nella direzione di "cosa faremo dopo" e non di "cosa è successo ieri".
Goodhart’s law. Una delle "anti-teorie" più utili per chi vuole fare metriche KPI.
Domande per la Comunità
Cosa pensa la community di 360? Lo usi? Com'è stata la tua esperienza?
Come si risolve il problema dell'anonimato quando la squadra è piccola e tutti capiscono tutto?
E quali parametri di consegna/qualità ti aiutano effettivamente a gestire il processo invece di redigere report carini?
Grazie per il tuo tempo e la tua attenzione.