M: Tu as raison, ça ne marche pas.
C: Euh… Qu’est-ce qui ne marche pas ?
M: La stratégie trouvée en COMEX : on se sépare des mauvais.
C: Sans blague. C’était un 180 cette idée.

M: Un 180 ?
C: Oui. Une idée 100% contre-productive, si tu préfères.
M: Ah oui.
C: Tu sais, quand tu veux aller dans une direction et que tu vas exactement dans la direction opposée.
M: Oui bah ça va, j’ai compris.
C: Un pur effet cobra.
M: Effet cobra ?
C: Je ne sais pas si l’histoire est prouvée, mais voilà : à Delhi, le gouvernement colonial britannique à l’époque, voulant se débarasser des cobras en trop grand nombre, avait décrété une récompense pour chaque cobra mort qu’on lui amenait. Ça n’a pas marché : les habitants se sont mis à élever des cobras. Le gouvernement a supprimé la récompense. Les habitants ont relâché les cobras qu’ils élevaient. Au final la ville s’est retrouvée avec encore plus de cobras.
M: Je vois. S’ils avaient fait un diagramme ils l’auraient vu aussi.
C: Je ne sais pas, mais on peut se prêter à l’exercice. Plus on livre des cobras, plus on obtient de récompenses. Plus il y a de cobras livrés, moins il y a de cobras vivants.

COBRAS LIVRÉS → RÉCOMPENSES
COBRAS VIVANTS → COBRAS LIVRÉS
COBRAS LIVRÉS -⊖→ COBRAS VIVANTS

Le système de récompense incite à créer des élevages, qui permettront de renouveler la population de cobras.

RÉCOMPENSES → ÉLEVAGES
ÉLEVAGES -|D|→ COBRAS VIVANTS

Lorsque la récompense est supprimée, la création d’élevage s’arrête, mais entretemps la population de cobras a augmenté.

système

M: C’est un exemple intéressant, mais quel rapport avec notre politique de performances ?
C: Dans les deux cas, il y a une erreur de raisonnement :

  • On a cru que la récompense diminuerait la population des cobras. Elle a eu l’effet inverse.
  • On croit que la suppression des “mauvais développeurs” va diminuer la quantité de défauts. Elle aura l’effet inverse.

M: Moins de mauvais développeurs ⇒ moins de défauts, c’est logique…
C: Regarde mieux le diagramme qu’on a fait hier. Moins de développeurs ⇒ plus de travail par développeur ⇒ moins de temps pour améliorer. Du reste ce n’est pas seulement une erreur de raisonnement, c’est une erreur d’observation.
M: Comment ça ?
C: Explique moi ce qu’est un mauvais développeur ? Sur quelles observations tu te bases ?
M: Ça existe, les mauvais développeurs figure toi.
C: Je ne le conteste pas. Mais que peux tu observer à propos des “mauvais” développeurs qui les différencie des “bons” ?
M: Oh, un tas de choses…
C: Vous avez un standard qui vous aide à les identifier ?
M: Non, pas vraiment…
C: Vous n’avez pas de standard, mais vous vous apprêtez à sortir les mauvais développeurs.
M: C’est facile de critiquer. Qu’est-ce que tu suggères ?
C: À ta place, j’interrogerais des développeurs et je leur demanderais ce qui leur a permis de progresser dans leur pratique. Je doute qu’il y en ait un·e seul·e qui réponde “mes collègues se faisaient virer”.

Stay tuned !

publié sur Linked In le 04/07/2023