Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Primes d'Encouragement Jugées Nocives


Par Joël Spolsky
Traduit par Gilles Mantel
Vérifié par Boris Fontaine
3 Avril 2000

Mike Murray, un DRH de Microsoft étonnamment malchanceux, fit un certain nombres de gaffes, mais la plus notoire fut celle de lancer un programme de récompense «Ship It» (NDT: «Livrez la marchandise») peu après être entré en fonctions. Son intention, c'était de préparer une sorte de grosse pierre tombale translucide de la taille d'un dictionnaire à tous ceux dont le logiciel allait franchir le quai d'expédition. C'était supposé en quelque sorte vous inciter à travailler, voyez-vous, parce que si vous ne faisiez pas votre boulot, alors pas de récompense pour vous! C'est à se demander comment Microsoft n'a-t-elle jamais livré du logiciel avant la venue du pavé translucide.

Le programme «Ship It» fut annoncé à l'interne en grande pompe et avec grand émoi à l'occasion d'un pique-nique de la société. Plusieurs semaines avant l'événement, des affiches énigmatiques apparurent partout sur le campus de l'entreprise avec une image de Bill Gates et les mots «Pourquoi cet homme sourit-il?». Je ne suis pas sûr de ce que ça voulait dire. Est-ce que Bill souriait parce qu'il était content de savoir désormais comment inciter ses employer à livrer sa marchandise? Mais au pique-nique de la société il devint évident que les employés se sentaient traités comme des enfants. Il y eut beaucoup de huées. L'équipe de programmation d'Excel brandit un panneau énorme qui demandait «Pourquoi l'équipe Excel baille-t-elle?». Le trophée «Ship It» fut tellement décrié qu'il y a même un épisode (réel) dans le classique Microserfs de Douglas Coupland dans lequel un groupe de programmeur essaye de le détruire au chalumeau.

Il n'est pas rare de voir des sociétés traiter les cerveaux comme s'ils étaient encore au jardin d'enfants. En effet, presque toutes les entreprises ont mise sur pied une sorte de programme d'encouragement qui est insultant et dégradant.

Dans les deux sociétés pour lesquelles j'ai travaillé, les moments les plus stressants de l'année étaient les remises de bilans semestriels de performance. Pour une raison ou pour une autre, le département RH de Juno et celui de Microsoft ont dû copier leur système de bilan des performances du même livre de management Dilbertesque, parce que les deux programmes fonctionnaient de façon identique. D'abord, vous remplissiez une évaluation patronale «anonyme» de votre superviseur (comme si ça pouvait être fait honnêtement). Ensuite, vous remplissiez des formulaires optionnels d' «auto-évaluation», que votre superviseur «tenait compte» en préparant le bilan des performances. Au final, on y comptait beaucoup d'impondérables tels que «travaille bien avec les autres» pour lesquels vous obteniez un score chiffré, de 1 à 5, qui ne pouvait vraisemblablement être qu'un 3 ou un 4. Les superviseurs soumettaient leurs recommandations de primes à la hiérarchie, lesquelles étaient totalement ignorées et chacun recevait des primes qui étaient presque complètement aléatoires. Le système n'a jamais tenu compte des talents différents et uniques que les gens peuvent avoir et sans lesquels une équipe ne peut pas bien fonctionner.

Les bilans de performance étaient stressants pour deux ou trois raisons. Plusieurs de mes amis, surtout ceux dont le talent était très significatif mais n'apparaissait pas sur l'échelle traditionnelle, avaient tendance à obtenir des évaluations de performance médiocre. Par exemple, l'un de mes amis était un joyeux catalyseur, un capitaine de navire sautillant qui motivait tous les autres lorsque la traversée devenait difficile. Il était le lien qui tenait l'équipe ensemble. Mais il avait tendance à obtenir des évaluations négatives parce que son superviseur ne comprenait pas sa contribution. Un autre ami était incroyablement visionnaire au niveau stratégique. En effet, ses conversations avec les autres à propos de la manière de faire les choses permettaient à chacun de réaliser un bien meilleur travail. Il avait tendance à passer plus de temps que la moyenne à éprouver les nouvelles technologies ; dans ce domaine il était inestimable pour le reste de l'équipe. Mais en termes de lignes de code, il écrivait moins que la moyenne, et son superviseur était trop stupide pour s'apercevoir de toutes ses autres contributions. C'est pourquoi il obtenait toujours, lui aussi, des évaluations négatives. Evidemment, les évaluations négatives ont un effet dévastateur sur le moral. En fait, donner à quelqu'un un bilan qui est positif, mais pas aussi positif qu'il l'espérait a aussi un effet négatif sur le moral.  

L'effet des évaluations sur le moral est disymétrique : alors que les évaluations négatives affectent beaucoup le moral, les évaluations positives ne renforcent aucunement le moral ou la productivité. Ceux qui les obtiennent ces dernières travaillent déjà de manière productive. Pour eux, une évaluation positive leur donne en fait l'impression qu'ils travaillaient bien pour pouvoir obtenir une évaluation positive... comme s'ils étaient des chiens de Pavlov travaillant pour une récompense, au lieu de professionnels qui se préoccupent en fait de la qualité du travail qu'ils font. 

Et c'est là que se trouve le hic. La plupart des gens pensent qu'ils font de l'assez bon boulot (même si c'est faux). C'est juste un petit tour que notre esprit nous joue pour que la vie reste supportable. Donc si chacun pense qu'il fait du bon boulot, et que les bilans sont simplement corrects (ce qui n'est déjà pas facile à réaliser), alors la plupart des gens seront déçus par leur évaluation. Le coût sur le moral est difficile à minimiser. Dans des équipes où les évaluations de performance sont faites honnêtement, elles tendent à résulter en une semaine environ de déprime, de cafard, et de résignation. Elles tendent à dresser des barrières entre les membres de l'équipe, souvent parce que les mal-notés sont jaloux des bien-notés, dans un processus que DeMarco et Lister appellent «teamicide» (NDT: «groupicide») : la destruction par inadvertance d'une équipe soudée.

Alfie Kohn, dans un article du désormais classique Harvard Business Review, écrit:

... au moins deux douzaines d'études sur les 30 dernières années ont montré de façon concluante que les personnes qui espéraient recevoir une récompense pour achever une tâche ou pour faire que cette tâche soit un succès n'ont simplement pas autant réussit que ceux qui n'espéraient aucune récompense. [HBR Sept/Oct 93]

Il conclut que «sur le marché du travail, les incitatifs (ou les pots-de-vin) sont tout simplement sans effets sur la productivité». DeMarco et Lister vont plus loin, déclarant de façon non équivoque qu'au travail, toute mise sur pied d'un programme de compétition ou de récompenses et punitions, y compris la vieille astuce de «surprendre les gens en train de faire quelque chose de bien et les récompenser», amène plus de mal que de bien. Donner à quelqu'un un renforcement positif (comme on le fait aux cérémonies stupides de sociétés où l'on distribue des trophées ) donne l'impression qu'il l'a seulement fait pour la plaque translucide et qu'il n'est pas assez indépendant pour travailler sans incitatif de gratification égocentrique. Et c'est insultant et dégradant en plus.

La plupart des gestionaires en développement de logiciel n'ont pas le choix et doivent composer avec les systèmes de bilan des performances qui sont déjà en place. Si c'est votre cas, la seule façon d'éviter le groupicide est de donner à chaque membre de votre équipe un bilan élogieux. Mais si vous avez vraiment le choix, je vous recommanderais de fuir loin de tout bilan de performance, prime d'encouragement, ou programme stupide d'employé du mois.



Cet article est paru en version originale anglaise sous le titre Incentive Pay Considered Harmful  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky