- Un article qui propose des stratégies concrètes pour que les ingénieurs participent efficacement à la politique interne d’une entreprise technologique, et explique comment surmonter le sentiment d’impuissance politique que beaucoup d’ingénieurs ressentent
- Les ingénieurs ne sont pas des joueurs du jeu politique mais des outils ; ils peuvent néanmoins exercer une influence politique en soutenant activement la réussite de projets très visibles ou en proposant des idées techniques alignées sur les changements de priorités de l’organisation
- Comme les centres d’intérêt d’une organisation évoluent par vagues, la stratégie clé consiste à préparer à l’avance des programmes techniques dans plusieurs directions — stabilité, expérience développeur, amélioration des performances, etc. — puis à les proposer au bon moment
- Quand le besoin politique entre en collision avec l’absence de bonnes idées, cela conduit aux pires décisions techniques ; les ingénieurs seniors ont la responsabilité de présenter la bonne idée au bon moment
- On peut y voir, de manière cynique, un moyen de devenir un instrument dans des luttes de pouvoir, ou, de manière optimiste, une façon d’atteindre ses objectifs techniques tout en respectant la hiérarchisation des priorités par la direction
Croyance répandue dans l’impuissance politique des ingénieurs
- Beaucoup d’ingénieurs logiciel adoptent une attitude fataliste vis-à-vis de la politique d’entreprise et pensent qu’il est inutile d’y participer
- Les décisions techniques sont souvent prises pour des raisons entièrement égoïstes, ce qui empêcherait les ingénieurs de bonne foi d’avoir la moindre influence
- Les parties prenantes les plus puissantes seraient trop incompétentes et dysfonctionnelles pour qu’il soit réellement possible de comprendre leurs demandes et d’y apporter des solutions
- Le jeu politique repose sur des informations non publiques auxquelles les ingénieurs n’ont pas accès, si bien que toute tentative de participation ne mènerait qu’à de la confusion
- Les managers et les dirigeants consacrent l’essentiel de leur temps à la politique, tandis que les ingénieurs le consacrent à l’ingénierie ; les ingénieurs partent donc avec un sérieux désavantage politique
- Il est vrai que les ingénieurs logiciel ne peuvent pas jouer au même niveau que les véritables opérateurs politiques
- Commencer à comploter à la Game of Thrones est une terrible erreur pour un ingénieur ; ce genre de manœuvres est immédiatement repéré puis retourné contre lui
- Pour intriguer efficacement, il faut de l’entraînement et du pouvoir, et les ingénieurs logiciel ne disposent généralement ni de l’un ni de l’autre
Façons pragmatiques de participer à la politique
- Dans les grandes entreprises, le simple fait est que les ingénieurs logiciel sont des outils plutôt que des joueurs du jeu politique ; mais il existe malgré tout de nombreuses façons de participer sans intriguer
- La plus simple consiste à travailler activement à la réussite d’un projet très visible
- Cela ressemble beaucoup à ce qu’il faudrait déjà faire dans le cadre normal de son travail
- Si l’entreprise investit massivement dans un nouveau projet — probablement un projet IA aujourd’hui — utiliser ses compétences d’ingénierie pour le faire réussir constitue un atout politique pour le VP ou le dirigeant qui le porte
- En échange, on peut obtenir les récompenses qu’un dirigeant peut accorder dans une entreprise technologique : bonus, aide pour une promotion, poste sur de futurs projets à forte visibilité, etc.
Utiliser des idées techniques dans des campagnes politiques
- Une approche un peu plus difficile, mais qui donne davantage de contrôle, consiste à rendre ses idées préférées utiles à une campagne politique existante
- Si l’on veut par exemple extraire une fonctionnalité existante dans un service séparé, il y a deux façons de procéder
- La méthode difficile : dépenser son propre capital politique pour rallier du soutien, convaincre son manager de l’importance du projet, puis persuader lentement les sceptiques afin d’obtenir l’approbation
- La méthode facile : laisser un dirigeant dépenser son capital politique (bien plus important) sur le projet
- Attendre qu’une consigne à l’échelle de l’entreprise apparaisse autour d’un objectif aligné avec le projet, par exemple un accent mis sur la stabilité après un incident majeur
- Puis suggérer à son manager que son projet pourrait précisément répondre à ce besoin
- Si l’analyse est juste, l’organisation soutiendra le projet, et au lieu de consommer du capital politique, cela l’augmentera au contraire
Surfer sur les vagues d’intérêt de l’organisation
- L’attention d’une organisation arrive par vagues
- Quand vient la période de la stabilité, les VP veulent désespérément faire quelque chose, cherchent un projet de stabilité crédible à montrer à leur hiérarchie, mais ne sont pas capables de le définir eux-mêmes
- En général, ils sont prêts à financer presque tout ce que les équipes d’ingénierie proposent
- À l’inverse, lorsque l’attention de l’organisation est ailleurs — par exemple sur un lancement majeur de produit — elle ne veut pas que les ingénieurs passent du temps sur des refactorings internes centrés sur la stabilité, invisibles pour les clients
- Pour faire aboutir un travail technique dans une entreprise technologique, il faut attendre la bonne vague
- C’est une bonne idée de préparer à l’avance plusieurs programmes techniques orientés dans des directions différentes
- Les ingénieurs solides repèrent naturellement ce type d’opportunités dans le cadre de leur travail habituel
- Exemples de plans :
- faire migrer le code de facturation d’appels API mis en cache vers des données stockées mises à jour par webhooks
- supprimer un ancien pipeline de build maison et le remplacer par Vite
- réécrire en Golang un service Python désordonné à fort trafic
- remplacer un frontend CMS lent servant la documentation publique par un site statique rapide
L’importance de proposer au bon moment
- Quand les dirigeants s’inquiètent de la facturation, on peut présenter un refactoring de la facturation comme une amélioration de la stabilité
- Quand ils se préoccupent de l’expérience développeur, on peut proposer le remplacement du pipeline de build
- Quand les clients se plaignent des performances, on peut mettre en avant la réécriture en Golang comme une bonne option
- Quand le CEO regarde l’état de la documentation publique et panique, on peut défendre une reconstruction en site statique
- L’essentiel est de disposer immédiatement d’un programme de travail détaillé et efficace, quel que soit le sujet à la mode du moment
Le moment où naissent les pires décisions techniques
- Même sans suivre cette méthode, certains programmes obtiendront un financement ; mais sans elle, on ne peut pas contrôler lesquels
- C’est précisément là que les entreprises prennent leurs pires décisions techniques : quand la nécessité politique de faire quelque chose rencontre l’absence de bonnes idées
- En l’absence de bonne idée, on finit par utiliser une mauvaise, et personne ne préfère vraiment ce résultat
- C’est mauvais pour les dirigeants : ils doivent vendre un résultat technique décevant comme s’il s’agissait d’un succès
- C’est mauvais pour les ingénieurs : ils doivent consacrer temps et efforts à construire une mauvaise idée
- Si l’on est un ingénieur très senior, les VP vous en tiendront silencieusement rigueur, et ils auront raison
- Être prêt avec la bonne idée au bon moment fait partie de votre responsabilité
Deux façons de voir les choses
- Vision cynique : on peut lire cela comme une invitation à devenir un outil commode au service des sociopathes qui dirigent l’entreprise dans leurs luttes de pouvoir internes sans fin
- Vision optimiste : on peut y voir une invitation à laisser les dirigeants définir les grandes priorités de l’entreprise — puisque c’est leur rôle — puis à aligner ses plans techniques dessus
- Dans les deux cas, faire avancer le bon plan au bon moment permet d’atteindre davantage d’objectifs techniques
Réactions sur Hacker News et citation connexe
- L’article a suscité de l’attention sur Hacker News et a reçu une réaction bien plus positive que d’autres textes sur la politique
- Un commentaire mentionne une citation de Milton Friedman et applique l’idée de l’article à la politique publique en général
- « Seule une crise — réelle ou perçue — produit un véritable changement. Quand cette crise survient, les mesures prises dépendent des idées disponibles autour de nous. C’est là notre fonction fondamentale : développer des alternatives aux politiques existantes, puis les maintenir vivantes et disponibles jusqu’à ce que ce qui est politiquement impossible devienne politiquement inévitable »
- Certains commentaires ont critiqué cette approche comme trop ludique et trop égoïste, mais l’auteur estime que tout dépend de l’objectif
- Un commentaire résume bien l’idée centrale : « Au lieu d’attendre les instructions, de se montrer cynique face aux mauvaises idées quand un vide apparaît, et de ne pas faire ce que vous voulez faire, l’auteur maintient un backlog de bonnes idées importantes à proposer quand une personne influente déclare qu’un sujet devient prioritaire. Il accepte un compromis sur le timing pour accomplir ce qu’il veut faire »
1 commentaires
Commentaire Hacker News
Voici l’idée principale de ce post
Le premier point peut sembler évident, mais c’est un sujet sur lequel j’ai dû coacher beaucoup de personnes en début de carrière à plusieurs reprises Beaucoup de gens qui allaient droit vers des difficultés, voire un PIP, ont trouvé un point de bascule rien qu’en appliquant bien cette boucle
J’interprète le point 2 comme le fait de préparer sa propre feuille de route. Par exemple, si je veux rendre une codebase plus minimaliste, je prépare à l’avance un PoC et les détails associés pour pouvoir le proposer immédiatement quand une occasion se présente Grâce à cette préparation, si un problème de performance du site, de SEO ou un bug survient, je peux proposer cette idée de simplification comme solution Le concept est intéressant, mais je me demande souvent comment l’appliquer concrètement. Je pense parfois à créer des documents préparatoires pour usage futur. Un peu comme tenir un blog, en documentant régulièrement mon travail en attendant la bonne opportunité Une grande partie de ce travail supplémentaire peut finir par ne servir à rien, mais au fond j’ai l’impression qu’on fait déjà souvent ce genre de choses
Une autre chose que j’ajouterais, c’est de ne pas faire n’importe quoi contre l’avis de personnes qui ont plus de poids politique que votre manager. Sauf, bien sûr, si quelqu’un d’encore plus puissant leur donne une instruction explicite en public Il ne s’agit pas nécessairement de faire ce qu’ils veulent, mais de faire attention à ne pas les froisser inutilement Se faire des ennemis vaut rarement le coup, et la plupart des managers sont prêts à vous sacrifier pour se protéger si la situation tourne mal
Personnellement, je préfère proposer directement à mon manager ce qu’il faudrait faire. Je mets les sujets importants sur la table et j’explique pourquoi ils comptent Il faut être proactif et faire en sorte que le manager bénéficie de mon expertise Je n’ai pas encore énormément d’expérience là-dedans, mais j’ai déjà eu quelques réussites
Ce type de conseil devient encore plus important à mesure qu’on monte. C’est vrai aussi pour un engineering manager, et j’essayais déjà d’appliquer ce principe quand j’étais director en report direct au CTO
Une de mes citations préférées est la suivante : "Seule une crise — réelle ou perçue — produit un véritable changement. Les actions entreprises à ce moment-là dépendent des idées qui traînent dans l’air. Notre fonction fondamentale est de développer des politiques alternatives, de les maintenir vivantes et disponibles, jusqu’à ce que ce qui semble politiquement impossible devienne politiquement inévitable" - Milton Friedman Rédiger des one-pagers et des documents techniques, les partager à l’avance, puis les ressortir quand la crise arrive a été efficace pour faire émerger mes idées Il m’est arrivé de pousser progressivement la direction architecturale que je voulais, en me rapprochant peu à peu de l’objectif, et il est important de construire du consensus Bien sûr, je me suis aussi souvent fait dépasser par des VP ou des directors meilleurs que moi politiquement Mais avoir une bibliothèque de one-pagers prête, les partager discrètement et les “laisser flotter dans l’air” jusqu’à ce qu’il y ait une motivation pour agir s’est révélé bien plus efficace
Je comprends complètement la partie "j’ai perdu la bataille politique". Ce qui m’a surpris, une fois devenu middle manager ou au-dessus, c’est à quel point on voit facilement les manœuvres politiques des employés plus juniors Beaucoup d’IC ou d’EM de premier niveau surestiment leur sens politique ou leur intelligence sociale En plus, la profondeur et la largeur de la communication dans l’organisation sont différentes, donc même si quelqu’un croit convaincre une partie prenante, cette personne peut très bien aller ensuite glisser le contexte à son manager J’ai vu cette scène se répéter plusieurs fois pendant que, côté management, nous essayions discrètement de contenir des manœuvres politiques maladroites
Je serais curieux de savoir ce que signifie concrètement le fait de "laisser circuler des one-pagers et des documents techniques"
Je suis d’accord avec cette citation et cette méthode me paraît efficace. Mais dans la réalité, l’échelle de temps peut être tellement longue qu’elle en devient épuisante Et il arrive souvent que la crise soit tout simplement ignorée, qu’elle ne soit pas perçue comme telle, ou qu’elle finisse normalisée
Je me demande si les one-pagers vous ont aussi apporté de la reconnaissance et des promotions, ou s’ils ont surtout aidé à faire aboutir les idées
Voici selon moi la meilleure manière de faire
Déployer souvent en production (livrer dans le réel plutôt que rester dans le théorique)
Obtenir des résultats significatifs (des wins), mesurés avec des métriques convenues
Avoir dans le management ou chez les PM quelqu’un qui sache bien “vendre” mes succès Mais malgré cela, les problèmes continuent. Il y a toujours un nouveau VP ou un nouveau leader qui veut montrer qu’il innove. L’équipe qui maintient le système existant se retrouve cataloguée comme ayant tort, et le nouveau VP met en avant sa ligne avec des idées progressistes, comme l’IA. Dès que mon code est déployé, il est considéré comme du "legacy" Ensuite, le VP enchaîne les promesses flamboyantes sur l’avenir, et depuis mon rôle de maintien du réel, je ne peux tout simplement pas rivaliser. La réalité n’est ni sexy ni amusante. On devient alors l’ancien monde Au fond, tout tourne autour du patronage : faire réussir le VP au-dessus de soi, puis se créer une position qui permette de le suivre lorsqu’il part ailleurs
Je pense vraiment que c’est juste. Un cran plus loin, en tant que staff engineer, il est important de faire comprendre très clairement que "je ne suis pas mon code". Le code devient dette / legacy dès le moment où il est déployé L’idéal n’est pas d’être perçu comme un "défenseur du code", mais comme un PARTENAIRE À ÉGALITÉ avec le leadership, le produit, les décideurs, etc. C’est surtout une question de cadrage. On peut avoir exactement les mêmes actions, mais si je suis vu comme un partenaire du travail, les dirigeants me considéreront comme un soutien proactif ; sinon, je serai perçu comme un obstacle qu’il faut convaincre de force
Je suis tout à fait d’accord avec l’idée qu’"il faut quelqu’un chez les PM qui sache bien vendre mes résultats". Avec le recul, ce qui a peut-être eu le plus d’impact sur ma carrière, c’est la vitesse à laquelle je parvenais à m’éloigner des mauvais PM Un bon PM améliore tout, mais ils sont difficiles à trouver. À l’inverse, quand un PM se trompe de direction, tout part de travers, et dès qu’il disparaît, le climat peut changer complètement
J’ai adoré la formule sur le fait de ne pas pouvoir "rivaliser avec des promesses d’avenir". Cela arrive tellement souvent. Même quand ces promesses n’ont déjà pas été tenues les 26 fois précédentes, le "futur glorieux" impressionne toujours autant
Dans le travail réel, l’idée de déployer souvent en production (rep = exécution concrète, zéro théorie) est intéressante, mais je me demande pourquoi les promesses floues des VP sur un avenir hypothétique sont jugées plus précieuses que leur faisabilité réelle
Je n’ai jamais entendu parler de "travail théorique", mais il existe clairement des endroits où l’on déploie tous les jours. Cela dit, je ne pense pas que déployer fréquemment soit idéal. Je me demande bien ce qu’on peut livrer de réellement substantiel en une seule journée. Les projets sur lesquels je travaille, qui rapportent de l’argent supplémentaire à l’entreprise, ne peuvent pas être terminés en un jour. Si tout pouvait être fini en une journée, on n’aurait besoin d’ingénieurs que quatre fois par an. Donc ce "déployer souvent" ressemble plutôt à une vanity metric
Je n’ai jamais travaillé dans une entreprise vraiment dysfonctionnelle, donc je ne me reconnais pas du tout dans le début de ce texte D’après mon expérience, la communication top-down a toujours été active, et même quand on développait dans une direction avec laquelle je n’étais pas d’accord, cela faisait l’objet de suffisamment de discussions en amont pour que je comprenne pourquoi des collègues intelligents voyaient les choses autrement Je ne sais pas si c’est parce que je n’ai travaillé que dans des entreprises fondées par des ingénieurs, ou si j’ai simplement eu de la chance
Les VP des grandes entreprises ont des objectifs plus larges, et une conception des moyens tout aussi large. Ce n’est pas forcément mauvais. Cela laisse de l’espace pour essayer différentes approches avant de se figer sur une technologie ou une méthodologie précise. Il y a certes du gaspillage, mais cela peut aussi être efficace pour réagir immédiatement aux bouleversements du secteur et accomplir la mission du management exécutif
Je serais curieux de savoir dans quel type d’entreprise, en termes de taille, vous avez travaillé
"Une voie un peu plus difficile mais qui donne davantage de contrôle consiste à rattacher mon idée à une campagne politique déjà existante" J’ai appris l’art de me greffer efficacement aux projets pilotés par un VP. C’est amer, mais terriblement efficace
Dans ce camp, on entend souvent la frustration suivante : "J’ai parfaitement refactoré toute la codebase et personne ne m’en donne le moindre crédit" J’ai déjà entendu une ancienne connaissance se vanter d’avoir passé des mois à nettoyer parfaitement un pipeline de données, sans que personne n’en reconnaisse la valeur, et cela m’a fait réfléchir En tant qu’ingénieur, je sais que ce travail a de la valeur, mais du point de vue d’un PM ou d’un EM, c’est un peu comme si un PM passait un mois à annoter et trier toute la documentation d’ingénierie interne, et qu’on lui répondait : "D’accord, mais quel est l’impact pour l’entreprise ?" Du point de vue d’un PM, cela rend floue la distinction entre un ingénieur influent et un ingénieur qui ne fait "que du travail de mise en forme" Au final, il est important d’expliquer clairement, avant de le faire, le travail qu’on prévoit dans un format adapté à un public non technique J’ai déjà essayé de pousser les tests unitaires et les tests d’intégration, mais faute de volonté politique, cela ne passait jamais dans les priorités. Puis un gros SEV est arrivé, et quand j’ai dit : "Il nous faut des tests pour éviter ce genre de problème", tout le monde s’est enfin accordé sur leur valeur. Désormais, tout le monde comprend pourquoi les tests sont nécessaires
Je suis tout à fait d’accord. Si je veux faire avancer une action en tant que priorité, je dois l’expliquer dans la logique et dans le langage des personnes qui décident des priorités Par exemple, les PM pensent généralement en unités monétaires. Si mon objectif technique, comme l’extension de la couverture de tests, demande 200 dev hours par an mais permet d’en économiser 400, de réduire les tickets de support de 15 %, d’ouvrir de futurs scénarios business, etc., il devient beaucoup plus facile à défendre Une astuce que j’aime bien consiste à empaqueter le travail sur la tech debt non pas comme un "travail technique", mais comme un sujet à impact business clair, au point que le PM finisse par l’ajouter lui-même à la roadmap Cette approche devient plus facile avec l’expérience. Au début, les gens sont sceptiques, mais avec le temps, la confiance dans mes estimations et mes résultats s’accumule, et ce qui demandait autrefois plusieurs réunions se règle maintenant en dix minutes de conversation
Je suis aussi d’accord avec cet avis. Mais je pense qu’on peut aussi retourner la situation dans l’autre sens Par exemple, sur un chantier, quelqu’un peut inspecter et maintenir avec rigueur les systèmes de sécurité et ainsi éviter des accidents, sans que le management ne reconnaisse jamais cette valeur ni ne la récompense Le simple fait qu’un bénéfice ne soit pas reconnu s’il n’est pas quantifiable en ROI est en soi une énorme défaillance du management, et lorsque la sécurité touche à la vie humaine, c’est aussi une défaillance morale En pratique, c’est exactement ce qu’on voit aujourd’hui chez Boeing
L’essentiel, c’est de l’expliquer en termes de valeur compréhensible pour le public. C’est au fond une compétence commerciale, et je pense que la plupart des développeurs n’ont ni l’expérience ni les repères pour s’en rendre compte. L’idéal est d’avoir un bon manager qui soutient bien cela, et quand on travaille avec un staff dev ou un engineering manager qui partage cette façon de voir, les résultats peuvent être énormes Je ressens toujours beaucoup de gratitude quand je collabore avec ce type de collègues
Si l’on doit justifier la nécessité de se laver les mains pour obtenir un arbitrage d’investissement, il y a un problème quelque part dans l’équipe. Comme un chef de restaurant haut de gamme n’a pas à être convaincu d’acheter du savon, rejoindre une organisation où ce genre de choses va de soi me semble être une étape de carrière en soi. Un SWE qui a réussi travaille dans une équipe où ce niveau est la base
Je suis d’accord. Le refactoring fait naturellement partie des responsabilités d’un développeur. Si on le fait au fil du développement de fonctionnalités, avec mise à jour normale des échéances, il suffit d’en parler entre techniciens et c’est beaucoup plus facile à faire accepter ; à long terme, cela améliore fortement la qualité de la codebase. Le résultat, c’est une maintenance plus simple et un développement de nouvelles fonctionnalités plus rapide
Le plus grand capital politique que je puisse accumuler, c’est ma compréhension technique et mes compétences. Mais cette force n’est utile que si elle s’inscrit dans la stratégie globale de l’entreprise et son contexte, sous forme de conseils pertinents et de livraison réelle Si je donne les bons conseils et que j’agis pour l’entreprise, les gens m’écoutent et finissent par dépendre de moi. À terme, cela me donne le pouvoir d’orienter la direction Préparer une sorte de plan B de gestion du risque, puis le proposer et l’exécuter au moment opportun, me paraît être la meilleure approche
Il existe un livre sur la carrière assez brutal, mais qui contient de bons points L’un d’eux est que la compétence technique peut en réalité nuire à ma carrière et à mon pouvoir. Si je consacre mon temps et mon énergie à faire réellement avancer quelque chose, un manager compétent fera activement en sorte de me garder à mon poste afin que je n’acquière pas trop d’influence politique En revanche, si je deviens manager, il ne faut concrètement plus rien faire soi-même, mais lancer autant d’initiatives que possible (projets, politiques, changements) et orchestrer habilement le capital politique dont on dispose Peu importe que ces initiatives créent réellement de la valeur, ce n’est même pas un sujet à considérer. Moi, j’ai déjà quitté la table de jeu, et ceux qui restent ici à s’accrocher au succès réel et à la valeur concrète sont ceux qui prennent du retard Si nécessaire, le manager peut simplement récupérer le crédit après coup en disant que c’est lui qui l’a fait
Il faut des équipes dédiées à l’alignement tactique sur la "flavor of the month" pour que les choses avancent — voilà ma théorie politique. C’est pareil à Washington DC. Il n’y a pas de grand plan d’ensemble, juste une armée de gens toujours prête à pitcher dès qu’une occasion se présente
Si vous devez vous entraîner à la lutte politique et accumuler du pouvoir, il vaut mieux chercher une autre entreprise Vous pouvez penser que je suis naïf, mais toutes les entreprises ne sont pas comme ça. La mienne, par exemple, ne l’est pas