Une traduction de l'article Why Don't They Trust Us? rédigé par John Cutler et publié sur Hackernoon.

Pourquoi ne nous font-ils pas confiance ?

Êtes-vous déjà allé dans votre restaurant favori, ne pas lire le menu et demander au Chef de vous surprendre ? Que vaut votre confiance au Chef ? Réfléchissez à la façon dont vous faites des affaires avec un charpentier, un plombier ou un garagiste à qui vous faites confiance. J'adore mon garagiste. Je lui donne carte blanche pour faire ce qui est nécessaire pour maximiser le retour sur investissement de mon véhicule et nous garder, ma famille et moi, en sécurité. Il me fait confiance pour payer.

Maintenant, imaginez que vous organiser un mariage. Vous rencontrez un traiteur (ou un photographe) qui veut faire affaire avec vous. C'est la première fois que vous les rencontrez (ou que vous goûtez leurs mets). Leur demandez-vous de vous suprendre ? Ou avec un nouveau garagiste… lui demandez-vous de réparer tout ce qui lui semble nécessaire tant qu'il y est ? Je parie que dans ces cas, la réponse est Non.

Alors, allons droit au but. La plupart des équipes de développement logiciel ne sont pas (entièrement) dignes de confiance pour livrer un résultat haut de gamme ou pour résoudre un problème. Je le dis sans jugement de valeur. Un synonyme de méfiance est le manque de confiance, qui est un terme plus acceptable à dire à haute voix. Pourquoi manque-t-on parfois de confiance dans la capacité d'une équipe à fournir un résultat haut de gamme ?

• Contexte et Jugement : Préoccupés par le fait qu'ils n'ont pas tout le contexte nécessaire. Ils n'ont pas entièrement confiance en leur jugement quant à la solution. Ils craignent de ne pas solliciter d'aide, de ne pas poser les bonnes questions ou de ne pas informer les autres de leurs intentions. Le fait de penser que nous savons mieux que quiconque, ou que notre idée personnelle est meilleure.
• Preuve : Nous n'avons pas constaté qu'ils génèrent des résultats fructueux. Ou plus généralement, nous n'avons pas observé de tendance à tenir les promesses de façon fiable.
• Égoisme : Un sentiment présumé de son intérêt personnel (“ils n'ont pas mes besoins en tête”). Un sentiment perçu d'indifférence (“Je ne suis pas sûr que leur cœur y soit”).
• Risque : Nous avons peur d'être sanctionnés à cause des mauvaises décisions de l'équipe. Les enjeux sont élevés et nous ne pouvons pas nous permettre d'être dans le noir ! Nous avons besoin que cela soit parfait ou nous ne pouvons pas nous permettre que cela tourne mal.
• Cohérence : Le résultat est trop lointain ! Il n'y a aucun moyen de mesurer le progrès, donc la seule alternative est de s'entendre sur des solutions prescriptives et de mesurer les accomplissements (en tant que mesure du succès).

Note : Nous sommes tous victimes d'un biais fondamental d'attribution par lequel nous avons tendance à sous-évaluer les causes externes (situations, évènements extérieurs), et de préférer blâmer les autres personnes. Et nous manquons peut-être nous-mêmes d'expérience.

Alors pourquoi, dans le développement logiciel interne, voit-on la dynamique du nouveau garagiste, ou pis celle du garagiste duquel on se méfie mais avec lequel on doit travailler prendre place ? Les relations de travail ne devraient-elles pas plutôt ressembler à celle du garagiste familial ou du Chef de notre restaurant favori ? D'ailleurs la méfiance s'installe dans les deux sens… toutes les charges émises ci-dessus peuvent être prises dans l'autre sens pour décrire ce que ressent l'équipe face aux personnes qui les dirigent ou les gèrent.

Au lieu d'une analogie client/fournisseur de services, considérons une équipe bien rodée de charpentiers (une situation de partenariat). Que fait le charpentier en chef lorsqu'un apprenti n'est pas digne de confiance pour effectuer un certain travail ? Le charpentier en chef binôme, enseigne, entraîne et conseille. L'apprenti accepte cette aide. Bingo !

Pourquoi cela fonctionne-t-il ? Voyons ce que dit l'algorithme de confiance de Larry Maccherone :

Confiance = (Crédibilité + Fiabilité + Empathie) / Égoisme apparent

tels que…

• Crédibilité = À quel point vous savez vraiment de quoi vous parlez
• Fiabilité = À quelles fréquences et vitesses vous faites ce que vous dites
• Empathie = À quel point vous montrez de la préoccupation aux intérêts des autres
• Égoisme apparent = À quel point vos paroles et actions qui vont dans votre propre intérêt sont-ils apparents ?

Dans l'exemple de nos charpentiers, les charpentiers ont de la crédibilité, ils montrent un intérét au succès des apprentis, et ils offrent de l'aide si nécessaire de façon fiable.

Maintenant voyons une dynamique classique dans le monde du développement logiciel.

• Le chef de projet ne comprend pas le développement logiciel. Le patron comprend une version vieille de 20 ans du développement logiciel appartenant à un autre domaine et rejette de temps en temps les décisions de l'équipe aléatoirement et sans vraie raison. Les membres de l'équipe ne comprennent pas les aspects commerciaux. Seuls les designers comprennent le design. (Crédibilité, Fiabilité, Empathie)
• L'équipe a été paralysé par la dette technique. (Fiabilité, Crédibilité)
• La direction n'a pas offert de ressources pour aider à alléger la dette. (Fiabilité, Égoisme apparent, Crédibilité)
• La direction ne comprend pas la complexité de ce défi technologique particulier et continue de demander à l'équipe de se porter garant. (Crédibilité, Empathie, Égoisme apparent)
• L'équipe n'a pas certaines des facultés nécessaires pour cet effort particulier, ainsi ses membres vont opter pour une technologie plus simple mais moins optimale qui finit par se retourner contre eux. (Crédibilité, Fiabilité, Égoisme apparent)
• Un membre de l'équipe s'approprie tout le travail intéressant pour parfaire son CV (Crédibilité, Égoisme apparent)
• Le chef de projet ne semble pas disposé à admettre les faux pas. (Égoisme apparent, Empathie, Fiabilité, Crédibilité)
• Quelqu'un décide d'utiliser la mesure de la vitesse de développement des fonctionnalités comme indicateur de progrès (Crédibilité, Empathie)

Je pourrais continuer encore et encore. Vous avez l'idée. Vous voyez comme il est simple de semer la méfiance ? Une partie du problème est purement systémique. Par exemple, dans un environnement optimisé pour multiplier les travaux en cours, vous trouvez toutes sortes de comportements qui ne paraissent pas dignes de confiance :

Notez les calendriers locaux (local agendas), l'utilisation de shunts pour voir le travail fait (use back channels to get work done), la méfiance (distrust), l'opacité (opacity), le moral en baisse (loss of morale), les raccourcis (cutting corners), … tout peut être facilement mis en rapport avec des soucis d'Empathie, de Fiabilité, de Crédibilité et d'Égoisme apparent.Ça va encore plus loin. Bon nombre de ces questions se résument à ce qu'Amy Edmonson appelle le conflit entre cultures professionnelles :

It seemed that teaming across industry boundaries was really, really  hard. OK, so … We had inadvertently discovered what I call “professional  culture clash” with this project. You know, software engineers and real  estate developers think differently — really differently: different  values, different time frames — time frames is a big one — and different  jargon, different language. And so they don’t always see eye to eye. I  think this is a bigger problem than most of us realize. In fact, I think  professional culture clash is a major barrier to building the future  that we aspire to build.

Il paraissait que collaborer malgré les barrières de l'industrie était vraiment dur. Bien, donc... Nous avions découvert accidentellement ce que j'appelle « conflit entre cultures professionnelles » via ce projet. Les informaticiens et les promoteurs pensent différemment — vraiment différemment : des valeurs et des emplois du temps différents — celle-ci est majeure — et un jargon différent, un langage différent. Et ils ne sont pas toujours d'accord. Je pense que ceci est un problème plus important que nous le croyons. En fait, je pense que le conflit de cultures professionnelles est une barrière majeure pour le futur que l'on aspire à construire.

Le conflit culturel peut s'étendre aux membres d'une même culture (par exemple les ingénieurs) qui se retrouvent clivés par générations, environnements professionnels précédents, par opinions sur l'individualisme et le collectivisme, … Il y a également l'influence de l'ancienneté… un cadre ingénieur senior est confronté à une dynamique différente (pressions, histoire, …) de celle, disons, d'un nouvel ingénieur tout juste embauché.

Ce sont pour ces raisons que nous pouvons trouver de nombreuses sociétés éditrices de logiciels optimisées pour la méfiance : planification prévisionnelle, missions contraignantes, objectifs au niveau individuel, etc., etc., etc. C'est un vilain problème qui s'auto-alimente. De nombreux procédés sont conçus pour obliger les gens à rendre des comptes (au lieu de produire des résultats) parce qu'il y a un sentiment sous-jacent de manque de responsabilisation. La seule chose (déprimante) qui sauve est que les structures ont tendance à trouver un équilibre médiocre au lieu d'imploser complètement.

Bon et que veut dire tout cela ? Que pouvez-vous faire ? L'optimisation pour éviter la méfiance est une course en avant. D'après mon expérience, nous avons peur de parler ouvertement de confiance (surtout lorsque celle-ci est en défaut). Il peut donc être extrêmement difficile de s'attaquer de front à ce problème. Le biais fondamental d'attribution nous fait également tendre à surestimer les causes personnelles au détriment de causes systémiques.

La clef, me semble-t-il, est de créer des situations sécurisantes dans lesquelles les équipes interfonctionnelles (couvrant plusieurs cultures) peuvent 1) développer de l'Empathie, de la Crédibilité et faire émerger un intérêt collectif, et 2) tenir leurs promesses les uns envers les autres (et envers leur entreprise) pour la Fiabilité. Le reste de l'entreprise, en retour, doit remplir sa part du marché, pour éviter le stéréotype qui veut que les équipes doivent d'abord prouver qu'elles peuvent livrer un produit de haute qualité avant qu'on puisse leur faire confiance (ce qui réduit la crédibilité et l'empathie dés le départ).

Au lieu de favoriser les communautarismes culturels… faites le pari de favoriser leurs intégrations. Ce sera difficile à court termes, comme l'explique Bob Putnam, professeur de politique publique à l'Université de Harvard, dans un épisode fascinant de Freakonomics au sujet de la confiance :

In the short run, increases in diversity seem to be correlated with decreases in social capital. Diversity, in the long-run, is a big advantage.

À court terme, l'augmentation de la diversité semble être corrélée à la diminution de capital social. La diversité, à long terme, est un gros avantage.

En gros… travailler avec l'algorithme de confiance de Larry. C'est la raison pour laquelle je suis si passionné par le fait de démarrer ensemble (Starting Together)… cela met les gens sur un pied d'égalité lorsqu'ils sont confrontés à un problème tous ensemble. Une fois cela acquis, les équipes peuvent progressivement se concentrer d'avantage sur les réalisations à mesure que le niveau de confiance collective augmente. Vous aurez besoin de contraintes, mais avec le temps elles deviendront plus implicites et moins explicites.

Et PS : vous rencontrerez toujours quelqu'un pour vous parler de “la vraie vie”.

[illustration par John Cutler]