L’incident où j’ai menti au CTO pour éviter la crise

L’histoire d’un développeur qui a menti à son CTO

• C’est une histoire qui remonte à quelques années, à l’époque où je travaillais dans une entreprise du Fortune 500
• À ce moment-là, le CTO avait décroché un gros projet pour un client important avec lequel il avait des liens personnels, et avait décidé d’externaliser la partie clé à un grand prestataire de services technologiques
• Mais le « produit » du prestataire nécessitait en réalité une personnalisation majeure pour répondre aux exigences, ce qui en faisait le pire choix possible
• Lors des réunions de suivi avec le CTO, personne ne pensait que c’était une bonne idée, mais tout le monde se contentait de dire : « Bonne idée, chef »
• Finalement, quand le prestataire a livré le « produit », on était déjà en septembre, et la death march pour une sortie en octobre a commencé
• Pendant les tests, de graves bugs ont été découverts, notamment des problèmes de performances et le dépassement de la limite de 16 Mo par document de MongoDB
• Tout en annonçant au client que la sortie serait retardée d’un mois, il a été décidé de lancer en parallèle un projet secret pour remplacer l’intégration du prestataire
• J’étais alors un jeune développeur enthousiaste, et on m’a affecté trois coéquipiers pour commencer à développer le système de remplacement
• À la mi-décembre, après avoir presque terminé le logiciel de remplacement en un mois, tout le monde était en état de burn-out
• C’est alors que le CTO est arrivé et a annoncé que les vacances étaient annulées, ce à quoi j’ai répondu : « D’accord »
• Mais en repensant au conseil de mon père, j’ai dit à mes coéquipiers de partir en vacances, puis je me suis rendu seul à la réunion de suivi de la death march avec le CTO et j’ai menti
  • « L’équipe travaille dur. Aujourd’hui, nous avons atteint le 73e jalon d’intégration »
  • « L’équipe a bien avancé hier. Nous avons terminé un autre service web »
• Une semaine plus tard, les membres de l’équipe sont revenus reposés, et nous avons pu livrer avec succès dans les délais en janvier

L’avis de GN⁺

• C’est un cas où le leadership qui a permis de mener le projet à bien, malgré un contexte dégradé et des exigences excessives, ressort clairement. Le soin apporté à l’état de forme de l’équipe est particulièrement marquant
• Mentir au CTO n’est toutefois pas souhaitable. À long terme, cela peut faire perdre la confiance au sein de l’organisation et provoquer des problèmes plus graves
• L’échec dans le choix du prestataire et la gestion de l’externalisation relève largement de la responsabilité du CTO, mais il aurait sans doute fallu une communication plus transparente et plus proactive pour corriger la situation
• Pour éviter le burn-out des développeurs, il aurait fallu dès le départ établir un calendrier plus réaliste et affecter suffisamment de personnel. Le mode crunch est une pratique à éviter
• Parmi les alternatives utiles à envisager face à des situations similaires, on peut citer la méthodologie agile. En développant par cycles courts et en répétant le processus de retour de feedback, on peut minimiser les risques et mieux réguler la charge de travail de l’équipe

[GN⁺]

Avis Hacker News

• Surmenage et annulation des congés :
  • Travailler jusqu’à l’épuisement et annuler ses congés pour respecter des délais irréalistes n’est pas judicieux et finit par se regretter
  • Une entreprise qui dépend du sacrifice des congés de ses employés pour livrer un produit contribue à une culture de travail problématique
• Entreprise saine vs entreprise malsaine :
  • Dans une entreprise saine, des personnes expérimentées auraient anticipé les problèmes de l’approche d’externalisation et auraient exprimé leurs inquiétudes plus tôt
  • Une communication ouverte, le fait de chercher ensemble des solutions et des managers qui défendent le bien-être de leur équipe sont des signes d’un environnement sain
  • Le récit décrit une situation malsaine dans laquelle un manager ment à plusieurs reprises à sa hiérarchie
• Pratiques fournisseurs aberrantes :
  • L’approche du fournisseur consistant à stocker toutes les transactions dans un immense document JSON et à devoir le relire en entier à chaque mise à jour est absurde
  • Un autre exemple est celui d’une startup qui stockait les données de tickets des utilisateurs comme colonnes supplémentaires dans la table des utilisateurs, aboutissant à des centaines de colonnes
• Situation dysfonctionnelle et leadership :
  • L’approche du chef d’équipe qui ment à propos des congés est inacceptable et constitue une faute pouvant justifier un licenciement
  • Une meilleure approche consiste à s’opposer aux exigences déraisonnables d’heures supplémentaires et à défendre un périmètre de projet raisonnable ainsi que la responsabilité du fournisseur
  • Le chef d’équipe a la responsabilité de protéger son équipe contre des exigences délirantes, même si cela met son propre poste en danger
• Personne n’y gagne :
  • Le fournisseur a livré un travail de mauvaise qualité, le CTO est resté dans l’ignorance, les développeurs ont été surmenés et le protagoniste a dû recourir au mensonge
  • C’est une situation insensée que personne ne devrait tolérer. Partir vers un meilleur environnement de travail est préférable
• Honnêteté et transparence :
  • Dire honnêtement à la direction qu’il existe des problèmes techniques, de performance, de changement de périmètre, etc., a bien fonctionné pour certaines personnes
  • Mentir pour tenir des échéances arbitraires fixées par une direction déconnectée n’est pas une bonne approche
• Fossé de confiance entre développeurs et direction :
  • Il existe souvent une asymétrie d’information et un manque de confiance entre les développeurs et les dirigeants non techniques
  • Les managers ne peuvent pas facilement évaluer l’avancement et ressentent de l’incertitude quant au succès du projet
  • Comme le risque se situe du côté business, les développeurs doivent parfois pousser pour combler ce fossé de confiance et livrer des résultats
• Sous-promettre et sur-livrer :
  • Le fait que le protagoniste ait menti en disant qu’un travail déjà terminé était terminé peut, dans une certaine mesure, être vu comme du « sous-promettre et sur-livrer »
  • Mentir à propos d’un travail inachevé est plus risqué et peut démoraliser les coéquipiers lorsqu’ils reviennent
• Organisations impuissantes et outils low-code :
  • Les pratiques déplorables du fournisseur et le périmètre modeste du projet montrent à quel point certaines grandes entreprises peuvent se sentir impuissantes face aux projets logiciels
  • Cela peut expliquer, sinon auprès des ingénieurs, du moins auprès du leadership technique, la popularité d’outils low-code comme Retool
• Intégrité et savoir dire non :
  • Une véritable « rockstar » fait preuve d’intégrité et a le courage de refuser la stupidité et les exigences déraisonnables
  • Il n’appartient pas à une seule personne de compenser une incompétence hors norme ni de porter à elle seule la charge de toute l’équipe