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