Que fait un Engineering Manager ?

Que fait un Engineering Manager ?

January 31, 2022

15 min read

Hugo Lassiège
@hugolassiege

Dans ce billet je souhaite revenir sur le rôle d’Engineering Manager, la personne responsable de l’efficacité du “delivery” (la capacité à livrer du logiciel), des personnes et de leur évolution dans l’entreprise. 

Pour en avoir discuté avec plusieurs personnes, ce rôle peut être assez différent selon les entreprises. Alors je tenais à partager notre expérience chez Malt de ce rôle. 

On essaiera de lire cette fonction à partir de 4 axes d’analyses : gestion humaine, gestion de l’efficacité collective, sens business et expertise technique et on verra comment nous sommes venus à introduire ce poste dans l’équipe.

4 axes de lecture : expertise, humain, collectif, business

Pour démarrer, je vais partir d’un postulat simple. Dans une équipe, vous avez 4 axes majeurs à travailler. 

Sur chacun de ces axes, il peut y avoir une ou plusieurs personnes dans l’équipe qui travaillent dessus au bénéfice du collectif.

Pour ne pas réinventer la roue, je vais repartir du site engineeringladders.com et de sa représentation sur 5 axes.

J’ai modifié pour ne garder que 4 axes de lecture. Sur chacun je vais indiquer l’équivalence.

  • Technologie

On parle ici des connaissances des frameworks, outils, et langages, les patterns d’architecture et le niveau d’influence sur le système. C’est l’équivalent de de Technology et system.

  • l’optimisation de l’efficacité collective

Ici il est question de sujets très variés mais on peut le résumer à “comment on fait les choses de la façon la plus efficace possible”. C’est l’équivalent de Process mais je ne suis pas fan de ce nom. Il faut faire attention à ne pas travailler pour le process mais pour l’efficacité et le succès.  

  • la gestion des humains

La gestion humaine regroupe entre autres le suivi individuel, le coaching, le recrutement, la constitution des équipes, la formation. C’est l’équivalent de People

  • le sens business 

C’est le fait de travailler dans l’intérêt général de la société et de comprendre sa stratégie afin d’aligner celle de l’équipe dessus. Aucun équivalent sur le radar engineeringladders.com. Je considère que c’est un manque. 

Sur cet axe là, puisqu’il est nouveau sur ce billet, je vous propose les 5 niveaux suivants :

  • Understands : comprend les bases du business et s'aligne sur les objectifs globaux 
  • Specializes : a une bonne compréhension d'un domaine métier de la société et sert de référent 
  • Enables : est en mesure de proposer des solutions pour résoudre des problématiques de son domaine métier
  • Owns : est le responsable fonctionnel sur une partie métier du produit et co-définit son évolution future
  • Influences : est en mesure d'influencer la société sur son domaine métier, visible au niveau de son industrie

Sur les autres axes, je vous invite à lire la définition sur engineeringladders.com

Voici ce que ça donne :

Voyons ce que cela donne chez nous.

L’engineering Manager chez Malt

Pour poser une première définition dans le contexte de Malt. L’engineering manager chez nous est un rôle de management, à l’opposé des rôles de leadership et de contributeurs individuels. 

Dans un ancien billet j’avais pris le temps de parler de la branche “leadership”. 

Reprenons ce schéma que j’avais utilisé : 

On y distingue 3 branches distinctes :

  • la branche “contributeur individuel” qui forme le tronc commun pour ensuite évoluer sur les deux autres branches
  • la branche leadership à gauche. C’est une extension de la branche “contributeur individuel” mais avec plus d’impact attendu et de coordination
  • la branche “management”, à droite, où on peut trouver le fameux Engineering Manager.

En schématisant, à partir des axes de lecture définis plus haut, cela nous donnerait (pour un senior dans ce rôle) :

En contributeur individuel : 

Le contributeur individuel senior :

  • est référent sur un domaine métier. 
  • maîtrise l’ensemble des technologies et du système sur lequel il opère
  • incarne et challenge les bonnes pratiques
  • a un rôle de support au sein de son équipe

En Staff engineer et plus (branche leadership)

A partir de ce niveau, on est toujours sur des contributeurs individuels, mais on attend le cran du dessus :

  • définit les bonnes pratiques au niveau ingénierie (souvent en collaboration avec l’Engineering Manager)
  • participe à la création de la vision technologique de la société et la façon dont la technologie est valorisé
  • sa vision technologique et ses capacités de communication lui permettent d’avoir de l’impact sur le business
  • il est en mesure de coordonner plusieurs personnes sur des projets technologiques complexes

En Engineering Manager :

L’Engineering Manager :

  • gère les individus dans l’équipe pour leur permettre de s’améliorer
  • a un bon vernis technique (il peut parfois être expert mais on ne lui demande pas) lui permettant d’être force de propositions sur les bonnes pratiques et le delivery
  • définit les méthodes et process de l’équipe afin de constamment accélérer les équipes
  • a une connaissance parfaite de son domaine métier afin de pouvoir aider son équipe à rester alignée et faire les bons choix 

Dans notre cas, son profil type est un Senior, ayant été contributeur individuel mais tourné aujourd’hui essentiellement sur l’humain et le business. 

Je pense que vous aurez noté par vous même que la personne qui “influence” le business, donc au niveau max sur cet axe, est le Product Manager. 

Mais, me direz-vous, c’est la même chose que XXX ? 

XXX pouvant être Scrum Master, Tech Lead, Chef de projet

Eh bien, voyons cela.

Engineering Manager versus Scrum Master

Tout d’abord, il faut bien voir qu’un Scrum Master c’est avant tout un rôle dans la méthodologie Scrum, rien de plus. C’est devenu un métier à part entière, pour le meilleur et sans doute surtout pour le pire… 

Les missions premières du Scrum Master sont :

  • Coacher l’équipe dans l’esprit de la méthode 
  • Faire le bouclier devant l’équipe pour les protéger des perturbations

Si on s’arrête à la définition, le Scrum Master est ce que Marty Cagan appelle un “process people”. Et je vais vous laisser lire ce qu’il en dit sur son blog.

Si on résume cela sur les 4 axes vus précédemment :

Le sujet est avant tout de s’assurer de l’efficacité collective de l’équipe (tout en restant dans le cadre de la méthode Scrum). L’aspect humain est présent mais la méthode Scrum ne définit aucune responsabilité de suivi individuel, gestion de la formation, recrutement etc… 

Quant au sens business, par définition, être “bouclier devant l’équipe” revient à placer l’équipe en premier, avant la boite. 

Ça vous titille?

Si vous êtes familier de Scrum, relisez la définition de son rôle :

  • “la protection face aux perturbations”, 
  • rôle de “proxy” devant le PO (lui-même proxy devant les stakeholders)

Le lien avec le business est en principe incarné par le product Owner. Mais pas par le Scrum Master.

J’aimerais citer Gergely Orosz dans ce billet pour insister sur la différence avec l’EM : 

As an engineering manager, you'll need to put the company first, team second, your team members third, yourself as fourth.

Gergely Orosz

Bon, je caricature un peu et il y a de nombreuses structures plus saines ou le Scrum Master est totalement lié au métier et peut endosser d’autres fonctions dans l’équipe. De mon point de vue, s’il n’y a pas d’EM dans l’équipe je préfère quand ce rôle est tournant dans l’équipe. Mais cela suppose une bonne maturité de l’équipe sur les principes Agiles. 

Si un EM est présent, c’est un bon candidat pour jouer ce rôle de facilitateur, tout en gardant à l’esprit qu’il ne doit pas s’enfermer dans ce rôle car ses responsabilités sont plus larges et il doit garder du recul.

Engineering Manager versus Chef de projet 

Prenons des pincettes, le chef de projet est un terme assez vague. C’est souvent lié à un mode d’organisation traditionnel où on parlera de projet informatique et pas de produit. 

Le CDP est la personne responsable de l’avancement, du planning, de l'exécution.

Selon nos axes vus avant cela se représenterait comme suit :

On notera donc un focus particulier sur l’efficacité collective en vue de tenir les plannings. Je place l’axe business sur “moyen” car dans ce type d’organisation on se concentre surtout sur le résultat (la sortie de tel ou tel projet), pas l’impact final. Mais je chipote. 

Ce serait délicat de comparer les deux rôles, ce sont des positions qu’on retrouve dans des organisations différentes et avec une culture différente. Ça n'aurait pas de sens dire que l’un est plus ceci ou cela, c’est le contexte qui est radicalement différent. Je dirais que le chef de projet s’inscrit dans un cadre plus traditionnel de projet “à la Française", tandis que l’Engineering Manager s’inscrit dans une culture produit importé des US.

Engineering Manager versus Tech lead 

Un split nécessaire ?

J’ai vu de nombreuses organisations dans lesquelles le tech lead avait aussi en charge les process et l’humain. 

J’ai vu également des organisations dans lesquelles les engineering manager avait en charge un rôle d’expert technique en plus du reste. 

Et… pourquoi pas ?

N’est-ce pas possible que les tech leads, en principe les personnes les plus seniors, endossent les deux rôles d’expert et de manager ?

Ma conviction, c’est qu’il est possible de trouver des personnes ayant des qualités sur ces 4 axes et qui seraient parfaitement compétents sur chaque sujet pris séparément.

MAIS, le souci principal, en dehors de la rareté de ces individus, c’est le temps disponible

Tout le monde doit faire des choix dans sa gestion du temps. Si un “tech lead” décide de passer du temps pour résoudre un défi technologique, c’est du temps en moins passé sur le mentorat, le recrutement, la formation collective etc… 

A l’inverse s’il décide de passer du temps chaque semaine avec chaque membre de l’équipe, plus quelques autres interlocuteurs clés de l’équipe, il se mettra en retard sur son dev. Rien que la gestion de son calendrier va différer. L’expert technique a besoin de plage de temps de  travail ininterrompu. Le manager doit être en multi tâches régulièrement. 

Ce n'est pas une question de compétences, on peut être fort dans les deux. Mais pas en même temps. 

Un autre défaut d’avoir les rôles d’Engineering Manager et de tech lead mélangé, c’est le risque de perte d’objectivité, ou d’être trop dans le quotidien pour continuer à développer le sens business à long terme. 

Je vous invite également à lire ce billet tiré de engineeringladders.com qui traite exactement de ce sujet (listé également dans les sources en fin de billet).

Mais tout est question d’échelle. 

A Malt, de 2014, premier dev recruté, à 2019, nous n’avions aucune personne dédiée à la gestion des individus et l’efficacité collective. Ce rôle reposait donc sur les tech leads.

L’introduction du rôle chez Malt

Le rôle d’Engineering Manager est assez récent chez nous. Le premier Engineering Manager a été introduit en 2021.

La première fois que j’ai entendu parler de ce rôle c’était en 2017. J’ai rencontré plusieurs EM dans différentes boîtes. Et pour être franc, je ne projetais pas bien ce que cela pourrait donner chez nous.

En 2017 l’équipe engineering faisait environ 10 personnes, je m’occupais complètement du recrutement. L’équipe était assez senior pour être autonome sur les aspects d’organisations et cette seniorité limitait également les besoins en people management. Cette situation avait cependant des limites bien sûr. Notamment pour les moins seniors qui ne pouvaient pas bénéficier d’un suivi personnalisé et pouvaient se sentir limités dans leurs possibilités d’évoluer sans mentorat constant. 

C’est pourquoi nous avions également des “leads” qui prenaient ce rôle de mentors et coachs. Ces leads pourraient être représentés comme suit dans leurs rôles de tous les jours :

La situation a pu perdurer jusqu'en 2019 mais avec plusieurs limitations :

  • un certain inconfort des leads qui ne souhaitaient pas aller plus loin dans le management, et connaissaient des perturbations dans leur quotidien de dev
  • un suivi moins efficace des junior et intermédiaires
  • des sujets d’efficience d’équipe de plus en plus consommateurs en temps en raison de la taille de l’équipe

C’est pourquoi fin 2019 nous avons recruté un VP engineering afin de préparer les futures étapes de notre croissance. 

(Plus d’infos sur ce poste dans un ancien billet de ce blog)

Suite à cela, le premier poste d’engineering Manager est apparu fin 2020, en prolongement de l’action du VP Engineering. 

Et pour être complet, il y a eu quelques réticences au début. 

Parce que, malgré les soucis de fond qu’il fallait résoudre, encore plus dans un contexte d’équipe qui doit doubler de taille en 1 an, il y a toujours le spectre du “chef de projet” qui ressurgit assez vite. Oui, on peut qualifier ça de syndrome post traumatique ;)

Tout est question de pédagogies d’une part, mais également d’être super vigilant sur le recrutement sur un point majeur : la culture d’entreprise

L’engineering Manager, reflet de la culture d’entreprise

La culture d’entreprise, ça fait partie des mots valises, tout le monde en parle, peu savent la définir. 

J’ai lu une fois une définition très basique, et en même temps très forte : la culture est la somme des pratiques utilisées dans l’entreprise. C’était dans le livre "reinventing organizations” de Frédéric Laloux. 

Donc la culture, c’est l’attitude que vous allez adopter pour répondre à une situation. Et quand on formalise sa culture, on fait en sorte que cette attitude soit systématiquement la même, guidée par des principes directeurs. 

Il existe des tas d’entreprises qui utilisent exactement les mêmes outils que vous, les mêmes définitions théoriques des métiers, et pourtant, la culture peut créer un monde gigantesque entre deux sociétés en apparence identique. 

La culture c’est par exemple comment vous allez gérer la formation continue ou la philosophie derrière la mesure de la performance

Or l’Engineering Manager est une personne qui doit incarner cette culture. C’est l’une des personnes qui va être le liant dans l’équipe, et en dehors de l’équipe. Elle va travailler sur l’efficacité collective, dégoupiller les problèmes, faciliter la communication et l’alignement avec la stratégie de la boite, du département, de l’équipe. 

Bref, lors du recrutement il faut être très vigilant sur l’adéquation entre la culture de la personne et celle souhaitée dans l’entreprise. Il faut amener de la fraîcheur sur les pratiques, certes, mais ne pas sacrifier sa culture. 

Chemin de progression (career path) de l’Engineering manager

Chez Malt nous avons un chemin de progression qui est assez proche du standard :

A chaque niveau il y a deux éléments qui vont influer sur la progression :

  • le niveau d’impact (ou d’influence)
  • le type de personnes à manager

Par niveau d’impact, j’entends la capacité à avoir de l’influence sur des cercles de plus en plus grands : équipe (squads), communauté de pratiques, groupement d’équipes (tribe), département, société.

Et par type de personnes à manager, j’entends qu’il est assez différent de manager des contributeurs individuels, que de manager des managers. 

La encore, je vais vous renvoyer vers le site engineeringladders.com qui décrit plutôt bien la progression par niveau

L’Engineering Manager, en transverse ou au sein des équipes ?

Chez Malt nous avons fait le choix d’associer un Engineering manager à deux squads, ce qui représente environ 8/9 personnes en management direct.

Mais voici ce que l’on peut retrouver un peu partout :

  • un EM par squads (donc 4/5 personnes en management direct)
  • un EM en transverse qui a des personnes à manager venant de différentes équipes

La première option permet d’avoir plus de compréhension du travail effectué dans l’équipe, voire même d’y participer dans certains cas (le nombre de personnes à manager étant plus faible). Le risque étant de manquer de recul et ainsi de privilégier l’équipe au détriment du collectif, de conserver des biais propre à une équipe, notamment en recrutement, ou avoir des difficultés à prendre des décisions lourdes (car trop proche de l’équipe). 

La seconde option permet une gestion des individus avec une vision plus large que l’équipe (utile par exemple en cas de réorganisation), de laisser plus de temps sur les sujets d’efficacité collective (au détriment d’une contribution active au sein d’une équipe) mais peut rendre plus difficile la compréhension des soucis internes à une équipe. 

J’ai l’impression qu’aucune solution n’est parfaite. Le choix sera assez contextuel.

—-------------------------------------------------------------------

Pour conclure ce billet, je vais essayer de le rendre plus concret en listant quelques sujets traités par les Engineering Manager chez Malt :

Cette liste, loin d’être exhaustive, illustre la diversité de sujets. 

Et si vous voulez aller plus loin, je vous invite à naviguer sur les liens indiqués ci-dessous dans les sources.

SOURCE

http://www.engineeringladders.com/  : un super panorama des différents rôles dans une équipe engineering. Avec 5 axes d’analyse différents de celui de ce billet 

http://www.engineeringladders.com/TechLead-EngineeringManager.html  : un autre point de vue sur la différence entre tech lead et Engineering Manager (proche de celui de ce billet)

https://blog.pragmaticengineer.com/things-ive-learned-transitioning-from-engineer-to-engineering-manager/  : le point de vue d’un dev étant passé Engineering Manager

https://www.youtube.com/watch?v=Q_bJVokYLRI : une conférence de Lena Reinhard sur le métier d’Engineering Manager


Partager sur :