Les données leur donnaient raison. Au début.

Ce qu'on nous a dit

On nous avait dit qu'un ingénieur était sous-performant.

Les préoccupations venaient de la direction produit et de la direction technique.

Cet ingénieur était décrit comme quelqu’un qui mettait trop de temps à livrer, remettait en question les décisions trop souvent, et perturbait l’harmonie de l’équipe.

L’organisation envisageait de retirer cet ingénieur de l’équipe.

Les preuves semblaient sans équivoque.

Entre le moment où le travail était assigné dans GitHub et l’ouverture d’une pull request, cet ingénieur mettait souvent plus de temps que nous ne l’aurions attendu pour l’implémentation elle-même.

Selon cette mesure, cet ingénieur était effectivement plus lent.

Ce que nous avons observé

GitHub montrait le temps écoulé.

Il ne montrait pas ce que faisait l’ingénieur pendant ce temps.

Nous avons donc suivi le travail jusque dans Slack.

Après avoir reçu une demande, l’ingénieur demandait fréquemment pourquoi une spécification donnée existait, quel problème elle était censée résoudre, ou si une implémentation différente atteindrait mieux le même objectif.

Ce n'étaient pas des objections arbitraires.

C'étaient des tentatives de comprendre le contexte de l'exigence ou de proposer une alternative avant le début de l'implémentation.

Le product owner considérait généralement ces questions et propositions comme inutiles.

Lorsqu'une proposition était rejetée, l'ingénieur commençait immédiatement l'implémentation.

Lorsqu'une question ou une proposition restait sans réponse, l'ingénieur n'attendait pas indéfiniment.

Au bout de trois jours ouvrés, l'ingénieur indiquait qu'aucune réponse n'avait été reçue et que l'implémentation se poursuivrait sur la base de la demande d'origine.

C'est seulement alors que le travail de codage commençait.

Le schéma

L'organisation mesurait la totalité du temps entre l'assignation et la livraison comme du temps d'exécution en ingénierie.

Mais une part significative de ce temps était consacrée à des activités antérieures à l'implémentation.

L'ingénieur cherchait à clarifier l'intention, à remettre en question des hypothèses, ou à proposer une alternative.

Ces activités n'étaient pas comptées comme du travail utile.

Elles étaient interprétées comme un retard.

Cette interprétation façonnait également la réputation de l'ingénieur.

Poser des questions ressemblait à de la résistance.

Proposer des alternatives ressemblait à un refus de suivre les instructions.

Attendre une décision produit restée sans réponse ressemblait à une implémentation lente.

Le même comportement servait donc de preuve à plusieurs jugements négatifs sur cette personne.

Puis nous avons trouvé un autre signal

Certaines des propositions rejetées ou ignorées de l'ingénieur n'ont pas disparu.

Après la mise en production de l’implémentation d’origine, le product owner redemandait parfois la même idée lors d’un sprint ultérieur.

La proposition auparavant jugée inutile pouvait ensuite revenir sous la forme d’une exigence officielle.

Cela comptait.

Cela montrait que les questions et les propositions alternatives de l'ingénieur n'étaient pas de la simple obstruction.

Au moins certaines d'entre elles identifiaient des améliorations que l'organisation produit finirait de toute façon par vouloir.

Notre hypothèse

L'ingénieur ne souffrait pas, avant tout, d'un problème de compétence.

L'organisation avait créé un environnement dans lequel un seul type de comportement en ingénierie était récompensé au-dessus de tous les autres :

Exécuter l'instruction telle qu'elle a été donnée.

Remettre en question la spécification créait du retard.

Suggérer une alternative créait des frictions.

Attendre une clarification augmentait le lead time mesuré.

Dans cette perspective, un ingénieur qui cherchait à améliorer le travail avant de l'implémenter pouvait sembler moins productif qu'un ingénieur qui se mettait simplement à coder immédiatement.

Le système ne se contentait pas de mesurer la vitesse de livraison.

Il récompensait indirectement l'obéissance aux instructions.

Pourquoi le diagnostic initial semblait convaincant

Le jugement initial ne reposait pas sur des données imaginaires.

Le temps écoulé était bel et bien plus long.

C’est ce qui rendait ce cas intéressant.

Une seule source de preuve soutenait la conclusion de l'organisation.

Si nous nous étions arrêtés à GitHub, nous serions parvenus à la même conclusion.

Mais l'indicateur ne répondait qu'à une seule question :

Combien de temps s'était écoulé entre l'assignation et la livraison ?

Il ne répondait pas à :

• Quand l'implémentation avait-elle réellement commencé ?
• Que s'était-il passé avant l'implémentation ?
• Qui attendait qui ?
• Quelles décisions restaient en suspens ?
• Quelle valeur était créée en dehors du code lui-même ?

Ce que les faits ont montré

L'ingénieur était plus lent si l'on ne mesurait que le temps de livraison écoulé.

Mais ce chiffre combinait plusieurs types d'activités différentes en un seul indicateur.

Une fois que nous avons séparé l’implémentation de la clarification, de la proposition, de la décision et du temps d’attente, le sens de ce chiffre a changé.

L'organisation avait interprété un schéma d'interaction au niveau du système comme un problème de performance individuelle.

Retirer l'ingénieur n'aurait pas corrigé ce schéma.

Cela n’aurait fait que retirer la personne dont le comportement rendait ce schéma visible.

Les données n'étaient pas fausses. L'interprétation était incomplète.

Le point de vue de Pulsar

Nous ne commençons pas par juger si une personne est bonne ou mauvaise dans son travail.

Nous suivons le travail.

Dans ce cas, GitHub montrait que la livraison prenait plus de temps.

Slack montrait pourquoi.

Des décisions produit ultérieures ont montré qu'une partie du comportement jugé inutile identifiait en réalité une réelle valeur.

Aucune de ces observations, prise isolément, ne racontait toute l'histoire.

Ensemble, elles ont changé le diagnostic.

Nous n'évaluons pas les personnes à partir d'un seul signal. Nous examinons le système qui a produit ce signal.