Tuer les avis 360 : comment nous avons arrêté d'évaluer les gens et commencé à gérer le travail

Bonjour! Je m'appelle Vitalina et je suis responsable de compte chez SToFU Systems.

Nous sommes le genre d'entreprise où les processus naissent en mouvement et reçoivent seulement plus tard des noms, des règles et la supervision d'un adulte. Au départ, nous n'avions pas notre propre école de management, donc nous copiions ce que « tout le monde copie ». L’une de ces habitudes de gestion empruntées était le feedback 360.

Sur le papier, la 360 ressemble à quelque chose de juste et de mature. De nombreuses sources. Moins de biais. "Objectivité". Mmmm !

Dans la pratique, 360 a discrètement séparé l’équipe au lieu de la renforcer. Formellement, cela semblait correct, alors que le travail réel avançait dans la mauvaise direction. Nous l'avons donc supprimé. Allons-y étape par étape.

Qu'est-ce que 360 ?

360, c'est quand vous collectez des commentaires sur une personne « de tous côtés » : du manager, des collègues, des coéquipiers adjacents et parfois des clients. Généralement c'est un questionnaire avec des notes et des questions comme "ce qui va bien", "ce qui gêne", "ce qui devrait être changé".

Nous l'avons fait aussi. Nous avons envoyé un questionnaire, collecté les réponses, les avons regroupées et rédigé des recommandations. Formellement, tout semblait bien rangé. Il y avait des points de données. Il y a eu des conclusions. Il y avait un « plan de développement ».

Pour bien comprendre de quel type de « questionnaire » nous parlons, je vais donner un exemple très simplifié de ce qui est habituellement demandé en 360. C'est une logique typique de la forme, paraphrasée.

Par exemple : « Que devrait-on continuer à faire ? ». Puis : « Que devrait-on commencer à faire ? ». Puis : « Que devrait-on arrêter de faire ? ». Et une autre question qui semble toujours innocente : « Décrivez une situation où l'interaction a été difficile et pourquoi. »

Et le résumé ressemble souvent à un petit rapport d’un œil collectif qui voit tout. A peu près comme ça :

Points forts : assume les tâches rapidement, aide les autres, ne disparaît pas des radars. Risques : « prêt » signifie parfois « presque prêt », la discussion lors des réunions peut être vive, dans le chat il répond par fragments. Que faire ensuite : se mettre d'accord sur la définition de Terminé, synchroniser les attentes, se mettre d'accord sur le format de remontée d'informations.

Sur le papier, tout va bien. Magnifique, même. Mais il y a un détail. Il est écrit par des personnes qui travaillent ensemble au quotidien. Et une fois que vous avez ajouté l'anonymat, ou retardé feedback "pour plus tard", ça cesse d'être un outil de développement et commence à vivre sa propre vie. Imaginez une équipe de projet de cinq personnes. Puis quelqu'un dit : « Voici des commentaires anonymes. » Anonyme. Dans une équipe de cinq personnes. Et dans cette réalité, le 360 ​​commence à montrer son vrai visage.

Pourquoi 360 est devenu un outil pour séparer l'équipe

1. Pointez un. Louange - une ligne, critique - un roman en trois volumes

Quand tout va bien, les gens écrivent brièvement. "Tout va bien." "Travail confortable." "Bien joué". Il s’agit d’un feedback au niveau d’un autocollant sur un cahier d’écolier. Quand quelque chose ne va pas, la littérature commence. Avec des détails, avec des exemples, avec des émotions. Et techniquement c'est normal : le négatif est plus facile à spécifier que le positif. Mais en 360 il y a le problème : tout ce « roman » revient alors à une seule personne comme un verdict de l'équipe.

Même si vous le formulez aussi doucement que possible, le cerveau humain le lit comme ceci : « Nous nous sommes tous réunis et avons écrit qu'est-ce qui ne va pas chez toi." Et c'est tout. Après cela, toute tentative de Les « commentaires constructifs » ressemblent à une audience au tribunal. Tu voulais un outil de développement et un tribunal collectif.

Nous nous sommes honnêtement demandé : qu’essayons-nous réellement de faire avec cette pratique ? Cela discipline le format, oui, mais cela détruit la confiance.

De la vie, cela ressemble à ceci. Un rapport arrive à une personne, où il y a trois des phrases « tout va bien » et deux toiles négatives. Et le cerveau, bien sûr, se souvient plus clairement des deux marques négatives que des trois positives. "pas bien". Parce que c'est ainsi que s'organise l'attention : ça fait mal, donc c'est important ! Et à partir de ce moment-là, la personne s'oriente vers l'autodéfense plutôt que vers le développement. Ils commencer à prouver le contraire, ou que "c'était le contexte", ou que "vous n'êtes pas non plus des saints". Et à ce moment, 360 se transforme en un rituel où chacun comme s'ils voulaient du bien, mais cela s'est avéré comme d'habitude.

2. Deuxième point. L'anonymat dans une petite équipe est une auto-illusion

Il existe un conte de fées familier en matière de gestion : « Les commentaires anonymes suppriment la peur ». Anonymat? Vraiment? Dans de petites équipes de projet ? En réalité, cela signifie presque toujours « Je vais deviner qui a écrit ça ! ».

Une personne reçoit plusieurs remarques désagréables, puis vient à la prochaine réunion de projet où ces mêmes 3 à 5 personnes sont assises. Ils ne pensent pas au « développement organisationnel ». Ils pensent : « Quel c'était l'un de vous ?" Et cela déclenche un processus très toxique : tout le monde reste extérieurement poli, mais en dessous se cache une couche de méfiance.

Cela n’explose pas toujours en conflit ouvert. C'est simplement rend l'équipe plus froide. Moins cohérent. Moins disposé à aider. Et puis on se demande pourquoi les gens ne partagent pas leurs problèmes "dans les premiers stades". Mais parce qu'ils le sont déjà une fois partagé - et il leur est revenu de manière anonyme une liste de réclamations.

3. Dès que 360 ​​affecte les décisions de promotion, les jeux commencent

C'était là la chose la plus intéressante. Et le plus triste.

Lors d'une de nos discussions de coordination, nous avons remarqué quelque chose d'étrange. Une personne peut être polie, solidaire et avec qui il est facile de travailler lors des appels. Au sein de l’équipe, ils peuvent ressembler à des amoureux absolus. Et puis vous leur remettez un questionnaire "anonyme" où ils peuvent "évaluer les autres", et soudain le score baisse ou les critiques deviennent excessives. Nous avons constaté cet effet nous-mêmes. Cela allait directement à l’encontre de l’intégrité.

Imaginez la situation. Vous dites à l'équipe : "Les notes à 360° comptent pour promotion." Et dans la même seconde, vous transformez une partie du équipe en joueurs, pas en collègues. Parce que si le bouton « influence » apparaît dans le système, quelqu'un appuiera dessus. Pas toujours du mal. Parfois juste en ressentant injustice ("et pourquoi est-il promu, il l'est..."). Parfois de la compétition. Parfois parce que « c’est ainsi que le monde fonctionne ». Et à ce moment-là tu as obtenu ce que tu voulais éviter : la politique, les jeux, les notes « juste au cas où ».

C'est d'ailleurs l'une des raisons pour lesquelles de nombreux chercheurs et il est conseillé aux praticiens de partager leurs commentaires pour le développement et les décisions administratives (argent, notes, promotion). La CIPD le dit sans détour : parler de il est préférable de séparer les évaluations/décisions administratives des conversations, où des commentaires sont donnés à des fins de développement. Voici un PDF de leur examen des preuves (résumé de la pratique) : www.cipd.org/...​e-review_tcm18-111378.pdf

4. Point quatre (notre perspicacité douloureuse). 360 remplace souvent le travail du manager

Après plusieurs cycles, nous nous sommes retrouvés avec une phrase qui sonnait d’abord comme une insulte puis comme la vérité.

Si un manager a besoin d'une vision à 360° pour comprendre comment les gens travaillent et où sont les problèmes, ce manager ne dispose pas d’un système de signaux observables. Il n'y a pas de métrique. Il n'y a pas conversations régulières. Il n'y a pas de rythme. Ou tout cela existe "quelque part", mais n'est pas réellement utilisé.

Et 360 devient une béquille : « on va maintenant récupérer le questionnaire et enfin nous apprendrons la vérité." Et puis vous ne comprenez pas la "vérité" et une image émotionnelle, multipliée par l'anonymat, les conjectures et les jeux politiques.

Pour garder cela fondé, j'ajouterai une référence.

Il existe une étude sur les retours multisources. Sa conclusion est en substance : « ne vous attendez pas à de la magie ». Dans une méta-analyse de 24 études longitudinales, Smither, London et Riley écrivent cette amélioration après Le feedback à 360° est généralement modeste et vous ne devriez pas vous attendre à un grand "mise à niveau de masse" après une vague de retours. Les chances d'amélioration augmentent lorsqu'une personne perçoit un réel besoin de changement, accepte les commentaires, croit qu'il peut changer, fixe des objectifs concrets, et fait réellement quelque chose, au lieu de simplement "lire un PDF et passer à autre chose." Voici le texte lui-même (PDF) : www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

D'accord, nous avons supprimé 360. Qu'est-ce qui l'a remplacé ?

Nous avons arrêté de mesurer les gens en fonction du nombre de billets

Un ticket peut contenir une semaine de recherche, une décision difficile, dix appels et seulement 20 lignes de code. Dans un autre, 50 fonctionnalités réellement issues d'une seule exécution de l'agent IA dans 20 minutes.

Si vous mesurez uniquement les billets, vous mesurez en réalité comment votre processus réduit le travail en morceaux

C'est pourquoi nous avons modifié la question. La meilleure question est devenue : Qu'est-ce qui a été livré, quelle valeur cela a-t-il créé, quelle était la qualité, était-ce prévisible et les statuts étaient-ils honnêtes ?

Comment nous avons défini le « résultat » sans théâtre de gestion

Nous avons convergé vers un cadre simple.

Un résultat est obtenu lorsque la valeur est apportée, la qualité est acceptable, l'équipe est prévisible et les progrès sont transparents.

La valeur n'est pas "le code est écrit". C'est "l'utilisateur ou le client a obtenu un meilleur résultat" ou "c'est devenu plus facile pour l'équipe pour soutenir le système ».

La qualité n'est pas "J'aime ton code". Ce sont des conséquences : bugs dans le produit, incidents, révisions.

La prévisibilité ne signifie pas « nous y parvenons toujours ». C'est : « nous comprenons honnêtement pour quoi nous avons du temps et ce pour quoi nous n'en avons pas, et nous ne nous mentons pas à ce sujet."

La transparence, c'est lorsque « presque terminé » ne se transforme pas en philosophie de vie.

Métrique

Lorsque les gens entendent le mot « métriques », beaucoup souvenez-vous du travailleur légèrement traumatisé par une expérience passée : celui qui a été frappé à la tête avec des chiffres.

Les mesures ne doivent pas être un fouet. Ce devraient être des lunettes. Sans eux, un manager est souvent aveugle. Et lorsque le manager devient aveugle, il se met à rechercher « l'objectivité » dans les questionnaires. Eh bien, vous l'avez.

Nous avons laissé les métriques au niveau de l'équipe, car la plupart des problèmes sont systémiques ! Et si nous voulons corriger le processus au lieu de chercher à blâmer, alors nous devons mesurer le processus !

Honnêtement, nous n’avons rien inventé ici. DORA (DevOps Research and Assessment) promeut déjà une approche très pratique ensemble de mesures de livraison : à quelle vitesse vous apportez le changement et combien les échecs sont douloureux lorsque les changements tournent mal. Voici leur guide rapide : dora.dev/guides/dora-metrics.

Il y a aussi une remarque importante que je voudrais préciser sur le mur à tous ceux qui ont déjà voulu créer des métriques KPI : "ne faites pas de la métrique l'objectif" ! Parce que dès que vous dites "nous devons déployer N fois par jour", une partie du l'équipe commence à déployer un nombre au lieu d'une valeur. C'est l'ancien histoire selon laquelle une fois qu'une métrique devient l'objectif, elle cesse d'être un indicateur. DORA fait explicitement référence à la loi de Goodhart et décrit les pièges typiques. Voici la page sur les "quatre/cinq clés" en termes simples : dora.dev/...​s/dora-metrics-four-keys

Et encore une chose importante sur laquelle DORA met habituellement l’accent : le contexte est important. Ces mesures sont mieux visualisées dans un équipe ou service et au fil du temps, non pas en comparant une application mobile avec un mainframe, ou une petite équipe avec une plateforme pour 200 personnes.

Si vous n’êtes pas une équipe technique, la logique est la même. Au lieu de « déployer », vous avez peut-être « le client a accepté le résultat » ; au lieu de « incident », vous pouvez avoir une « escalade » ; au lieu de "rollback", "rework après alignement". Le point est toujours le même : à quelle vitesse nous déplaçons la valeur à travers le système et combien l'erreur nous coûte.

Et maintenant – le très important « ne fais pas ça ». Ne convertissez pas ces métriques en KPI individuels ! Parce qu’alors les gens commencent à optimiser le nombre au lieu d’améliorer le produit. KPI sur les "déploiements", et du coup vous avez des déploiements pour le plaisir des déploiements. KPI sur le "temps de cycle", et les tâches sont décomposées jusqu'à l'absurdité juste pour "les fermer rapidement", tandis que les parties difficiles disparaissent tranquillement dans l'ombre. KPI sur les « incidents », et les incidents commencent à être renommés « particularités » ou « scénarios utilisateur inattendus ».

La première chose qui nous a aidé a été la prévisibilité. Simple question : qu'avons-nous promis lors de la planification et ce qui a été réellement donné. Pas par honte. Pour comprendre. Parce que si vous promettez constamment 10 et en faites 6, alors le problème ne vient pas des "gens paresseux". Le problème est dans l'estimation, priorités, WIP, bloqueurs, changement de contexte. Autrement dit, en gestion.

Le deuxième est le délai de livraison. Combien de temps prend la tâche ? sur le chemin de « mis au travail » à « effectivement livré ». Cela donne à réfléchir. Parce qu'il s'avère souvent que nous « écrivons du code » rapidement, mais « livrons » lentement. Et puis vous pouvez voir où se situe le goulot d'étranglement : révision, tests, libération, réconciliation, dépendances.

Le troisième est WIP. Si l'équipe est "au travail" en même temps dix problèmes à la fois, alors personne ne fait vraiment rien. Plus précisément, tout le monde fait tout en même temps. Et puis nous nous demandons pourquoi le progrès semble lent et nerveux. Quand le cerveau s'étale en une fine couche sur dix tâches, il ne devient pas plus productif. Cela devient juste plus fatigué.

Une autre chose qui nous a aidé à réfléchir plus clairement est la suivante : si vous voulez que le travail avance plus rapidement dans le système, la réponse est souvent de ne pas insister davantage sur les gens. Il s’agit de réduire la taille des lots. Les modifications mineures sont plus faciles à examiner, tester, publier et annuler. DORA fait directement le même argument : des lots plus petits améliorent généralement à la fois la vitesse et la stabilité. Cela semble évident jusqu’à ce qu’une équipe essaie de vivre selon cela pendant un mois.

Qualité : nous avons arrêté de discuter "il me semble" et avons commencé à regarder les conséquences

Évaluer la « qualité » avec des questionnaires est une mauvaise idée. Parce que la « qualité » dans le questionnaire, il est souvent question de sympathie, de style et de goût.

Nous sommes passés aux conséquences.

Combien de défauts ont atteint la production. À quel point étaient-ils sérieux ? Comment la tendance évolue-t-elle ?

Combien d’incidents avons-nous eu. Combien de temps nous a-t-il fallu pour récupérer ? Les mêmes raisons se répètent-elles ?

Combien de révisions. Combien de tâches ont été « transmises » puis renvoyées. Parce que « prêt » s’est avéré ne pas être prêt.

Vous ne vous disputez plus pour savoir « qui est le meilleur ». Vous voyez ce qui se passe réellement avec le produit.

Une conclusion contre-intuitive : pourquoi évaluer une personne ?

Plus nous creusions, plus nous tombions souvent sur une question étrange.

Pourquoi évaluons-nous une personne ? Refuser une promotion ? Pour montrer qui est la « star » ? Pour comparer les gens ?

Et quand nous en avons parlé honnêtement, il s'est avéré que la plupart de nos besoins réels ne concernaient pas le classement personnes. Ils portaient sur la performance de l'équipe : faisons-nous quoi nous l'avons promis, la qualité est-elle bonne, le travail est-il prévisible, sommes-nous épuisés et le client obtient-il ce que ils s'attendent ?

Autrement dit, à propos du système.

Et si c'est le cas, alors le premier objet de l'évaluation est l'équipe et le processus. Et pas une personne comme cible.

L'équipe est sous-performante, nous examinons donc l'ensemble chaîne : embauche, intégration, définition des tâches, planification, révision, tests, versions, communication, dépendances. C'est du point de vue de la gestion plus dur, oui. Mais c'est plus honnête.

Parfois, cela semble très terre-à-terre. Par exemple, quand "nous n'avons plus eu le temps", la première question n'est pas "qui ralentit", et "où le temps a-t-il disparu". Parce que le temps peut disparaître en attente : les tâches restent inactives en révision, en attente de test, bloqué par accord, ou il y en a tout simplement trop en parallèle.

Quand quelqu’un a des difficultés, ce que nous vérifions en premier

Nous voyons aussi parfois des situations où quelqu'un « ne tire pas ». Mais au lieu d’un questionnaire, nous faisons un simple diagnostic.

Ce problème a-t-il toujours existé ? Si c'est le cas, le problème est probablement lors de l'embauche ou de l'intégration. Dans ce cas, vous corrigez le processus d'embauche, pas la personne avec les questionnaires.

Était-ce normal avant et puis ça a empiré ? Alors cela peut être le contexte : burn-out, changement de tâches, conflit de rôles, circonstances personnelles. C'est la zone de travail normal de gestion : découvrir ce qui s'est passé, réduire la charge, aider la personne à retrouver contrôlez et élaborez un court plan de récupération de 2 à 4 semaines.

La personne comprend-elle clairement ce qu’est le succès à quoi ça ressemble dans un futur proche ? Parce que souvent le problème n'est pas que la personne est « faible ». C'est qu'on les a placés dans le brouillard et j'IA appelé cela des attentes.

Et encore une nuance que nous avions également. Si une personne échoué plusieurs fois, le manager peut parfois relever subjectivement bar : "prouvez maintenant que vous n'êtes pas un échec." Cela fonctionne souvent à un niveau subconscient et cela fonctionne mal pour l'équipe. Il est généralement préférable de faire le contraire : réduire la portée, réduire les tâches, supprimer le bruit, donner à une personne une chance de bien faire certaines choses de manière constante et reprendre confiance en soi. C'est une tâche difficile pour gestionnaires. Et c'est exactement pourquoi nous regardons de très près chez les managers que nous embauchons.

Conclusions

Bien sûr, le 360 ​​peut fonctionner. Dans les grandes entreprises, où l’anonymat est réellement possible.

Lorsque l'équipe a déjà une culture de feedback direct, et 360 est un signal supplémentaire, pas le principal "vérité".

Nous n'avions pas cela. Nous avions de petites équipes, un rythme rapide et un coût élevé de méfiance.

Le 360 ​​​​ressemblait à un outil pour adultes sur le papier. Dans notre En réalité, c'est devenu un mécanisme qui rassemble la peur en un seul endroit, conjectures, compétition et « jugement collectif ».

Nous avons supprimé 360 et sommes revenus à l'essentiel : des mesures d'équipe simples, des conversations ouvertes et des statuts transparents.

Matériel et liens (si vous souhaitez approfondir)

DORA, software delivery performance metrics. Une explication fondée des cinq mesures et des pièges dans lesquels tombent les équipes lorsqu'elles les utilisent à mauvais escient.

DORA, DORA’s software delivery performance metrics. Version courte avec historique "pourquoi quatre/cinq" et un avertissement concernant les jeux avec des métriques.

DORA Research: 2024, DORA Report. Rapport complet (télécharger le PDF en plusieurs langues).

Smither, London (2005), meta-analysis on multisource feedback. Pourquoi il ne faut pas s'attendre à un effet magique d'une seule vague à 360°.

CIPD, Performance feedback: an evidence review (PDF). Sur la manière dont le feedback fonctionne/ne fonctionne pas et pourquoi confondre « évaluation » et « développement » est souvent préjudiciable.

CCL, 360 Degree Assessment & Feedback: Best Practices Guidelines. Si vous faites quand même un 360, il y a quelque chose à penser avant le départ, pas après l'incendie.

CCL, SBI feedback model. Un cadre très simple pour des commentaires « sans raccourcis ».

Google SRE, Postmortem Culture: Learning from Failure. Sur des post-mortems irréprochables et pourquoi faire honte à la culture tue l’apprentissage.

Amy Edmondson (1999), Psychological Safety (PDF). Source primaire sur la sécurité psychologique dans les équipes.

WEF, Feedforward technique. Sur la façon d'orienter les commentaires vers « ce que nous ferons ensuite » et non vers « ce qui s'est passé hier ».

Goodhart’s law. L'une des « anti-théories » les plus utiles pour tous ceux qui souhaitent créer des métriques KPI.

Questions pour la communauté

Que pense la communauté du 360 ? L'utilisez-vous ? Quelle a été votre expérience ?

Comment résoudre le problème de « l’anonymat » quand l’équipe est petite et que tout le monde comprend tout ?

Et quelles mesures de livraison/qualité vous aident réellement à gérer le processus plutôt que de rédiger de jolis rapports ?

Merci pour votre temps et votre attention.