Pourquoi les ingénieurs senior laissent-ils parfois passer les mauvais projets ?

• Les ingénieurs senior privilégient l’« action efficace » plutôt que le simple fait d’avoir raison, et ne cherchent pas à bloquer tous les projets erronés
• Un « mauvais projet » peut relever de problèmes techniques, politiques ou UX, et dépend souvent d’un jugement subjectif
• L’influence doit être gérée comme un compte bancaire : s’opposer trop souvent fait perdre de la crédibilité et peut mener à une forme de « faillite politique »
• La décision d’intervenir dépend de la proximité du projet, de son impact sur l’équipe et de l’ampleur des dégâts potentiels pour l’entreprise
• Plutôt que de vouloir tout corriger, il faut choisir stratégiquement quand intervenir, et gérer le reste par l’observation et la préparation

---

Définition et exemples de mauvais projets

• Un « mauvais projet » peut prendre plusieurs formes : résoudre un problème inutile, concevoir une architecture trop complexe, ou répondre à des motivations politiques
  • Côté UX, il peut s’agir de résoudre un problème inexistant ou de casser un flux existant
  • Techniquement, on retrouve une complexité excessive, un mauvais choix de bibliothèque, ou une architecture inefficace
  • Politiquement, il peut s’agir de projets lancés pour une promotion ou pour suivre une mode
• Le caractère bon ou mauvais d’un projet reste un jugement subjectif qui ne se révèle souvent qu’avec le temps, et n’est pas forcément clair au départ
• Exemple chez Google : un projet où l’équipe plateforme voulait transférer un flux utilisateur central à une autre équipe a échoué pour des raisons politiques
  • Le projet était techniquement excellent, mais a été abandonné deux ans plus tard à cause de problèmes de pouvoir entre organisations
  • Leçon : la politique interne et la justesse de la définition du problème comptent autant que la qualité technique

Pourquoi on ne peut pas bloquer tous les mauvais projets

• Les entreprises logicielles ont un fort biais en faveur de l’exécution rapide, si bien que soulever des inquiétudes est souvent perçu comme un frein
  • Par conséquent, si le problème n’est pas perçu comme majeur, il a de fortes chances d’être ignoré
• S’opposer de manière répétée peut vous faire étiqueter comme une personne négative, et les échecs évités sont rarement reconnus
• L’opposition peut affecter la promotion de quelqu’un ou un projet soutenu par la direction, ce qui crée un risque politique
• L’attention qu’un seul ingénieur peut consacrer est limitée : intervenir sur tous les sujets finit par rendre cynique

Gérer son influence comme un « compte bancaire »

• L’influence est un capital accumulé par les résultats et la collaboration, qui se retire à chaque opposition
  • Chèque de 5 $ : une remarque mineure au niveau d’une revue de code
  • Chèque de 500 $ : une contestation d’une décision d’architecture ou d’un planning
  • Chèque de 50 000 $ : une tentative d’arrêter un projet porté au niveau exécutif
• Intervenir de façon répétée sur des sujets mineurs fait perdre la capacité de réagir sur les enjeux majeurs
• Quand l’influence est épuisée, on peut sombrer dans une « faillite politique », avec exclusion des réunions et avis ignorés

Critères pour décider quand intervenir

• Vérifier son expertise : s’assurer que son jugement est suffisamment fondé
• Reconnaître les limites de sa parole : exprimer un avis n’est pas donner un ordre, mais partager un point de vue
• Trois critères de décision
  • Proximité (Proximity) : plus le projet est proche de votre équipe, plus le coût d’intervention est faible
  • Impact sur l’équipe (Team Impact) : si l’échec risque de nuire directement à l’équipe, intervenir a plus de valeur
  • Échelle entreprise (Company Scale) : si l’échec peut affecter l’ensemble de l’organisation, l’intervention est davantage justifiée

Façons de réagir face à un mauvais projet

• Intervention directe : demander l’arrêt du projet ou soumettre un document exprimant de fortes inquiétudes
  • Cela demande de la conviction et d’accepter le risque
• Intervention partielle : réorienter la conception ou guider vers une meilleure solution
  • Avec une approche coopérative, on peut être perçu comme quelqu’un d’utile
• Non-intervention : lorsque l’inertie politique ou les limites d’influence rendent l’intervention peu rentable
  • Si l’équipe est concernée, il faut préparer des mesures de protection, comme réduire les dépendances ou construire des alternatives
  • Sinon, il vaut mieux observer discrètement et ne partager son avis qu’en interne
• Gestion d’équipe : partager honnêtement la réalité avec les membres, tout en évitant les détails politiques inutiles

Conclusion

• L’idée clé est que « avoir raison et être efficace sont deux choses différentes »
• Dans les grandes entreprises, la politique et le contexte pèsent souvent plus que la logique, et il est impossible de corriger toutes les erreurs
• Il faut utiliser stratégiquement son influence et sa crédibilité pour se concentrer sur les moments où un vrai changement est possible
• Dans les autres cas, il faut partager avec ses collègues, se préparer et apprendre en observant
• Même sans tout résoudre parfaitement, cette approche reste soutenable dans la durée

[GN⁺]

Réactions sur Hacker News

• Ça me rappelle un manager qui disait autrefois : « parfois, il faut laisser les gens échouer »
  Continuer à porter certaines personnes demandait trop d’énergie. J’espérais qu’elles finiraient par nager seules, mais parfois cet effort était mieux employé ailleurs
  Il y a eu un projet mené sans ma participation qui n’aurait jamais pu réussir sans mes connaissances. Cette équipe était tellement médiocre qu’elle mélangeait les questions à son travail comme si c’était normal
  En plus, quand j’ai appris que la direction rabaissait mon équipe tout en les félicitant, je l’ai vraiment vécu comme une humiliation. Leur implémentation était affreuse

  • Je dis souvent : « parfois, il faut laisser les managers échouer »
    Certains managers détestent qu’on leur dise que leur idée ne marchera pas. Si on les contredit, on devient la cause désignée de l’échec
    Donc je fais avancer le travail, tout en leur partageant souvent la situation. Comme ça, ils voient eux-mêmes l’échec annoncé, et cela me dissocie de cet échec
  • Quand la direction échoue, elle ne se rejette pas la faute entre elle. À la place, elle fait venir des consultants et licencie les ingénieurs seniors
  • J’ai déjà entendu dire que « les gens doivent collecter eux-mêmes leurs données ». Au final, on n’apprend qu’en se heurtant soi-même aux choses
  • Je pense que l’échec d’une personne et l’échec d’un projet sont deux choses différentes
    L’échec individuel coûte peu et a une valeur pédagogique. Parfois même, leur approche fonctionne, et l’organisation acquiert alors un nouvel actif de connaissance
  • Laisser les gens apprendre par eux-mêmes est risqué. Il faut croire qu’ils ont conscience d’eux-mêmes et qu’ils ne dépendent pas de mon soutien
    Ils peuvent échouer sans rien apprendre. Mais si on a fait de son mieux, on peut au moins garder la conscience tranquille

• Le caractère « mauvais » d’un projet est subjectif pendant la plus grande partie de son cycle de vie
  Il m’est arrivé de voir des personnes extérieures s’opposer à un projet et tenter de le faire arrêter, puis le projet a fini par sortir et réussir, ce qui a détruit leur crédibilité
  Il faut faire attention à l’usage qu’on fait de sa réputation

  • J’ai vécu quelque chose de similaire. C’était la première fois que je voyais un égoïsme aussi flagrant dans une organisation censée favoriser la collaboration
    Je sais bien que le monde n’est pas toujours fait de soleil et d’arcs-en-ciel, mais à ce moment-là j’ai vraiment été déçu

• Comme dans l’expression « pas mon singe, pas mon cirque », je n’interviens pas dans ce qui n’est pas de ma responsabilité
  Même quand je travaillais comme architecte, je ne donnais pas de conseils inutiles sur l’UI ou la logique métier hors de mon périmètre
  Quand une décision venait d’un manager plus haut placé, je la suivais simplement. En tant que consultant, j’ai gardé le même principe
  Je n’interviens avec prudence que dans mon domaine d’expertise. Et seulement avec l’approbation du C-suite

• Ce conseil est assez pertinent pour les PME. Mais dans les grandes entreprises, s’opposer à un projet n’a presque aucun intérêt
  S’il réussit, on a l’air idiot, et s’il échoue, personne ne s’en souvient
  Le vrai ROI apparaît quand on propose une solution après l’échec. Les gens aiment les « problem solvers »
  J’avais autrefois proposé des tests E2E automatisés et on avait refusé ; plus tard, quand le problème a explosé, j’ai ressorti ce framework et j’ai été traité en héros

  • Plus on monte dans l’entreprise, plus on doit assumer les erreurs des autres pour peu de récompense
    Il me semble plus sage de rester à un poste plus junior et de vivre sans ce stress
  • Dans une startup, quelques ingénieurs qui disent « ça n’a aucun sens » peuvent éviter un désastre
    À l’inverse, les grandes entreprises gaspillent des années et des millions de dollars à cause de la politique interne

• Je fais partie de ceux qui pensent qu’« il ne faut pas ignorer les problèmes »
  Si on est en position d’aider, il faut proposer discrètement une autre approche. Pas besoin de réagir de manière émotionnelle

  • La condition « être en position d’aider » est essentielle
    Dans une petite organisation, les bonnes idées sont facilement prises en compte, mais dans une grande, le risque politique est bien plus élevé
    En pratique, il y a plus de chances d’y perdre sa réputation que d’aider réellement. D’où l’importance de choisir ses combats
  • Dans une petite organisation, intervenir tôt peut être un devoir
    Mais dans une grande organisation, changer un projet déjà lancé demande un temps et une énergie énormes
  • La formule « laisser un mauvais projet tranquille » peut prêter à confusion
    En réalité, il arrive souvent qu’on n’ait aucun contrôle sur ce projet. Un titre plus juste serait : « on ne sait pas pourquoi l’autre équipe fait comme ça »
  • Moi aussi, quand un échec me semble probable, je consigne mon avis par écrit et j’en reste là
    Le professionnalisme, c’est parler quand il faut parler. Mais par expérience, ça ne change presque jamais rien
  • Si on sait, on le dit, puis on ne porte plus la charge émotionnelle ensuite. Si mes conseils sont ignorés, ce n’est plus mon problème

• Je suis justement en train d’observer une situation de ce genre
  Le dirigeant a choisi une plateforme low-code pour des raisons de coût et de rapidité, mais cela a fini par exiger une énorme personnalisation bricolée
  Mon équipe déploie plusieurs fois par jour en TypeScript, tandis que cette équipe ne déploie qu’une fois par mois et fait des choses bizarres avec curl

• Ce conseil est excellent dans la réalité politique du big tech, mais au fond cela ressemble à une forme de pacifisme d’entreprise
  Dans d’autres environnements, on n’a pas le luxe de brûler de l’argent et de la motivation
  (Cela dit, Lalit résume très bien des dynamiques organisationnelles complexes dans un court texte)

  • Je n’ai jamais travaillé dans le big tech, mais j’ai vu le même phénomène dans de petites organisations
    Celui qui chipote en permanence finit par être étiqueté comme une personne négative
    Le vrai conseil, au fond, c’est de garder son énergie pour les moments importants. Tous les problèmes ne mettent pas l’entreprise en jeu
  • Le pacifisme n’est pas l’inaction. C’est au contraire l’action politique la plus active et la plus efficace

• Les ingénieurs n’ont pas le pouvoir, pour des raisons politiques, de « laisser échouer » un mauvais projet
  C’est la responsabilité de la direction. Les ingénieurs n’ont qu’à donner un avis technique
  Mais il faut comprendre cette dynamique pour que sa carrière n’en pâtisse pas
  Les luttes de territoire entre équipe produit et équipe plateforme viennent d’un manque de leadership clair
  Si vous vous demandez pourquoi cela arrive si souvent, ce billet à propos de Google mérite le détour

• Cette façon de penser est courante dans les grandes organisations, surtout dans les administrations publiques
  Les coûts sont supportés par d’autres services, et le pouvoir se mesure au nombre de personnes qu’on gère
  Pour empêcher cette nécrose organisationnelle, les dirigeants doivent mettre en place des mécanismes clairs de mesure et de prévention

  • Les humains aiment instinctivement les personnes positives et n’aiment pas les personnes négatives
    Le capital politique ne disparaît pas juste parce qu’on choisit de l’ignorer

• C’est une bonne analogie
  Quand on construit du leadership et de la confiance, on crée un espace où l’on peut dire « vous avez tort »
  Mais si les dirigeants ne font pas toujours confiance aux ingénieurs, c’est aussi parce que les ingénieurs ont parfois tort
  Les ingénieurs excellent à repérer les défauts, mais sont souvent moins bons pour comprendre le contexte métier
  Donc même une « idée qui a l’air stupide » doit être jugée après avoir compris son contexte
  C’est quand on sait distinguer les idées qu’il faut vraiment tuer de celles qui sont simplement imparfaites qu’on gagne la confiance de l’organisation