Ce que signifie vraiment « terminer le travail » dans une entreprise de la big tech

• Dans la big tech, vraiment terminer un travail signifie le mener jusqu’au point où l’entreprise en est satisfaite, puis passer à autre chose, dans un système améliorable à l’infini
• Un ingénieur compétent mais manquant d’initiative risque de répéter sans fin de petites améliorations et de passer à côté de vrais résultats
• Il faut livrer aux décideurs des résultats clairs et visibles pour être reconnu comme quelqu’un qui a vraiment « travaillé »
• Il faut toujours vérifier si ce que l’on fait est présenté sous une forme que les managers de haut niveau peuvent lire et évaluer
• On ne peut pas tout peaufiner, et à un certain stade, la capacité à « déclarer la victoire et partir » devient une compétence clé

---

Le « travail » a une nature qui ne peut pas être totalement achevée

• Contrairement à un problème de maths ou à un devoir, le travail dans le monde réel est un système ouvert améliorable à l’infini
• Développer un service ressemble à planter un arbre : c’est un processus qui demande une gestion continue

Le piège dans lequel tombe l’ingénieur compétent

• L’ingénieur qui assume tout lui-même et enchaîne seulement de petites améliorations continues a l’impression d’obtenir des résultats, mais
• du point de vue du management, cela peut être jugé comme une absence de création de valeur visible pour l’entreprise
• Au final, il peut être perçu à tort comme quelqu’un de très occupé mais sans résultats

Le vrai sens de « terminer »

• Amener le travail jusqu’au point de satisfaction de l’entreprise (des décideurs), puis passer à la suite
• Au lieu de continuer à refactorer ou à répéter de petites améliorations, il faut produire une liste claire de résultats
• La capacité à déclarer que « c’est terminé » et à passer au sujet suivant est essentielle

Rendre le travail « lisible »

• Les projets déjà connus des managers, ceux qu’ils ont demandés, ou les réponses à un incident majeur ont une forte lisibilité
• Par défaut, la plupart des tâches techniques ne sont pour les managers qu’un bruit technique difficile à évaluer
• Il faut donc mettre les résultats sous une forme visible ou souligner leur impact financier, autrement dit les rendre lisibles

« Terminer » est un concept social

• Philosophiquement, l’idée même d’avoir « terminé » est aussi une construction sociale, mais dans la réalité, elle a un pouvoir très concret
• L’ignorer peut empêcher d’être reconnu, et peut même finir par mener au licenciement

Résumé

• Travailler ne veut pas dire avoir terminé
• La plupart des tâches ne peuvent pas vraiment se terminer et peuvent se prolonger indéfiniment
• Il faut être non pas un jardinier, mais un tacticien orienté résultats
• Le critère du « c’est terminé » est la satisfaction de l’entreprise / du management
• Déclarer la victoire → partir → passer au travail suivant constitue la stratégie clé

[aer0700]

Choisir un travail suffisamment propice pour pouvoir déclarer victoire semble aussi être une compétence importante.

[elbanic]

On appelle cela le scoping : limiter le périmètre. Savoir bien scoper pour se mettre en position de réussir, c’est une vraie compétence.

[bakyeono]

Hanshin vs. Soha

[doolayer]

Des résultats visibles et quantifiables, pas des détails

[GN⁺]

Avis Hacker News

• Je ne suis pas totalement en désaccord avec la thèse de cet article, mais pour avoir travaillé dans la big tech, dans plusieurs startups et dans des licornes, je ne trouve pas que ce soit un conseil très concret. Ces dix dernières années, le travail des développeurs est devenu tellement spécialisé qu’il s’est éloigné des décideurs et des besoins des clients. Cela arrive parce que les Product Managers s’intercalent entre les ingénieurs et le reste de l’entreprise. J’essaie toujours de produire des résultats utiles, mais en pratique, cela exige d’accepter un stress permanent. Ma contribution est forcément remaniée après être passée par l’ego de la personne qui parle aux décideurs. Le seul moment où j’ai vraiment eu un sentiment d’accomplissement au cours des cinq dernières années, c’est quand j’ai assuré pendant neuf mois un rôle temporaire de Product Manager. Pendant cette période, notre équipe a mené à bien trois projets que d’autres équipes avaient déjà ratés plusieurs fois. Le secret, c’était de parler réellement aux parties prenantes pour comprendre leurs besoins, pas d’essayer de faire les choses à ma façon. Donc à l’avenir, je vais continuer à livrer uniquement ce qu’on me demande, à me faire reprocher les bugs, et à ne recevoir aucun crédit pour les fonctionnalités. Au moins, la rémunération est correcte. Je continue malgré tout à chercher un endroit où je pourrai vraiment contribuer

  • La partie « la rémunération est correcte » m’est particulièrement restée en tête. J’ai ma propre vision selon laquelle être « stagnant » dans la big tech n’est pas si terrible. Par exemple, si on gagne 300 000 dollars par an chez Google ou MS et qu’on passe dix ans sur le même projet ennuyeux, cette expérience reste reconnue partout. Quelqu’un d’ambitieux comme je l’étais autrefois peut le vivre comme une frustration, mais avec ce tempérament, on finit sans doute par rejoindre une plus petite entreprise. En vieillissant, mes priorités se sont déplacées de l’entreprise vers ma famille et mes amis. Si quelqu’un me disait qu’il n’y aura pas de promotion, je répondrais « et alors ? ». Je gagne assez pour ma famille et je préserve mon équilibre entre vie pro et vie perso. Franchement, le mieux dans l’entreprise, c’est le salaire et le fait qu’il améliore le reste de la vie
  • J’ai constaté que le poste de Product Manager, dans la réalité, correspond mal à la description idéale qu’on en fait, et que la personne au milieu représente mal les deux camps. Du coup, j’ai développé moi-même des compétences en gestion de produit, et ces compétences sont vraiment utiles pour éviter de perdre son temps. Ça me fait me demander si, pour être un grand ingénieur, le product management ne devrait pas aussi être une compétence indispensable
  • Un autre point à garder à l’esprit, c’est qu’en continuant comme ça, on est sur la voie du burn-out
  • J’ai compris que la communication est le meilleur ensemble de compétences dans n’importe quelle organisation. Neuf mois en poste temporaire ne suffisent pas pour en mesurer toute la valeur. Le texte donne surtout l’impression, comme chez d’autres ingénieurs, d’une personne très agacée qui pense être plus intelligente que les autres dans l’organisation. En réalité, c’est souvent faux, et ce genre d’état d’esprit nuit à la collaboration
  • Derrière toute application web qui fonctionne bien, il y a toujours quelqu’un qui fait un travail de jardinier
  • Je me demande pourquoi il n’a pas continué comme Product Manager
  • Ça dépend énormément des entreprises. Dans beaucoup d’endroits, les ingénieurs ont bien plus d’influence. Même dans la big tech, il existe des cas où ils ne sont pas coupés des clients
  • Est-ce que ça veut dire qu’il faut licencier les Product Managers ?
  • J’ai aussi exercé ce rôle de Product Manager, c’est-à-dire faire l’intermédiaire entre les ingénieurs et l’entreprise, et ma propre contribution passait elle aussi par le filtre de mon ego — à t’entendre, ça avait l’air plutôt satisfaisant… ça a dû être un travail assez gratifiant

• Je m’oppose fondamentalement à l’idée que la réussite se mesure uniquement au fait de satisfaire les puissants. Nous sommes certes pris dans des structures de statut ridicules, mais je ne pense pas que tout se résume à passer un ticket Jira en « Done » ou à faire disparaître des avertissements du compilateur. Personne ne se dit « je ne regrette rien, j’ai passé 40 ans à satisfaire mon chef à chaque fois »

  • Cela fait 30 ans que je travaille sur 40, et il y avait clairement de la valeur à satisfaire mon chef et le chef de mon chef. Même si une vision cynique n’est pas toute la vie, connaître ce point de vue cynique, c’est se rapprocher de la vérité
  • En réalité, je pense que « satisfaire son chef et le chef de son chef » correspond à la définition même de l’emploi. On fait ce que quelqu’un nous demande et on est payé pour ça

• Globalement d’accord, mais j’ajouterais une chose : pour comprendre ce que veut son manager, il faut comprendre la structure business de l’entreprise. Il faut absolument savoir par soi-même comment l’entreprise gagne de l’argent et ce qu’elle considère comme précieux. Quand on travaille dans un endroit aligné avec ses valeurs, la rémunération est meilleure et la satisfaction aussi. Il est important de rencontrer directement les clients, bien sûr, mais aussi les ventes, le marketing, et, autant que possible, les dirigeants. Même si on travaille seulement sur des systèmes internes, il est essentiel de savoir où ces systèmes créent ou protègent de la valeur. Si votre service ne crée pas clairement de valeur, il faut envisager de rejoindre une équipe qui en crée. Travailler à contre-courant des besoins de l’entreprise a toujours été une grosse erreur

  • Je pense qu’on peut très bien se considérer comme un menuisier. Le développement consiste à implémenter selon la spec, mais si cette spec est absurde ou irréalisable, il faut le signaler directement. Si le côté business n’est pas capable d’expliquer clairement son besoin, c’est qu’il ne le comprend pas lui-même. Et si, en plus, on attend vraiment des développeurs qu’ils maîtrisent aussi le business, alors cela doit absolument être rémunéré. Il y a aussi un coût d’opportunité : pendant ce temps, on pourrait progresser techniquement
  • L’hypothèse selon laquelle « le manager va réellement comprendre le business et s’en soucier » ne tient souvent pas

• L’auteur dit qu’il faut « produire des résultats visibles pour les décideurs », et je partage cet état d’esprit très orienté « business ». Beaucoup de développeurs peinent parce qu’ils ne savent pas expliquer l’utilité business de leur travail. Le refactoring en fait partie. Améliorer du code peut sembler n’avoir aucun intérêt à court terme, mais selon le contexte, cela peut produire d’énormes bénéfices pour l’organisation. Au fond, l’essentiel est de réfléchir à la manière de relier son travail aux revenus ou aux économies de l’organisation, et de savoir le communiquer

  • Les développeurs doivent apprendre le langage du business et formuler les problèmes d’une manière que les gens du business comprennent et jugent importante. La plupart des décisions business se résument à coût contre bénéfice. En pratique, beaucoup de gens du business considèrent aussi le logiciel comme un centre de coût. Autrement dit, contrairement à l’idée qui semble évidente pour les développeurs — « comment le logiciel pourrait-il ne pas être au cœur de la création de revenus ? » — le business ne s’intéresse pas au logiciel en lui-même. S’ils pouvaient vendre gratuitement, tous les coûts seraient à 0, donc la marge serait infinie : c’est ce que pensent vraiment les gens du business. La vente est un domaine où l’ambiance, les relations, voire les pots-de-vin, comptent parfois plus que la rationalité. Même si cela paraît irrationnel, il faut absolument le comprendre

• Je me demande si cet état d’esprit n’explique pas pourquoi tant d’ingénieurs ne se soucient pas de la qualité du code, des tests ou de la documentation. Si l’on ne pense qu’à satisfaire immédiatement les personnes haut placées, qui va s’efforcer d’écrire du code maintenable sur la durée ? On n’a peut-être pas besoin d’une qualité au-delà des standards, mais même un investissement minimal peut faire économiser des milliards

  • De plus en plus de gens ne se soucient ni du travail bien fait ni de la qualité. On entend souvent « je fais juste ce pour quoi je suis payé ». Autrefois, il y avait l’idée qu’on faisait son travail consciencieusement, indépendamment du salaire ; cette mentalité semble s’être largement perdue
  • Chacun a ses raisons de tenir son rôle. Comme sur un plateau de tournage, les ingénieurs peuvent avoir des objectifs différents. Si on empêche les ingénieurs d’exprimer leur passion, il ne restera plus que des gens motivés par l’argent. C’est risqué
  • Je ne pense pas qu’il y ait des gens qui écrivent délibérément du mauvais code. Quand l’indifférence ou le burn-out apparaissent dans un environnement où les efforts répétés ne sont pas récompensés, plus personne ne fournit d’effort supplémentaire. Et beaucoup de développeurs ont aussi, tout simplement, un niveau assez faible. Ce n’est pas une profession aussi hautement compétitive qu’actuaire, donc on peut y entrer avec n’importe quel parcours, et il est difficile d’y devenir vraiment bon au départ
  • Beaucoup de Product Managers ne veulent qu’une chose : aller vite. Nous voulons des tests et de la documentation, mais les CFO considèrent souvent ce travail annexe comme inutile sous prétexte que « ce n’est pas une fonctionnalité »
  • On part du principe que l’ingénieur ne restera pas longtemps dans l’entreprise, donc il ne se sent pas responsable du futur. Quand on change d’emploi en permanence, on ne subit jamais soi-même les problèmes du code qu’on a écrit dans son poste précédent ; on ne vit donc pas l’échec, et on le répète. Moi, cela fait presque 20 ans que je suis dans la même entreprise, et j’ai vu les mêmes erreurs se répéter sans cesse. Je suis aussi lassé des changements purement superficiels qui laissent les problèmes de fond intacts. Tant qu’on ne corrige pas les vrais problèmes, le changement n’a aucun sens. Mon objectif, c’est de résoudre les vrais problèmes

• J’ai souvent vécu cette réalité et ces problèmes, je les comprends, mais je continue à m’y opposer. Beaucoup de projets sont lancés, puis on annonce « problème résolu, done ! » et l’équipe est dissoute. Mais le produit a toujours des problèmes, il faut encore ajouter des fonctionnalités, et l’entreprise continue d’évoluer. Au final, on ne fait qu’accumuler de la dette technique à cause d’une mauvaise gestion. Un nouveau manager arrive, relance l’ancien projet et refait exactement les mêmes erreurs. Cette manière de faire est inefficace. Si on prend l’analogie de la climatisation, maintenir une température constante est plus efficace que l’éteindre puis la redescendre à chaque fois. En pratique, l’outil de gestion que j’ai créé n’intéressait pas la direction, mais il était suffisamment nécessaire pour être utilisé par plus de 500 personnes en interne. Il était important de conserver cette confiance dans le temps, sans y consacrer énormément de maintenance. Si on l’abandonne, tout se disperse et l’outil perd sa fiabilité. Quelques minutes suffisaient pour garder de la cohérence

  • L’analogie de la climatisation est en fait fausse du point de vue thermodynamique. L’éteindre puis refroidir à nouveau est plus efficace

• J’ai des sentiments mitigés à plusieurs égards. Il est clair que ce texte a raison sur la visibilité et les promotions, mais dans les faits, c’est un conseil centré sur les managers : il suffirait de les satisfaire. Mais que se passe-t-il si aucune direction claire n’est donnée et que les priorités changent sans cesse ? Il devient difficile de produire des résultats utiles, et la relation manager-subordonné se transforme entièrement en système de « yes-man ». Le résultat n’est pas très bon

  • La solution est simple. Si vous avez l’impression de travailler sous les ordres d’un chef idiot, partez. La souffrance est temporaire, et au final, la situation s’améliore. C’est bien mieux que de perdre son temps à expliquer son travail à un imbécile
  • À l’inverse, quand on travaille avec un très bon manager, le simple fait de « satisfaire son manager » peut faire progresser rapidement à la fois sa carrière et ses résultats

• Un « unagentic engineer », c’est un ingénieur sans autonomie. Si un ingénieur travaille de cette façon, cela peut conduire à de l’inefficacité et à des problèmes graves comme des coûts cloud excessifs, des incidents de sécurité ou des plaintes clients. Parmi les exemples de travail qui ne se termine jamais, on peut citer les correctifs de sécurité, la correction des erreurs, l’optimisation des coûts et la prise en compte des retours clients. Si l’entreprise ne comprend pas la valeur de tout cela, il faut changer d’emploi

  • C’est précisément le propos du texte. Certaines organisations sont centrées sur la réalité, d’autres sur le statut. Les organisations centrées sur la réalité sont rationnelles à long terme, tandis que les organisations centrées sur le statut n’ont qu’un seul but : satisfaire le chef. La qualité du produit ou la relation client comptent moins que la hiérarchie. Ce type d’organisation n’a pas forcément besoin de s’effondrer, mais il peut aussi s’écrouler d’un seul coup
  • « Unagentic » désigne un employé sans agency, sans autonomie. On aimerait qu’il fasse preuve d’initiative, mais en pratique, c’est un piège où le développeur finit par rendre sa propre existence invisible
  • Ce n’est pas forcément obligé d’être ainsi, mais si les dirigeants ne s’en soucient pas, cette culture s’installe par défaut. Par exemple, j’aime me concentrer sur les détails de l’interface design. Mais ce soin n’est récompensé que lorsqu’il est reconnu comme une valeur par l’organisation. Dans beaucoup d’endroits, personne n’y prête attention
  • Un « unagentic engineer » désigne un profil qui manque de capacité à prendre des décisions et à faire avancer les choses de sa propre initiative, quelqu’un qui se laisse simplement porter par le courant
  • Cela désigne un ingénieur non autonome, c’est-à-dire avec peu de marge de jugement
  • Cela veut dire qu’il n’a pas de « high agency » : même s’il a l’air intelligent et compétent, il attend toujours des instructions et ne prend pas les choses en main de lui-même

• Je déteste profondément les buzzwords comme « alignment ». Mais cela reste, au fond, un concept important. Idéalement, moi, mon manager et même les dirigeants au-dessus devrions être d’accord sur ce qui est le plus important. Si ce n’est pas le cas, c’est un problème du point de vue de quelqu’un qui appartient à cette organisation. Que ce soit juste ou équitable importe peu : nous vivons en nous y adaptant. Au final, faire ce qu’on nous dit de faire est la raison pour laquelle nous sommes payés. Très peu de gens ont le privilège d’influencer ceux d’en haut. C’est ce qu’on appelle le « managing up »

• Le texte original est utile, mais il me semble qu’il manque des points encore plus importants :

  • travailler dans la bonne équipe est plus important que faire le bon travail
  • avoir un bon PM et un bon manager est plus important qu’avoir de bonnes tâches
  • une bonne chaîne de reporting compte plus que la valeur du résultat
  • le travail aligné avec les objectifs du leadership est bien plus valorisé que le soutien réel au fonctionnement du business
  • il faut toujours être prêt à tout faire soi-même, et la politique des grandes entreprises crée toujours des désincitations à la collaboration

[heal9179]

Ces avis touchent au contraire plus juste sur l’essentiel.

[roxie]

C’est clair haha