D’ingénieur à manager : ce que j’aime et ce que je n’aime pas

• Après 7 ans comme développeur front-end, l’auteur est devenu team lead puis engineering manager à plein temps : son impact sur le produit et l’équipe a grandi, mais la nature du travail a profondément changé
• Un manager peut intervenir, avec une autorité formelle et informelle, sur des problèmes qu’il était difficile de faire évoluer en tant qu’IC, comme l’écriture de tests, l’amélioration des processus ou l’ajustement de l’ambiance d’équipe
• Sur le long terme, ce parcours offre une rémunération plus élevée que les postes d’ingénieur généralistes, plus d’opportunités que les rôles d’IC staff+, et des compétences transférables vers d’autres domaines techniques, la gestion de projet, le product management ou la création d’entreprise
• En contrepartie, il faut appliquer des procédures très corporate comme les évaluations de performance, les deadlines déraisonnables ou les politiques internes, tout en assumant directement les conflits, l’insécurité psychologique et la pression d’être constamment disponible
• Le travail de management s’inscrit dans des boucles de feedback longues : les résultats apparaissent rarement en moins d’un mois, et même de bons changements — comme une scission d’équipe ou un recrutement — peuvent empirer la situation à court terme

---

Le passage d’ingénieur à manager

• Il y a environ 2 ans, l’auteur est passé team lead, puis est devenu engineering manager à plein temps après l’agrandissement de l’équipe
• Avant cela, il avait travaillé 7 ans comme développeur front-end, en choisissant d’abord une trajectoire de carrière d’IC senior avant de basculer vers le management
• La transition a été cahoteuse mais intéressante, et son poste actuel comporte à la fois des aspects qu’il aime et d’autres qu’il n’aime pas

Ce que j’aime dans le rôle de manager

• Le pouvoir de faire évoluer le produit et l’équipe

  • Devenir manager donne le pouvoir d’améliorer l’état global du produit et de l’équipe
  • En tant qu’IC, il peut être difficile de faire bouger des problèmes comme les stand-ups trop matinaux, la faible qualité du code ou des nouvelles fonctionnalités difficiles à comprendre
  • Un EM peut, via son autorité formelle et informelle, orienter l’équipe vers de meilleures façons de travailler
  • Dire « il faut écrire des tests » n’a pas le même poids selon qu’on est IC ou EM, et la parole d’un EM peut effectivement se traduire par l’écriture de tests

• Des opportunités de carrière plus larges

  • Le poste d’engineering manager ouvre des opportunités de carrière plus larges qu’un parcours d’ingénieur classique
  • Un EM est en général mieux rémunéré que les niveaux d’ingénieur d’équipe plus standards comme junior, middle ou senior
  • Il existe aussi des niveaux d’IC plus élevés, comme staff ou principal, avec des rémunérations comparables ou supérieures à celles d’un EM
  • Mais les postes d’IC staff+ sont surtout concentrés dans les grandes entreprises technologiques avec des défis techniques plus complexes, alors que presque toutes les équipes logicielles ont des postes de leadership
  • L’échelle de carrière en management monte plus haut que celle des IC
  • Même si devenir CTO reste peu probable, cela ouvre des options inexistantes pour un pur IC sans expérience de management
  • La demande en EM est plus stable que celle en ingénieurs staff+, et offre davantage d’opportunités en seconde partie de carrière

• Des compétences plus faciles à transférer vers d’autres domaines

  • Les compétences de management sont utiles dans un spectre plus large que celles d’un poste d’ingénieur IC spécifique
  • Un ingénieur front-end expérimenté en React peut passer à un autre framework front-end, ou se reconvertir vers le back-end ou le mobile au prix d’un léger recul de niveau
  • Avec de l’expérience en engineering management, il est plus facile de prendre en charge des équipes aux focales différentes, comme une équipe de développeurs mobile, d’infrastructure ou d’ingénierie ML
  • Il faut du temps pour comprendre les grandes difficultés techniques d’une nouvelle équipe, mais beaucoup d’entreprises acceptent ce type de transition
  • Si l’on ne veut plus continuer comme EM, on est bien placé pour passer vers la gestion de projet ou le product management
  • Même si tout le marché tech ralentit, beaucoup de compétences de management restent utiles dans d’autres secteurs
  • L’expérience acquise au contact des personnes et des décisions business est aussi une bonne préparation à la création d’entreprise

• Des connaissances qui se périment moins vite

  • Si suivre les derniers frameworks et outils front-end est fatigant, un rôle de management peut alléger ce fardeau
  • Les méthodes « nouvelles » comme agile, kanban ou scrum reposent en réalité sur des concepts vieux de 20 à 30 ans, et les formats de réunion de base comme les démos, les daily ou les 1:1 ont eu le temps d’évoluer
  • Le cœur du management repose sur le travail d’équipe et les interactions humaines, des dimensions qui ont peu changé depuis les débuts de l’humanité
  • Il faut toujours surveiller les évolutions techniques, mais il est moins souvent nécessaire d’entrer d’urgence dans les détails

• Un nouveau défi au-delà des problèmes techniques familiers

  • Après 4 à 5 ans dans un domaine technique donné, on devient généralement capable de résoudre l’essentiel des problèmes concrets du métier
  • Les façons, pour un ingénieur expérimenté, de trouver des défis plus grands ont leurs limites
  • Changer légèrement de stack, par exemple avec un nouveau framework front-end, suffit rarement à maintenir l’intérêt sur la durée
  • Un changement plus important, comme passer du front-end au back-end, peut apporter quelques années stimulantes, mais relève souvent du hasard ou peut affecter la rémunération
  • Se créer soi-même des problèmes, par exemple en réécrivant tout avec une nouvelle librairie ou en cherchant à gérer 9000 RPS « pour l’avenir », peut être amusant mais nuit souvent à l’équipe et au business
  • Pour un ingénieur expérimenté, passer au management est ce qui apporte le plus de nouvelles choses à apprendre sans réduire la rémunération

Ce que je n’aime pas dans le rôle de manager

• Il faut appliquer des procédures corporate

  • Quand il était ingénieur, l’auteur détestait déjà les évaluations individuelles de performance, les deadlines inutiles et les restrictions imposées par l’entreprise sur les processus ou la stack technique — tout ce BS corporate
  • En devenant manager, on devient la personne qui applique ces pratiques, qu’on y croie ou non
  • Dans les organisations avec calibration des performances, un team lead doit tous les 6 mois désigner une personne qui n’aurait pas assez travaillé
  • Si l’on ne fournit pas un membre de l’équipe à sacrifier, quelqu’un risque d’être choisi aléatoirement plus tard dans le processus, ce qui rend la procédure difficile à supprimer
  • Certaines procédures peuvent être négociées ou contournées ; par exemple, il est possible d’attribuer à tour de rôle une mention « performance en dessous des attentes »
  • Du point de vue de l’équipe, le manager peut parfois apparaître comme un monstre corporate
  • L’auteur n’a pas encore eu à gérer des situations plus dures comme des licenciements, des fermetures ou des réorganisations

• Il faut gérer les tensions entre les personnes

  • À l’origine, l’auteur est devenu engineering manager parce qu’il savait bien construire des choses, et il s’attendait à aider sur les décisions techniques, les conseils de carrière, l’ajustement des processus et l’automatisation
  • En réalité, une grande partie du travail consiste à déboguer les tensions sociales et l’insécurité psychologique entre les personnes
  • Exemples :
    • Un ingénieur junior commente quelques tests pour pouvoir déployer un aperçu de fonctionnalité
    • La personne en charge de la QA se met très en colère, estimant que l’équipe ne respecte ni le rôle ni la valeur de la QA
    • Le manager doit rétablir la confiance
  • Autre exemple :
    • Un chef de projet fait une blague ratée, et une designer, blessée, se met à pleurer
    • Le manager doit faire en sorte que le PM présente ses excuses
  • Comme l’auteur n’est ni psychologue ni particulièrement doué avec les gens, cette partie est difficile et ressemble surtout à une épreuve d’endurance jusqu’à ce qu’on s’y habitue

• Un travail où il est difficile d’être vraiment hors ligne

  • La vie d’un ingénieur peut être relativement détendue
  • S’il n’y a rien d’urgent, on peut passer une demi-journée dehors à réfléchir à l’avenir du projet, et même manquer quelques réunions à la dernière minute sans que ce soit dramatique
  • Si un EM s’absente quelques heures, les problèmes s’accumulent dans la messagerie
    • Un stagiaire a oublié comment faire npm install et ne peut plus avancer
    • Un senior manager veut discuter d’une fonctionnalité potentielle
    • Une release déraille
  • Les réunions qu’on anime ou qu’on doit organiser sont difficiles à sauter sans préparation
  • La situation peut s’améliorer si l’équipe gagne en maturité et si les processus deviennent meilleurs, mais en général le manager ressent beaucoup plus fortement les heures de permanence
  • L’équilibre vie pro / vie perso dépend alors directement de sa capacité à bien faire son travail

• Des boucles de feedback longues et non linéaires

  • La plupart des tâches d’ingénierie donnent des résultats visibles assez vite
  • Une nouvelle fonctionnalité produit des effets en quelques semaines ou quelques mois, corriger un bug permet de voir les réactions des utilisateurs dès le lendemain
  • Un refactoring permet de constater une baisse de complexité en quelques heures
  • Les actions d’un manager produisent très rarement des résultats visibles en moins d’un mois
  • Si l’équipe est devenue trop grande et qu’il faut la scinder, il faut passer par de nombreuses étapes
    • définir une composition pertinente des ingénieurs pour la nouvelle équipe
    • parler avec les personnes concernées de leurs sentiments face au changement
    • mettre en place de nouvelles réunions récurrentes
    • définir les processus et la communication
    • traiter les tâches liées à Jira
    • dans certains cas, séparer la codebase d’un sous-produit
  • Penser que tout cela peut être réglé en une semaine est une erreur
  • Même les bons changements peuvent empirer la situation avant de l’améliorer
  • Si l’équipe manque de monde et qu’on décide de recruter, le court terme est souvent plus difficile : les entretiens prennent beaucoup de temps, et les nouveaux arrivants ont besoin d’onboarding avant d’être productifs
  • Les changements de management ressemblent davantage à un refactoring à grande échelle qu’à une résolution rapide de problème, ce qui peut être frustrant quand aucune amélioration immédiate n’est visible

À ceux qui envisagent la transition

• Passer d’ingénieur IC à un poste de management ressemble à des montagnes russes, avec ses aspects lumineux et ses aspects sombres
• Les avantages : un impact plus large sur le produit et l’équipe, plus d’opportunités et de flexibilité sur le long terme, et un nouveau défi lorsqu’on commence à s’ennuyer dans la technique
• Les inconvénients : devoir appliquer les politiques de l’entreprise, gérer les tensions sociales et l’insécurité psychologique, avoir du mal à être hors ligne, et supporter une gratification très différée avec des boucles de feedback longues
• Si l’on aime les défis et les responsabilités, et que l’on en a l’occasion, cela vaut la peine d’essayer
• Le management ne convient pas à tout le monde, mais c’est une expérience qui peut élargir son spectre technique et faire voir le travail d’ingénierie sous un autre angle
• Et si cela ne convient pas du tout, il sera toujours temps de revenir au code

[GN⁺]

Avis de Hacker News

• J’ai été manager quatre fois, dont deux chez des FAANG, mais je suis en désaccord avec une grande partie du texte original.
  L’échelle managériale n’est pas réellement plus élevée, et la plupart des engineering managers se concentrent autour de l’équivalent L6/staff engineer. Les promotions au-delà de senior manager dépendent énormément du contexte et sont rares, tandis que les collègues sur la filière ingénieur sont promus quand ils sont prêts, sans attendre que les astres s’alignent.
  Les personnes licenciées après avoir été de purs engineering managers cherchent souvent encore un poste et sont près d’abandonner, alors que celles qui acceptent de revenir à un rôle d’IC n’ont pas de gros problème pour retrouver du travail. Les cultures managériales varient énormément d’une entreprise à l’autre et se transfèrent difficilement ; selon moi, la compétence la plus transférable dans ce secteur, ce sont les internes de Linux.
  L’idée qu’avec 5 ans d’expérience on peut résoudre la plupart des problèmes me paraît aussi étrange. Même après 18 ans de métier, il y a encore beaucoup de choses que j’ignore et dans lesquelles je dois progresser, et d’excellents ingénieurs avec 40 ans d’expérience continuent d’apprendre.
  Le meilleur côté du rôle de manager, c’est qu’on passe beaucoup de temps à penser à l’avenir et qu’on a davantage de chances d’entrer dans « la salle » où l’on parle avec les dirigeants C-level. Mais c’est aussi le pire côté, parce qu’on voit beaucoup trop bien comment les décisions se fabriquent.
  Je suis d’accord avec les aspects que l’auteur original n’a pas aimés, mais cela s’améliore avec le temps. Cela dit, un nouveau manager n’a peut-être pas encore vécu ce qu’il finira par détester le plus : dans beaucoup d’entreprises, le management supérieur se comporte comme des clans de lycée, et les problèmes de comportement de VP, de C-level, voire parfois de directeurs, sont tolérés alors qu’ils vaudraient un licenciement à un employé ordinaire.

  • Dire que « les collègues sur la filière ingénieur sont promus quand ils sont prêts » ressemble à une anecdote mêlant biais de confirmation et biais du survivant.
    La plupart des ingénieurs logiciel restent bloqués au niveau senior, surtout chez Google ; se retrouver autour de L6 est donc déjà relativement privilégié. Les promotions L6 ne sont pas extrêmement rares, mais elles ne concernent pas non plus une majorité, et L7 ou plus est difficile. Si l’on a l’impression que la plupart de ses collègues y arrivent naturellement, c’est peut-être qu’on exclut ceux qui sont partis faute de promotion, ou qu’on a eu peu d’occasions de se lier avec des personnes de niveaux inférieurs au sien.
    Je suis d’accord pour dire que la voie engineering manager n’ouvre pas autant de portes que les gens le pensaient autrefois, mais les possibilités de promotion ne me semblent pas plus étroites que pour les IC.
  • J’ai aussi trouvé étrange que le texte original voie le rôle d’engineering manager comme une bonne voie vers l’entrepreneuriat.
    Construire quelque chose de 0 à 1 n’a presque rien à voir avec le management d’ingénierie. Les capacités les plus importantes sont de coder vite et de parler à l’aise avec des clients potentiels, et aucune des deux n’est directement liée au rôle d’engineering manager. Il n’y a pas non plus de garantie qu’on recrutera des personnes à manager.
    Les postes de management sont structurellement beaucoup moins nombreux que les postes d’ingénierie, et la frontière entre lead engineer et manager de première ligne est assez floue dans les deux sens, donc le vivier réel de concurrents ne se réduit pas d’autant.
  • Je n’ai jamais travaillé dans une grande entreprise tech, ni avec des IC au-delà du niveau staff. Les promotions principal ou fellow doivent aussi être assez rares, et la plupart des entreprises « ordinaires » n’ont même pas de tels grades.
    Quand je parle de transférabilité, je veux dire des compétences utiles aussi en dehors de la bulle des grandes entreprises tech. L’argent peut donner envie de ne pas en sortir, mais il est bon de savoir qu’on peut faire autre chose que faire biper des ordinateurs.
  • Je suis rassuré de ne pas être le seul à penser que les internes de Linux sont la compétence la plus transférable.
  • Là où mon expérience différait du texte original, c’était peut-être davantage lié aux caractéristiques de l’endroit où la personne travaille qu’à des différences intrinsèques entre les rôles.
    Par exemple, l’idée selon laquelle « il faut faire plus de tests » serait prise plus au sérieux venant d’un engineering manager que d’un IC.
    En fait, quand je venais d’être promu IC niveau staff, j’avais moi aussi l’impression de manquer de crédibilité, et j’ai envisagé de passer au management en pensant que me cacher derrière un titre aiderait. En réalité, ce n’était pas nécessaire, et aujourd’hui, en tant qu’IC dans une autre entreprise, mes idées et mes retours sont pris au sérieux à l’échelle de l’organisation comme par mes collègues.
    Un système qui impose de classer les gens chaque semestre pour désigner des low performers est dysfonctionnel. La gestion de la performance dans beaucoup d’endroits a cette triste réalité, mais ce n’est pas une vérité universelle selon laquelle un manager devrait forcément faire cela. Les conversations difficiles sur de vrais problèmes de performance sont statistiquement inévitables, mais il existe aussi des entreprises où l’on n’a pas à dire « ce semestre, tous les membres de l’équipe ont fait mieux que toi » ou « il fallait choisir quelqu’un, et cette fois c’est tombé sur toi ».

• J’aime la résolution de problèmes et la vision d’ensemble, et j’aime trouver des solutions pour lever les obstacles. Le rôle qui me convenait le mieux était celui d’« architecte », même si l’intitulé semble être en train de disparaître. Cela ne change rien au fait que ce travail reste nécessaire.
  J’ai aussi occupé des rôles de team lead/manager, Scrum Master et product manager, mais les compétences nécessaires à un bon manager sont très différentes de celles d’un ingénieur. Le point clé est d’avoir un niveau de névrosisme extrêmement bas, c’est-à-dire la capacité à prendre de bonnes décisions sous stress prolongé tout en conservant une apparence calme et rationnelle.
  90 % des managers de premier niveau n’ont pas cette caractéristique et, sous stress, ils abîment leur équipe et l’entreprise. Si vous voulez devenir manager, vous devez évaluer honnêtement votre réaction à un stress durable : est-ce que vous vous emportez contre les gens autour de vous, est-ce que vous vous cachez ou vous vous figez au point de ne plus décider, est-ce que vous rejetez la faute sur les autres pour protéger votre réputation ? Ces facteurs qui paraissent ennuyeux sont en réalité ce qui distingue les managers efficaces des autres.

  • Ce résumé est vraiment excellent. C’est pour ça que le management me semble assez proche de l’éducation d’un enfant. Un bon manager doit être capable de jouer le rôle de l’adulte.
    Cela implique souvent les tâches ingrates que tout le monde évite : mettre les problèmes sur la table, laisser les gens se plaindre collectivement de mes décisions, continuer à s’impliquer même quand l’autre se désengage et repousse le contact.
    Pour moi, le management donnait l’impression de demander toutes les cuillères que j’avais, puis d’en demander encore davantage. Cela dit, je pense que c’est plutôt un problème d’adéquation avec moi que l’essence même du management. D’après les questionnaires en ligne, je suis dans la moyenne en névrosisme, mais j’ai du mal à m’arrêter à « suffisamment bien », et l’élargissement du périmètre de responsabilité du management me donne l’impression de créer un problème de passage à l’échelle sur le plan émotionnel.
  • Les managers les plus efficaces avec lesquels j’ai travaillé venaient de pays calmes et peu stressants, avec une culture de travail similaire.
    La clé pour résoudre le crunch et le burnout est peut-être de créer un environnement réglementaire où toute la subsistance des travailleurs — santé, loyer, remboursement des prêts étudiants pour l’université publique, etc. — ne dépend pas uniquement du fait de conserver un emploi.
  • D’après mon expérience, la plupart des « personnes qui voient la vision d’ensemble » se contentent souvent de parler sans savoir ce que signifient leurs propos, quelles en sont les conséquences, comment les exécuter, ni pourquoi c’est une mauvaise idée.
  • Je suis aussi un résolveur de problèmes généraliste assez similaire, et je suis arrivé à la même conclusion après avoir fait du management pendant un peu plus d’un an. La compétence clé, c’est la résilience au stress.
    En tant qu’IC, on peut faire évoluer sa carrière en apprenant une nouvelle technologie ou un nouveau domaine, mais pour un manager, le développement de carrière finit de plus en plus par dépendre de la croissance personnelle : maturité, prise de recul, résilience émotionnelle. C’est peut-être aussi pour cela que l’ancienneté va souvent de pair avec un intérêt croissant pour des choses comme la méditation de pleine conscience.
    HN va détester ça, mais même si je suis célibataire, je me demande si les parents ne deviennent pas de meilleurs managers. Peut-être parce qu’ils sont moins susceptibles de perdre le sens des proportions et de stresser pour des choses qui n’ont pas d’importance dans le grand schéma des choses. Curieusement, j’ai l’impression que l’on manage mieux quand on prend un certain recul émotionnel.
    J’ai fini par comprendre que je suis assez sensible par tempérament, et je m’inquiète personnellement de ne pas être constitutionnellement fait pour le management. Le côté parfois hypocrite du type « il ne s’agit pas de contrôler, mais de motiver » est aussi difficile. J’aimerais simplement circuler dans l’organisation pour corriger des problèmes, simplifier les processus et repenser les systèmes de travail.

• Cela fait 12 ans que je suis ingénieur logiciel, et je n’ai absolument aucune envie de devenir manager. Je veux juste construire des choses, pas gérer des gens.
  Je travaille de près avec des managers et je vois en quoi consiste leur travail, mais cela ne m’attire pas du tout. En tant qu’ingénieur senior, ce que je dis a souvent de l’influence, mais sans l’énorme responsabilité qui pèse sur un manager, et ça me convient. Je n’ai pas envie d’ajouter du stress à ma vie.
  Il est probable que les 30 prochaines années de ma carrière se déroulent au même poste qu’aujourd’hui.

  • L’importance accordée à la parole d’un ingénieur senior dépend énormément du management. Votre situation actuelle est peut-être bonne, mais elle peut changer.
    Il y a quelques années, j’étais dans une situation similaire. Mon supérieur m’appréciait, avait beaucoup de contacts, partageait toutes les informations avec moi, m’invitait aux décisions, me demandait mon avis sur l’orientation à prendre et me disait qu’il me soutiendrait en coulisses si je devais parler en son nom ou au nom d’autres managers.
    Aujourd’hui, une structure de management entièrement nouvelle est arrivée : très descendante, très orgueilleuse et peu disposée à accepter les retours. Les managers de niveau inférieur ou les ingénieurs qui s’exprimaient ont été progressivement écartés, et l’autonomie comme la voix que j’avais ont presque disparu.
    On m’a même retiré beaucoup de choses que je considérais comme des décisions d’ingénierie. J’avais besoin de X pour un service que je construisais, j’ai créé une solution automatisée qui fonctionnait bien, puis quelques mois plus tard on m’a dit que j’avais eu tort parce qu’il existait un autre plan pour X, et on m’a ordonné de supprimer la solution entièrement automatisée pour la remplacer par un processus d’entreprise manuel d’une autre équipe. Cette tâche est souvent oubliée, ce qui dégrade la fiabilité de mon service.
    Je suis content de ne pas être le manager qui doit se battre contre ces gens-là. Si c’était le cas, j’aurais probablement déjà perdu mon poste et été remplacé par un de leurs amis. Cela dit, l’influence d’un ingénieur senior peut énormément varier à long terme, même au sein de la même entreprise et de la même équipe.
  • Les managers construisent aussi quelque chose. Leur outil, ce sont les ingénieurs.
  • Ingénieur senior reste un rang assez bas. Un jour, vous pourriez vous lasser d’un salaire qui stagne et du fait de continuer à recevoir des ordres.
    Il existe aussi des postes techniques plus élevés avec peu ou pas de responsabilités managériales : senior principal engineer, architecte, etc., selon la valeur que l’entreprise vous accorde.
    Le meilleur exemple que j’aie vu était un ingénieur titulaire d’un doctorat et de plusieurs décennies d’expérience, qui travaillait comme gourou recherche/architecture, utilisait beaucoup Matlab, n’avait ni équipe ni subordonnés directs, et était « VP of technology » dans une entreprise de plusieurs centaines de personnes.
  • J’ai été manager de notre équipe pendant 6 mois ; au final, ce n’était pas si terrible, mais c’est un métier complètement différent. Je redeviens IC le mois prochain, et ce sera probablement ma première et dernière expérience de management en 15 ans de carrière.
  • La bonne conclusion n’est pas « ne devenez jamais manager », mais plutôt de ne pas devenir un manager d’entreprise chargé de gérer la vision de quelqu’un d’autre.
    Ce qui est difficile, ce n’est pas seulement l’apprentissage ou les personnes, mais tout le contexte autour. Avoir une perspective de management aide énormément à comprendre quoi construire et pourquoi, ainsi que pourquoi le travail paraît inefficace et cassé. On gagne aussi des intuitions sur les solutions et sur le contexte qui n’est pas correctement transmis.

• Je suis actuellement développeur senior et je passe des entretiens pour un poste de team lead dans une startup. Je pense avoir un bon niveau technique, mais ce qui me frustre le plus au quotidien, ce sont les problèmes liés au travail d’équipe
  Le manque de confiance, les membres de l’équipe qui ne veulent pas se parler, d’autres seniors qui livrent un travail médiocre sans conséquence, l’absence d’objectifs d’équipe clairs et de vision produit, ainsi que l’absence d’accord sur les pratiques d’ingénierie communes. En devenant manager de personnes, pour le meilleur ou pour le pire, ces problèmes entrent dans le périmètre sur lequel je peux exercer une influence et dont je dois être responsable

  • Je comprends, car beaucoup des problèmes rencontrés dans mes équipes précédentes auraient sans doute pu être résolus par du management
    Mais une fois devenu team lead, je me suis rendu compte que le périmètre sur lequel je pouvais réellement exercer une influence était bien plus réduit que je ne l’imaginais. Il y a beaucoup de gens, y compris mon supérieur, qui veulent tout piloter directement, et on attend de moi que je ne fasse qu’apposer mon tampon
    Au contraire, cela me met encore plus en difficulté, parce que je dois exprimer à la place de l’équipe ce que les gens ont peur de dire. Par exemple : « pour qu’une story soit prête, l’API doit être définie ». Comment la QA peut-elle créer des tests automatisés en parallèle si elle ne sait même pas quoi tester ?
    Les Scrum Masters, product owners, managers et architectes disent au jour le jour ce qui les arrange comme si c’était une vérité évidente, puis se plaignent le lendemain que les tests soient en retard
    Au final, on entre dans une lutte politique pour savoir à qui incombe la responsabilité de la situation actuelle, et les personnes qui ont choisi cette direction et cette stratégie ont un bon réseau et savent très bien rejeter la faute sur les autres
  • Les gens ont vraiment du mal à se parler. Au bout du compte, pour que cela arrive, il faudra peut-être même utiliser des jeux de maternelle
  • Je suis curieux de savoir en quoi tu penses que ce genre de problèmes entrera davantage dans ta sphère d’influence

• Il y a longtemps, mon chef de l’époque venait de réussir un appel téléphonique pour demander quelque chose à quelqu’un d’un autre service, et j’étais debout dans son bureau
  Il a levé les yeux de son bureau vers moi, a souri légèrement et, d’un ton perplexe, a dit : « Ce n’est pas parce que mon intitulé est passé de “Specialist” à “Manager” que je suis devenu plus beau, mais ça aide clairement à faire avancer les choses. » C’était un moment où le pouvoir du titre fonctionnait réellement

  • Dire « il faut vraiment écrire des tests », c’est bien, mais ce n’est qu’ajouter une autre tâche par-dessus une roadmap qui aurait déjà dû être terminée hier, pour une équipe déjà en sous-effectif et pas assez armée techniquement
  • Dans mon cas, en tant qu’IC senior de mon équipe, c’est plutôt le manager qui me demande de porter certains sujets auprès de l’équipe. Parce que les membres de l’équipe m’écoutent vraiment
    Un manager est facilement ignoré tant qu’il ne menace pas de véritables conséquences, et ce genre de carte doit être utilisé avec parcimonie

• Il y a quelques années, j’ai commencé comme engineering manager en tant que CTO d’une petite startup, et ma vie a beaucoup changé. Je ressens la même chose sur tous les aspects que l’article original dit aimer et détester
  Mon conseil supplémentaire, c’est de vraiment méditer. Avant de prendre des décisions importantes et influentes qui peuvent nuire aux gens, il faut rester assis en silence assez longtemps pour que le cerveau s’éteigne
  Au début, cela devient une sorte de relation parent-enfant avec des génies. Il faut accepter les gens et comprendre leur manière de fonctionner. Plus on met de contrôle en place, moins on a de contrôle réel. Ils contourneront et repousseront la bureaucratie inutile, et franchement, je ferais pareil
  Mon deuxième conseil est de toujours agir comme quelqu’un qui part demain. Ainsi, l’équipe et les collègues sont prêts, et votre propre mode de vie s’améliore aussi

  • Dans le même esprit, ma technique ultime de management consiste à prendre des vacances et à laisser mes subordonnés assumer mon rôle. Je leur confie ça au moins deux semaines
    Ils progressent vraiment très vite, et il y a quelque chose d’étrangement rassurant à constater que l’organisation tourne sans moi. En même temps, comme ils semblent progresser plus vite quand je ne suis pas là, je me demande si ce n’est pas le signe que je fais quelque chose de travers
  • Je suis récemment devenu parent, et la transférabilité des compétences entre engineering manager et parent est très élevée
    Certains jours, j’ai l’impression de gérer ma famille avec des compétences apprises au travail

• Mon parcours est inverse. Je suis un ingénieur logiciel ordinaire, mais je suis plutôt doué pour gérer les gens
  J’ai assez d’expérience pour savoir ce qui prend du temps et quelles parties du système sont les plus importantes. Il y a quelques ingénieurs seniors que j’écoute vraiment, et à qui je donne beaucoup de confiance et d’autonomie
  Ce ne sont pas mes décisions de conception, ce sont les leurs, et j’apporte mon avis. En cas d’échec, j’en prends la responsabilité et j’apprends ; en cas de succès, j’en attribue le mérite à l’équipe. Même en restant humble, je pense que le rôle de manager porte avant tout sur les personnes

  • Honnêtement, je pense que c’est le parcours de carrière optimal pour devenir engineering manager. C’est dommage que beaucoup d’entreprises n’aient pas de dispositif officiel de transition vers le management à une étape intermédiaire

• Il n’y a qu’une seule raison pour laquelle je voudrais quitter un rôle de codeur/IC pour passer sur la voie du management : les entretiens au tableau blanc nécessaires à chaque changement de poste
  Il faut presque douloureusement se préparer depuis le début à chaque fois, et même s’il existe des rôles sans ce processus, ils sont très rares. Quand je pense à cette préparation, je me dis souvent « oh non, pitié, encore ? » et je reste simplement dans le même emploi

• Un mauvais engineering manager peut faire bien plus de dégâts qu’un mauvais IC. Je pense qu’on n’en parle pas assez souvent
  Au cours d’une longue carrière, j’ai rencontré un excellent manager, quelques managers corrects, et beaucoup de très mauvais managers. Les très mauvais managers rendent le travail beaucoup plus difficile, et parfois carrément misérable
  La combinaison d’un mauvais engineering manager et d’un IC junior peut être particulièrement mauvaise. Avec l’âge, j’ai compris qu’on peut aussi travailler avec un mauvais manager tout en essayant de faire évoluer la situation dans une meilleure direction, ou partir si l’on estime qu’il n’y a aucun espoir

  • Je serais curieux de savoir comment tu définirais cet excellent manager. Quels traits de caractère, comportements ou compétences le distinguaient ?
    J’ai de plus en plus de responsabilités de management ces temps-ci, donc ça m’intéresse

• J’ai un jour dirigé une équipe composée d’IC titulaires de doctorats. Il fallait leur trouver du travail, contenir les rêveurs et les garder heureux
  Sans plaisanter, je passais parfois six heures d’affilée à parler individuellement avec eux, en jouant le rôle de conseiller d’orientation et de consolateur. Je n’aurais jamais imaginé que cela deviendrait mon travail
  L’un des membres de l’équipe a aidé à décrocher deux contrats distincts d’un milliard de dollars, donc mon temps a été rentabilisé