Claude Montpetit -- Montpetit.net -- fr

Une vieille expérience (Hofling et al. 1966) dans un hôpital aux États-Unis, 95% des infirmières ont accepté d'exécuter un ordre d'un médecin inconnu alors même que cet ordre allait à l'encontre de leur bon sens, allant même jusqu'à accepter d'administrer en sur-dose un médicament interdit. Beaucoup d'autres études vont dans le même sens.

Dans autre cas apparemment réel, un médecin traitant un patient pour une infection à l'oreille droite a écrit dans sa recommandation de donner des gouttes "in the R ear" (oreille droite). L'infirmière les a administrées dans le "rear" et ni elle, ni le patient n'ont contesté cette action (extrait d'un livre).

Cela semble indiquer que dans une situation où 2 cerveaux intelligents sont impliqués, si un des deux est dans une position d'autorité claire, le deuxième cerveau est pratiquement hors service.

Si on transpose ça dans le contexte du développement de logiciel, on pourrait en déduire que dans une situation ou un programmeur interagit avec un manager en situation de pouvoir, le programmeur a toutes les chances d'éteindre son cerveau durant l'échange et d'appliquer les décisions du manager sans discuter. À combien de meeting ai-je assisté où on retrouvait 2-3 managers et plusieurs programmeurs? Beaucoup, et dans la plupart des cas, les managers discutaient entre eux et les programmeurs acquiesçaient sous l'influence de l'autorité.

Mais un programmeur avec un cerveau endormi, c'est complètement inutile, à moins qu'on ne s'attende qu'à une job de bras de sa part: coder sans poser de question, ce qui nécessite un design et une analyse impeccable, et un peu de naïveté pour croire que le programmeur va endurer cet état longtemps. Et dans une telle situation, le programmeur peut changer d'emploi, ou espérer monter dans la hiérarchie du pouvoir, ce qui implique dans les deux cas que d'être développeur n'est qu'un passage dans un tel contexte.

Pour maximiser l'utilisation de ses ressources cervicales (ressources principales dans le cas d'une entreprise de développement logiciel), les dirigeants ont tout intérêt à éviter les relations de pouvoir entre les employés et favoriser une structure plus horizontale que hiérarchique, tout en évitant de tomber dans un état de débat continuel où rien n'est fait: Cet état ou les développeurs finissent par critiquer le manque d'autorité. Pas facile d'arriver avec des règles d'action précises.

Mais ceci m'amène à croire qu'à priori, des managers non-techniques, c'est peut-être mieux que des managers très techniques. Le pouvoir des managers non-techniques pourrait ne se limiter qu'à un pouvoir décisionnel laissant une place suffisante aux développeurs. De son côté, le manager technique influence le débat technique et peut (involontairement) faire en sorte que le design soit issue de son unique cerveau plutôt que de la somme des compétences cervicales de ses développeurs.

L'idéal en fait, est probablement d'avoir un manager technique conscient de l'effet de l'autorité et qui réussit à anéantir ses effets négatifs.