Avant de commencer, une précision : ce qui suit n’est ni une méthode ni une vérité générale. C’est un retour d’expérience personnel, forcément subjectif, sur ce que le rôle d’engineering manager m’a appris. Je n’ai aucune prétention à la démonstration, juste l’envie de partager honnêtement ce qui m’a construit dans ce rôle.
C’est le premier article d’une série où je vais explorer, à chaque fois avec un focus différent, ce que ce métier m’a apporté. Plutôt que de vous exposer mes propres principes, j’ai préféré faire autrement : partager les citations et les principes que des personnes qui ont compté dans mon parcours (collègues, mentors) m’ont transmis, et vous dire ce qu’ils m’apportent au quotidien. Ce premier épisode porte sur le rôle et la posture d’engineering manager.
Si ces articles ouvrent des voies à quelques personnes, alors j’en serai déjà ravi.
Une référence avant les citations : “Engineering Management for the Rest of Us”
Avant d’entrer dans les citations qui ont individuellement marqué mon parcours, je ne peux pas commencer cette série sans mentionner une référence : le livre Engineering Management for the Rest of Us de Sarah Drasner.
C’est une vraie recommandation, du contenu de grande qualité. En un format relativement court, elle aborde énormément de sujets et formalise une multitude de concepts et de conseils de façon très simple. Si vous ne devez lire qu’un seul livre sur le sujet, c’est celui-là.
Merci Sarah pour cette dédicace, obtenue lors de la DotJS 2025 où nous étions
tous les deux speakers et avons pu échanger brièvement.
Je citerai quand même un conseil tiré du livre : demander explicitement les attentes qu’ont vos managés de vous.
C’est un exercice très sain, et vous verrez que chaque individu a des besoins et des attentes très différentes. C’est là aussi que ressort une nécessité importante : il vous faudra vous adapter à chaque individu de l’équipe. Une méthode unique ne fonctionnera pas avec tout le monde, sinon ce serait de la magie.
Le rôle du manager vs. celui de l’IC : hands on, hands off
“Tout ce que tu fais, l’équipe doit savoir et pouvoir le faire, mis à part les aspects de management.” (Florent Dubost)
Tous mes modèles en management d’équipe d’ingénierie ont toujours gardé un aspect technique dans leur travail. Le pourcentage varie d’une personne à l’autre, mais iels ont toujours eu les mains dedans.
Pour moi, engineering manager est un rôle étendu du rôle de contributeur individuel, pas un rôle qui s’y substitue.
C’est aussi ce que j’en interprète : se réserver des tâches et des sujets en tant que “chef” est une mauvaise pratique. Si on veut pouvoir compter sur son équipe, toute l’équipe doit pouvoir nous épauler.
Comment fonctionnerait l’équipe en cas de vacances si vous silotez des étapes de développement, de planification, ou des tâches spécifiques ?
La posture face à l’équipe : confiance et délégation
“Ta priorité c’est ton équipe, puis les individus qui composent ton équipe, et enfin les projets que ton équipe doit réaliser.” (Kenny Dits, mon chef pendant de nombreuses années chez M6)
J’ai eu la chance d’avoir des managers humanistes. Je pense qu’il est nécessaire de prioriser l’équipe pour construire de la confiance, et qu’avec cette confiance, il n’y a plus de crainte à avoir pour l’accomplissement des objectifs.
Pour la priorisation, il faut comprendre quelque chose qui n’apparaît pas forcément à la première lecture. Cela signifie que vous devrez parfois abandonner des projets ou des objectifs pour protéger les individus ou votre équipe. Cela signifie également qu’il sera parfois nécessaire de sortir quelqu’un de l’équipe, pour le bien de l’équipe. Ce sera votre responsabilité, autant s’y préparer. On ne sacrifie pas une équipe pour un individu ou un projet.
De plus, votre équipe saura répondre présente lors d’un besoin plus important, car elle sait que si vous la sollicitez, c’est vraiment pour un sujet qui compte.
Oui, c’est une référence troll à la pyramide des tests, un modèle que tout le monde connaît, que tout le monde cite, et que tout le monde finit par retoucher à sa sauce tant il ne veut plus dire grand-chose. J’en ai justement parlé dans une conférence avec Jules Poissonnet, mon ancien alternant : Tester c’est tricher !.
La posture de challenge : débloquer et faire grandir
“Qu’est-ce qui t’en empêche ?” (Yann Verry, mon ancien collègue, qui me l’a dit plusieurs fois)
Un manager, c’est aussi quelqu’un qui challenge et qui permet à son équipe de sortir de ses blocages. C’est aussi être là pour débloquer des situations, mentorer, accompagner dans des décisions.
Un manager est également là pour faire en sorte que les individus qui composent son équipe puissent s’épanouir et progresser.
Ce que “servir” son équipe veut dire concrètement
“Je fonctionne comme ça, je fais confiance de base et après si besoin je discute avec toi si il y a des choses à revoir.” (Étienne de Thoury, mon actuel Head of chez Scaleway)
L’idée est simple : éviter le micromanagement, laisser de la liberté.
Quand on devient manager, on peut parfois ressentir du stress et se retrouver à vouloir tout suivre, tout gérer.
C’est aussi souvent nos propres managers qui nous poussent, sans le vouloir, vers ce travers : quand un n+1 demande un reporting ultra précis, il ne reste pas beaucoup d’autre choix que de commencer à tout suivre. Je le vois autrement : l’information en elle-même n’est pas un pouvoir. Savoir vers qui la renvoyer l’est bien plus, car elle sera toujours plus pertinente venant de la personne qui la maîtrise réellement.
J’en ai une autre lecture, qui me parle tout autant : ce stress est souvent moins une question de contrôle que de confiance en soi. Si je vous confie une tâche alors que moi-même je ne suis pas certain à 100 % du résultat, que je n’ai pas confiance en moi pour la mener à bien, il me sera impossible de vous faire confiance pour la réaliser. Et cette incertitude finit par retomber sur le dos de la personne, ou de l’équipe.
L’effet miroir
“Quand tu réagis ou tu parles mal d’un projet ou d’une équipe en tant que manager, tu peux être sûr que ton équipe réagira en x10 dans quelques semaines.” (Florent Dubost)
Qu’on le veuille ou non, un manager est un modèle. Son équipe observe ses réactions, son ton, la façon dont il parle d’un projet, d’une autre équipe, d’une décision. Ce qui est capté, consciemment ou non, c’est ça qui se répète et s’amplifie dans l’équipe au fil des semaines.
Si je me montre négatif ou désabusé sur un sujet, cette attitude ne reste pas la mienne. Elle infuse les conversations de l’équipe, puis sa manière d’aborder ce sujet avec les autres, et elle finit par me revenir, amplifiée. L’inverse est vrai aussi : la confiance et l’énergie qu’on montre se propagent de la même façon.
Ça veut dire faire attention non seulement à ce que je dis, mais à comment je le dis, car c’est ça qui devient la norme de l’équipe, bien plus que n’importe quelle consigne explicite.
La sécurité psychologique : une responsabilité de leader
“Chaque leader de chaque groupe d’influence est responsable de la sécurité psychologique de son groupe d’influence.” (Léa Coston, dans son talk Les gens ne savent pas ce qu’ils font, la plupart du temps !)
En tant qu’engineering manager, on est le leader du groupe d’influence que constitue son équipe. La sécurité psychologique n’est pas un supplément d’âme ou une option “sympa à avoir” : c’est une responsabilité structurelle du rôle.
Ce n’est d’ailleurs pas qu’une conviction personnelle : le projet Aristote mené par Google, qui a étudié des centaines d’équipes internes, a montré que le facteur le plus déterminant de la performance d’une équipe n’était ni les compétences individuelles ni l’ancienneté, mais bien son niveau de sécurité psychologique.
Une équipe en sécurité psychologique, c’est une équipe qui ose dire qu’elle s’est trompée, qui ose remonter un problème avant qu’il ne devienne critique, qui ose ne pas être d’accord avec vous. Une équipe qui n’a pas cette sécurité apprend vite à se taire, et vous perdez l’information la plus précieuse : celle qui arrive tôt.
Il y a là un vrai enjeu d’exemplarité : être capable de dire à son équipe qu’on peut se tromper, qu’on s’est trompé, ou qu’on ne sait pas, ça rassure chacun sur sa propre capacité à faire ou dire la même chose.
Ça rejoint directement l’effet miroir vu plus haut : la sécurité psychologique ne se décrète pas, elle se construit par la façon dont vous réagissez, en particulier quand quelque chose se passe mal.
Le bâton de pouvoir
“Le bâton de pouvoir” (une phrase lue quelque part, dont la source m’échappe malheureusement)
Photo : collection du musée du Louvre.
Lorsqu’on décide de vous nommer responsable d’une équipe, cela signifie qu’on a confiance en vous pour vous donner ce pouvoir de décision. Ce pouvoir est un acte de confiance important, mais c’est aussi un fardeau : il faut, dans la mesure du possible, éviter de trop l’utiliser au sein de votre équipe.
Les décisions doivent rester collectives, mais il vous faudra parfois arbitrer, plusieurs fois. C’est ce qu’on attend de vous, et non d’escalader la décision plus haut si son scope ne concerne que votre équipe.
Une décision collective embarquera toujours bien plus l’équipe qu’une décision descendante. Faire émerger le maximum d’intelligence collective est, à mes yeux, l’une des missions les plus importantes d’un manager.
Se créer un réseau de managers
Un dernier point, essentiel selon moi : se créer un réseau de managers, dans son entreprise ou ailleurs, avec qui échanger sur ces sujets, prendre des avis, des conseils. Je vous assure que ça aide, énormément.
Une pensée pour les managers avec qui j’échange régulièrement : ils se reconnaîtront, merci à eux.
Si vous n’en avez pas encore, des communautés en ligne existent, comme le Slack Engineering Managers Community.
Et la suite ?
C’est le premier article de cette série sur mon retour d’expérience en tant qu’engineering manager. Le prochain épisode abordera le 1:1 et le suivi individuel. Vous pouvez retrouver tous les articles de la série via le tag engineering-management.