- Quand faut-il un Staff Engineer, et quelle est la différence avec un Engineering Manager ?
- Beaucoup d’ingénieurs et de managers confondent encore ces deux rôles
- Des EM qui veulent éviter la gestion de personnes pour se concentrer sur la technique, ou des Senior Engineers qui souhaitent assumer un leadership technique, se posent ces questions
- Il est important de bien comprendre les responsabilités et le périmètre de chaque rôle
Les questions qu’on m’a posées
- EM : « Je veux me concentrer sur la technique plutôt que sur la gestion de personnes. Le rôle de Staff Engineer me conviendrait-il ? »
- Senior EM : « J’ai trop de tâches de management. Faut-il recruter un Staff Engineer pour lui confier le travail technique ? »
- Staff Engineer : « Dans les faits, je joue déjà un rôle de manager d’équipe, et cela me plaît. Devrais-je passer EM ? »
- Senior Engineer : « Quelles sont les responsabilités d’un Staff Engineer ? On dirait un développeur à la retraite. »
- New Staff Engineer : « Qu’est-ce qu’un “dotted reporting line” ? J’ai déjà un manager hiérarchique, dois-je aussi prêter attention à un autre manager ? »
Quand faut-il un Staff Engineer ?
- Les ingénieurs construisent et maintiennent la technologie, mais la technologie n’existe pas seule
- C’est une solution à un problème, et ce problème est défini par le produit
- Le produit rend un service à des utilisateurs finaux ou à des clients internes
- Le produit est un moyen de résoudre un problème utilisateur, par exemple :
- une application qui mesure la distance de course et permet de la partager avec d’autres utilisateurs
- un site de réservation d’hôtels
- une plateforme d’infrastructure utilisée par d’autres équipes
- un système de déclaration du temps de travail
- Les ingénieurs qui développent ces produits appartiennent en général à des équipes dirigées par un Engineering Manager (EM)
- L’EM est redevable (accountable) des membres de son équipe et des artefacts techniques qu’ils produisent
- Mais il peut devenir difficile d’assumer pleinement toutes ces responsabilités dans les cas suivants :
- lorsque l’équipe est très grande
- lorsque la technologie est trop complexe
- ou lorsque les deux se cumulent
- Dans ce cas, l’EM manque de temps et d’énergie (bande passante), et il devient difficile d’assumer parfaitement à la fois les responsabilités liées aux personnes et celles liées à la technique
- Si l’EM a du mal à remplir son rôle, on peut envisager deux stratégies de délégation :
- Délégation des tâches administratives :
- optimiser les processus et outils RH, ou
- recruter un assistant pour alléger la charge de gestion des personnes
- avoir un assistant dédié à une seule équipe peut sembler excessif, mais il existe aussi des cas où plusieurs équipes partagent un même assistant
- des outils d’IA peuvent également remplacer en partie certaines tâches mécaniques, comme la coordination d’agendas, les réponses aux questions de management ou la collecte de feedback
- un excellent système RH peut réduire radicalement la charge managériale
- Délégation du travail technique :
- recruter un Staff Engineer pour partager la charge technique
- En revanche, un assistant ou l’IA ne peuvent pas remplacer les tâches centrées sur l’humain qui relèvent du cœur du rôle d’un EM, comme :
- constituer une bonne équipe
- le mentorat
- les évaluations de performance
- le recrutement, etc.
- Par ailleurs, transférer tout le travail technique à un Staff Engineer est considéré comme un anti-pattern
- Un Staff Engineer ne doit pas jouer le rôle de traducteur technique de l’EM
- L’EM doit conserver un certain niveau de responsabilité technique
- Il est donc essentiel pour un Engineering Manager de garder un bon sens technique, et
Situations où un Staff Engineer est utile
- Un Staff Engineer peut apporter une vraie valeur à l’organisation dans les cas suivants :
- lorsqu’il existe une charge technique que l’EM ne peut pas absorber
- par exemple : beaucoup de legacy à maintenir en continu
- lorsqu’il existe des solutions complexes qui traversent plusieurs équipes ou exigent une expertise technique approfondie
- ou, même si c’est une mauvaise pratique, lorsque l’EM lui-même n’est pas technique
- lorsqu’on peut lui confier une redevabilité (accountability) claire sur une partie du travail technique
- lorsque le périmètre technique dépasse ce qu’un seul EM peut piloter
- Un Staff Engineer doit être redevable de la technique, pas des personnes
- cela n’inclut pas la gestion des membres d’équipe ni les entretiens de performance
- Comme chaque organisation, produit et personne est différent, il est impossible d’appliquer une règle universelle à toutes les situations
- Remarque : responsibility et accountability sont des notions proches mais distinctes ;
- Un Staff Engineer doit avoir les caractéristiques suivantes :
- une compréhension technique profonde et une forte culture technique
- une redevabilité technique (accountability) clairement définie
- davantage de temps investi dans la technique, puisqu’il n’a pas de responsabilités de management de personnes
- En revanche, un EM ne doit pas non plus se désengager totalement de la technique
- il doit toujours rester impliqué et garder une certaine compréhension du sujet
- La vraie valeur d’un Staff Engineer vient de son leadership technique transverse sur plusieurs équipes
- Mettre un Staff Engineer à l’intérieur d’une seule équipe peut créer les problèmes suivants :
- un chevauchement des responsabilités techniques
- de la confusion sur les rôles, et au final l’inefficacité consistant à découper un même rôle en plusieurs intitulés
Cas exceptionnels où il peut agir au niveau d’une équipe
- En général, un Staff Engineer se concentre sur le leadership technique transverse, mais dans certaines situations il peut aussi intervenir temporairement au niveau d’une équipe :
- lorsqu’un nouvel EM doit rapidement comprendre une stack legacy
- lorsqu’un nouveau Staff Engineer s’onboarde en commençant par un périmètre réduit
- lorsqu’il y a trop de dette technique et que les indicateurs de santé du système se dégradent
- lorsque la complexité technique rend la maintenance difficile
- Dans ce cas, un Staff Engineer rattaché à l’échelle d’une équipe doit rester une configuration temporaire
-
La vraie valeur d’un Staff Engineer
- jouer un rôle de liant (glue) entre les équipes
- travailler sur le terrain avec les autres ingénieurs et faire remonter leur voix vers le management
- en général, les ingénieurs parlent plus franchement à des pairs ingénieurs qu’à une personne qui a autorité sur leur salaire, leurs congés ou leur évaluation
- exercer un leadership techniquement profond
- contrairement à l’EM, il a moins de réunions, de 1:1 et de tâches managériales, ce qui lui permet de se concentrer sur le développement de ses capacités d’ingénierie et de sa profondeur technique
-
Le plus grand risque : l’Ivory Tower Architect
- devenir un théoricien abstrait éloigné des problèmes réels et du code
- ce problème est traité en détail dans Ivory Tower Architect
Le rôle du Staff Engineer pour les systèmes couvrant plusieurs équipes
- Le Staff Engineer est particulièrement adapté à un leadership technique qui couvre l’ensemble d’un système, et non une seule équipe
- Dans l’essai de Will Larson, quatre archétypes de Staff Engineer sont proposés :
- Tech Lead : leader technique au sein d’une équipe
- Architect : concepteur de l’architecture système
- Solver : résolveur de problèmes techniques complexes
- Right Hand : bras droit d’un leader de l’organisation technique
- Il est difficile d’appeler Staff Engineer le Tech Lead d’équipe montré dans ce diagramme
- la vraie valeur d’un Staff Engineer vient de la coordination inter-équipes et de l’intégration technique
- voir Introduction to Staff Engineering
- un Staff Engineer n’est pas qu’un simple intitulé de poste, c’est une posture fondée sur le leadership technique
- ce rôle consiste à assurer la coordination technique et la résolution de problèmes à travers différentes équipes et différents produits
- il exerce de l’influence sans autorité formelle sur les personnes ou les produits, et guide la stratégie et la direction techniques de l’organisation
- contrairement à un Engineering Manager, il crée de la valeur moins par le management que par une expertise technique approfondie et la collaboration transverse
- il garde les mains dans le cambouis, participe au concret et joue aussi un rôle de mentor pour aider les autres ingénieurs à progresser
- Dans les organisations réelles, les systèmes techniques ne sont pas limités à une seule équipe ; ils sont souvent répartis entre plusieurs équipes ou fortement interconnectés
- dans ce cas, il faut un Staff Engineer dédié qui porte la responsabilité de l’ensemble du système
- quelle que soit la répartition des responsabilités entre les équipes, il faut une vision d’ensemble du système et un sens de la responsabilité associé
Un Staff Engineer doit passer non seulement par la technique, mais aussi par les personnes et le produit
- Point clé : la tech ne parle ni n’écoute par elle-même
- la technologie ne peut pas exister seule ; elle prend son sens à travers les personnes (ingénieurs) et le produit (le problème)
- Pour qu’un Staff Engineer crée une vraie valeur, il doit impérativement passer par :
- la collaboration avec les ingénieurs
- les échanges avec l’équipe produit
- C’est pour cela qu’un Staff Engineer a des dotted reporting lines
- un lien informel mais important entre la collaboration transverse et les engagements d’organisation
- Certaines personnes attentives demandent parfois pourquoi les flèches partent vers le bas depuis le Staff
- Raison 1 : un bon leadership repose sur la collaboration, pas sur l’autorité
- le Staff Engineer adresse aux EM ou PM d’équipe des demandes d’amélioration technique dans une logique de coopération
- il ne s’agit pas de directives unilatérales, mais d’une démarche collaborative tenant compte des ingénieurs et de la roadmap produit
- Raison 2 : le Staff Engineer est un IC (Individual Contributor), il n’a donc pas de subordonnés directs officiels
- s’il existe avec les EM/PM des canaux de discussion réguliers, ceux-ci ne devraient pas servir à faire du simple reporting, mais à avoir :
- une discussion sur l’état actuel de la technique (status quo)
- une vision technique (vision) pour résoudre les problèmes produit
- une stratégie technique d’organisation (strategy) pour y parvenir
- et, idéalement, un dialogue bidirectionnel sur ces trois sujets
- Pour clarifier cette structure de reporting imbriquée et aider à l’alignement technique/produit entre équipes,
- un document de stratégie à l’échelle de l’entreprise est très utile
- les bases sont présentées dans Strategy basics
-
Diagnostic
- après avoir exploré l’espace du problème, on identifie les enjeux clés à résoudre et les raisons pour lesquelles ils comptent
- cela explique pourquoi une stratégie est nécessaire
- on identifie les symptômes et les causes profondes, puis on analyse pourquoi ils sont importants maintenant
- dans une mauvaise stratégie, cette partie est souvent omise ou se limite à décrire l’état actuel
- un bon diagnostic exige une enquête objective et une posture de détective
-
Guiding Policy
- c’est une approche de haut niveau pour résoudre les problèmes identifiés
- elle se concentre sur la solution et aligne l’ensemble de l’organisation
- elle donne une direction sans obliger à reposer la question à chaque détail tactique
- dans une mauvaise stratégie, le lien entre cette policy (HOW) et le diagnostic (WHY) est absent
-
Coherent Actions
- c’est un plan d’action concret pour résoudre, conformément à la policy, les problèmes identifiés dans le diagnostic
- il clarifie qui (WHO), quoi (WHAT) et quand (WHEN)
- le point essentiel est la cohérence, afin que les différentes équipes avancent ensemble dans la même direction
Une autre manière de réduire le périmètre technique à une seule équipe : le modèle Kebab vs Cake
- On peut aussi concevoir la structure de l’organisation pour que la technique ne s’étende pas sur plusieurs équipes et soit résolue à l’intérieur d’une seule équipe
- L’une des approches représentatives est précisément le modèle Kebab vs Cake
- une approche structurelle qui compose les équipes autour du parcours utilisateur afin de réduire le périmètre de responsabilité technique
- pour plus de détails sur ce modèle, voir Kebab vs Cake organization
-
Architecture Kebab
- les équipes sont organisées autour des fonctionnalités fournies
- le parcours utilisateur traverse les artefacts produits par plusieurs équipes
- Avantage : autonomie et faible couplage
- Inconvénient : risque de handovers
-
Architecture Cake
- les équipes sont organisées autour du parcours utilisateur
- la charge cognitive est gérée au moyen de couches d’abstraction
- Avantage : ownership end-to-end et réduction des handovers
- Inconvénient : risque d’augmentation de la charge cognitive
- Le Staff Engineer n’est pas un simple rôle technique, c’est un owner responsable de l’ensemble du système, qui doit réunir ces trois éléments :
- Knowledge :
- une compréhension approfondie de la stack technique et des problèmes produit
- il doit être capable, si nécessaire, de les expliquer et de les implémenter lui-même
- Mandate :
- une position qui lui permet d’avoir son mot à dire sur la manière dont la technologie va évoluer et être maintenue
- Responsibility :
- la responsabilité de l’état de santé du système (incidents, dette technique, documentation, ruptures techniques, etc.)
- Le Staff Engineer n’est pas un rôle purement technique ; pour guider l’organisation sur le plan technique, les soft skills sont indispensables
- communication d’influence, capacité de collaboration, leadership, etc.
- Mais si l’on se concentre uniquement sur les soft skills, on risque de voir apparaître les problèmes suivants :
- présenter des idéaux déconnectés de la réalité sans participer au code ni à la résolution concrète des problèmes
- et dériver vers le profil d’Ivory Tower Architect
Conclusion
- Toutes les organisations n’ont pas besoin d’un Staff Engineer. On peut très bien s’en passer dans les cas suivants :
- lorsque l’EM a une capacité technique suffisante pour diriger directement la technique de l’équipe
- lorsque la stack technique est saine et facile à maintenir
- lorsque la technique est contenue dans une seule équipe et qu’il y a peu de dépendances inter-équipes (le modèle organisationnel Cake en est un exemple)
- lorsque l’organisation est assez mature pour bien faire fonctionner l’ensemble du système sans owner spécifique
- À l’inverse, si une organisation a des Staff Engineers, elle doit clarifier les points suivants :
- définir clairement la technical ownership
- et donner au Staff Engineer une accountability explicite sur cette responsabilité
- En résumé :
- il faut éviter l’Ivory Tower Architect (déconnecté du réel)
- découper un rôle en plusieurs intitulés est inefficace
- un EM non technique est lui aussi inefficace
- Enfin, ce texte n’est pas une règle absolue, mais un essai de référence
- chaque organisation, technologie, produit, mode de fonctionnement et personne est différente, donc un jugement souple et adapté au contexte est essentiel
- éviter l’imitation aveugle (cargo culting) → voir l’article associé
4 commentaires
On a l’impression que ce sont les bras droits du CTO.
Ingénieur staff : la personne qu’on va embêter quand on a tout essayé et que rien ne marche.
Ah putain mdr, tellement vrai
Ce n’est pas vraiment très lié au contenu de l’article, mais comme je réfléchissais justement aux notions d’accountability et de responsibility, le lien suivant m’a été d’une grande aide.
https://blog.alexewerlof.com/p/accountable-vs-responsible