De développeur à Engineering Manager
Houlà ! Déjà Septembre ? Ça fait donc presque un an que je suis Engineering Manager ! Dire que j’étais encore développeur backend en septembre dernier… Le temps passe vite!
En octobre dernier, j’ai changé de poste chez OpenClassrooms : je suis passé du rôle de développeur backend à celui d’Engineering Manager (EM). J’ai beaucoup appris sur les différences entre ces deux métiers : j’en avais anticipé certaines, d’autres pas du tout ! J’ai décidé d’écrire cet article pour toute personne qui pourrait hésiter à se lancer dans un tel changement. De plus, je pense que certaines de ces observations pourraient facilement s’appliquer en dehors du monde de la programmation, à toute personne envisageant de passer d’un rôle de contributeur individuel à un poste de manager.
Petite précision : le rôle d’EM peut être très différent d’une entreprise à une autre. Je ne vais pas décrire ici comment nous travaillons en tant qu’EM chez OpenClassrooms : cet article explique très bien notre vision !
Pourquoi ce changement ?
Dans un poste précédent, j’ai découvert la Communication Non-Violente et l’incroyable pouvoir d’une connexion authentique au niveau des émotions. C’était un changement radical de point de vue, par rapport à ce que j’avais retenu de ma formation d’ingénieur, où l’on m’a toujours dit de me concentrer sur les faits bruts et de mettre de côté les sentiments ! Cela a été le point de départ d’un intérêt croissant pour l’humain, la psychologie, les relations, les interactions entre personnes et les organisations.
Cet intérêt n’a fait que s’approfondir au fur et à mesure des missions que je réalisais : les situations où le noeud du problème était purement technique étaient en effet beaucoup plus rares que les cas où les difficultés venaient de l’organisation des personnes et des équipes.
Ces expériences m’ont amené à me diriger vers le management plutôt que vers l’expertise technique.
Aparté :
J’ai eu la chance, voire le luxe, de pouvoir me poser cette question et choisir ce qui m’intéressait le plus ! Dans de (trop) nombreuses entreprises et industries, la carrière par défaut va toujours du poste de contributeur individuel vers le poste de manager… même si les compétences requises pour être un bon manager sont très différentes de celles nécessaires pour être un bon contributeur individuel !
Dans le monde de la “Tech”, certaines entreprises (y compris OpenClassrooms) ont réalisé cette différence de compétences et ont également compris que certaines personnes peuvent réellement progresser, améliorer leur performance et augmenter leur impact dans l’entreprise, tout en continuant à programmer ! Cela a conduit à des postes tels que “Principal Engineer” pour ceux qui souhaitent rester dans la technique, et “Engineering Manager” pour ceux préfèrent s’orienter vers du management.
Comment le changement a eu lieu
J’ai rejoint OpenClassrooms en tant que développeur backend, mais avec à l’esprit les centres d’intérêt que j’ai mentionnés précédemment. Au cours des premiers mois, j’ai fait quelques suggestions dans ce domaine : j’ai commencé par animer un atelier au sein de ma nouvelle équipe pour “briser la glace” et se préparer à travailler ensemble. Plus tard, j’ai commencé à animer des ateliers d’initiation à la Communication Non Violente pour les personnes de l’équipe technique qui étaient intéressées.
Cela a rapidement permis à ma manager de comprendre dans quelle direction je me dirigeais, davantage vers le management que vers l’expertise technique. Elle m’a encouragé à poursuivre dans cette direction et à m’impliquer davantage dans les questions organisationnelles au sein de mon équipe.
J’ai également commencé à essayer de prendre une habitude : chaque fois que je prenais conscience que j’étais en train de penser “je vais demander à ma manager ce qu’elle en pense”, je prenais un moment pour me demander : “si j’étais Engineering Manager et qu’une personne sous ma responsabilité venait me poser cette question, comment pourrais-je répondre ?” Je ne prétends pas que je trouvais toujours la bonne réponse (ni même que je trouvais toujours une réponse), mais cette habitude m’a aidé à me projeter dans mon futur poste. Cela m’a également aidé à gagner en autonomie, à réaliser que je pouvais trouver beaucoup plus de solutions par moi-même que je ne le pensais !
Quelques mois plus tard, un sujet impliquant toute l’équipe Engineering est apparu : définir les valeurs de l’équipe. Le sujet me paraissait important et j’étais curieux du processus pour aboutir à cette définition, je me suis donc porté volontaire pour aider à définir les ateliers et le processus décisionnel… Et ce faisant, j’ai commencé à travailler avec l’équipe de managers.
Cette équipe a ensuite ouvert un nouveau poste et m’a proposé d’y postuler. J’ai hésité, puis j’ai lu le livre Radical Candor. Ce livre décrit très bien à quel point le travail d’un manager peut être profondément gratifiant et agréable, tout en fournissant de précieux conseils et outils. Cela m’a donné à la fois motivation et confiance pour me lancer dans ce changement de rôle !
À ce stade, j’ai dû passer par un processus de recrutement interne : comme je l’ai déjà dit précédemment, les compétences requises pour être un manager ne sont pas les mêmes que celles requises pour être un développeur backend !
Pour résumer, si vous commencez à envisager un changement de rôle pour vous diriger vers un poste de management, voici mes conseils :
- Informez-vous sur le management (j’ai adoré Radical Candor, mais il existe de nombreux autres livres et de nombreuses autres sources d’information non livresques que vous pouvez trouver !)
- Commencez à vous impliquer dans des problématiques humaines et organisationnelles au niveau le plus proche de vous (votre équipe, par exemple), en essayant d’identifier ce qui vous ralentit et comment vous pourriez vous améliorer en tant qu’équipe.
- Cherchez du soutien autour de vous, peut-être pouvez-vous commencer à demander à votre manager de vous parler de son travail et de comment vous pourriez avancer dans cette direction ?
- Vous pouvez également utiliser ma méthode de réflexion “comment répondrais-je à cela si j’étais manager ?” si vous pensez que cela peut vous aider !
Ce que j’ai découvert pendant les premiers mois
Dans mon quotidien, j’ai rapidement fait les premiers constats évidents, auxquelles je m’attendais déjà (et qui sont toujours d’actualité aujourd’hui) : je passe beaucoup moins de temps à programmer (… en fait, je ne code plus du tout) ; j’ai des entretiens individuels toutes les deux semaines avec mes collaborateurs directs pour échanger autour de leur quotidien, prendre du recul et essayer de comprendre comment les aider en cas de problème. Et surtout, je suis invité à beaucoup plus de réunions avec plus de personnes différentes.
Une autre chose qui s’est avérée être un avantage inattendu : le fait d’avoir été un développeur dans l’équipe, aux côtés des personnes dont j’étais maintenant responsable. Je connaissais en effet déjà les personnes avec lesquelles je travaillais, la culture de l’entreprise, leur façon de travailler. Cela m’a aidé à m’intégrer plus rapidement.
De plus, ayant travaillé à leurs côtés, je sais à quel point ils sont investis dans la mission, le produit et la qualité du code. Cela m’a donné confiance pour mes premiers mois, où j’ai pu me concentrer sur les relations individuelles et la vision à long terme, qui étaient les sujets qui me motivaient le plus à cette époque. Cela m’a également permis de prendre rapidement mes marques et de rester très motivé dès le début !
Je sais également ce qui est important pour eux dans leur travail quotidien, ce qui me permet de comprendre plus clairement l’importance de leurs demandes… Par exemple, je sais à quel point il est essentiel d’avoir un pipeline CI/CD fonctionnel et fiable qui ne mette pas plusieurs heures à tourner !
Enfin, étant donné que tout le monde est au courant des deux propositions de carrière possibles (management/expertise), les relations avec les collaborateurs directs ont pu commencer sur des bases saines : nous savions tous les deux que nous étions là où nous voulions être, moi en tant que manager parce que je l’avais choisi, eux en tant que développeurs parce qu’ils l’avaient également choisi.
Ce que j’ai réalisé plus tard
Quelques mois plus tard, j’ai eu une sensation étrange. Dans toutes mes expériences précédentes en tant que développeur, j’avais commencé à me sentir plus à l’aise après quelques semaines ou quelques mois, avec au moins ma première fonctionnalité déployée en production, ou du moins un code fonctionnel. Mais là, cette sensation de confort n’était pas présente.
J’ai alors réalisé que cela découlait de la nature même de mon nouveau travail : les actions d’un manager sont vraiment plus “floues” que celles d’un développeur (et je pense que cela peut être vrai en général pour n’importe quel poste de contributeur individuel).
En effet, en tant que développeur, ma journée était jalonnée par des actions concrètes :
- Écrire des tests unitaires
- Écrire du code
- Lancer les tests
- Proposer mon code à d’autres développeurs
- Examiner le code des autres, approuver les Pull Requests (PR) ou demander des modifications
- Déployer en production
Et ces actions étaient accompagnées de retours clairs et binaires à chaque étape :
- Le résultat des tests est soit rouge (échec) soit vert (réussite)
- Le commit Git réussit, ou échoue avec des conflits
- Ma PR est approuvée ou des modifications sont demandées
- Le déploiement réussit ou échoue
- Le bug est corrigé ou non
Maintenant, en tant que manager, ce que je fais au jour le jour ne s’accompagne pas du même retour clair et net. J’organise des réunions, j’assiste à des réunions, j’écoute, je réfléchis, je donne mon avis, je propose des idées et je remets en question d’autres idées. Et la plupart de ces actions ne déclenchent pas de retour immédiat. Les gens ne deviennent pas rouges ou verts (à moins qu’il y ait un autre problème nécessitant une intervention médicale).
Bien sûr, je reçois tout de même un certain retour d’information sur ce que je fais ! Mais il est moins immédiat (voir le résultat de certaines actions peut prendre des mois) et moins certain (les personnes sont moins prévisibles que les machines).
Dans l’ensemble, cela a rendu plus difficile pour moi de déterminer, jour après jour, si je faisais du bon travail ou non. J’ai dû trouver d’autres moyens d’obtenir des retours, de la part de mon manager, de mes collaborateurs et de mes pairs.
Ce que je savais déjà mais que je continue d’apprendre
Il y a une autre grande différence entre les deux rôles. Cela m’a frappé dès mon tout premier jour… Mais j’apprends encore aujourd’hui !
Le jour de ma première expérience en tant que manager, j’avais de nombreuses réunions prévues dans mon calendrier. Mais j’avais aussi quelques heures sans réunion. J’attendais avec impatience ces moments, comme je le faisais habituellement en tant que développeur… Et puis… La réunion se termine. Hmm… Que fais-je maintenant ?
Aucun Product Owner n’avait rempli de tableau Jira pour moi avec un backlog de tâches bien définies que je pouvais commencer à coder…
Oh. Donc, il faut que je trouve comment organiser mon temps, quoi faire, quand le faire, comment le faire… C’est à moi aussi de faire ça ? Wow. Je le savais, mais ça fait quand même une différence quand c’est vécu pour la première fois.
Mon ancienne manager appelait ça “être son propre manager”. C’est un travail délicat qui implique plusieurs choses parmi lesquelles :
- Identifier les principaux sujets sur lesquels travailler
- Déterminer les prochaines étapes pour chaque sujet
- Trouver comment les mettre en œuvre
- Mettre régulièrement à jour les priorités
- Tout cela en gérant le temps entre les réunions
- Et en tenant compte du fait que la plupart des “prochaines étapes” impliquent de discuter avec quelqu’un d’autre dont l’agenda est tout aussi chargé que le mien.
Cela implique également de choisir les réunions auxquelles je décide de participer, et parfois de choisir de ne pas participer à certaines, pour éviter d’être submergé.
Oui, c’est beaucoup. Oui, c’est difficile. Je vous avais bien dit que j’étais encore en train d’apprendre !
J’ai déjà découvert quelques astuces qui m’aident : chaque vendredi, je jette un coup d’œil à ce à quoi ressemble mon agenda pour la semaine à venir, et je prends un peu de temps pour le rendre plus clair (déplacer certaines réunions, décliner certaines invitations, etc.). Et chaque jour, je prends un moment pour définir mon objectif quotidien : une tâche, aussi petite soit-elle, que je veux avoir terminée d’ici la fin de la journée. Cela m’aide aussi à gérer le côté “flou” du management, soit dit en passant !
Pourquoi je suis très satisfait de ce choix
Naviguer parmi toutes les différences que j’ai énumérées ici est vraiment un défi. J’ai beaucoup à apprendre, chaque jour ; plus que je n’ai jamais eu à apprendre, je pense. Mais je n’ai aucun regret et je ne voudrais pas revenir en arrière. Parce qu’au quotidien, je me concentre sur les sujets qui m’intéressent le plus : les relations humaines et l’organisation des équipes.
De plus, il s’en est passé des choses en un an ! C’est assez long pour avoir pu avoir des retours sur certaines actions que j’ai entreprises… et parfois je réalise qu’une petite idée proposée il y a quelques mois a eu depuis un bel impact sur les relations ou la motivation de certaines personnes.
J’ai aussi pu recueillir beaucoup d’informations sur des sujets variés, et je connais de mieux en mieux mes collaborateurs, ce qui me permet de plus en plus de leur proposer des conseils pertinents.
Dans les deux cas j’ai vraiment l’impression que partager ces idées est plus gratifiant pour moi, plus utile pour les autres, plus personnel et plus original que n’importe quelle idée que j’ai pu avoir auparavant lors de discussions techniques !
En résumé, je suis très heureux d’avoir sauté le pas… Mais ça n’a fait que renforcer ma conviction que ça ne doit pas être un passage obligé ! J’espère que mon témoignage pourra vous aider à faire votre choix, si vous faites face à une telle décision !
