Comme souvent, notamment sur les sujets de ce type, ce blog est l’occasion pour moi de mettre par écrit des idées qui me trottent dans la tête et de déclencher des discussions intéressantes. Comme on dit souvent, Views are my own, not my employer, et mes articles sont le fruit de toutes sortes d’expériences, discussions, remises en question…​actuelles ou passées, et ne reflètent pas forcément comment je travaille au quotidien ;)

Comme dit précédemment de nombreuses boîtes Françaises (notamment des boîtes tech type scale-up) mettent en place des "career tracks" pour définir clairement les évolutions possible de leurs employés, avec deux chemins possibles: devenir manager (gérer une équipe, puis gérer un département…​) ou devenir expert (staff, senior staff, principal engineer).
On va s’intéresser dans cet article à la seconde catégorie.

Le but de cet article n’est pas de décrire comment fonctionnent les careers tracks dans la tech, lisez cet article d’Hugo Lassiège avant cet article si vous n’êtes pas familier avec ces concepts.

Le mot "impact" est souvent mentionné lorsqu’on parle de devenir staff engineer ou plus. On s’attend à ce que vous ayez un impact dans votre équipe puis au delà: à l’échelle de la tech, de toute l’entreprise, voir que vous rayonnez à l’extérieur.
On trouve beaucoup d’articles expliquant comment devenir staff: "trouver" des sujets transverses sur lesquelles travailler, se faire remarquer…​ presque parfois pour moi à l’excès où le processus de promotion est presque devenu un jeu où il faut "grind" pour monter (mais c’est un autre sujet).
De mon côté c’est en partie ma frustration qui me porte, de "il y a des quick win à faire sur ce truc" à "cette techno/pratique que toute la boîte utilise ne devrait pas exister dans tous les mondes du multivers, allons régler son compte à cette dinguerie".

Vous avez donc un champ d’action de plus en plus large, avec en parallèle une attente sur faire monter en compétence des gens sur toutes sortes de sujets, savoir débloquer des situations diverses et variées, mettre en place des indicateurs pour que les gens puissent suivre ce qu’il se passe (si j’avais envie de troller, ce qui n’est pas du tout mon genre, je dirai que créer des dashboards Grafana avec du vert et du rouge est peut-être le meilleur moyen de rendre des chefs heureux). On vous demandera d’aligner les gens et les équipes pour mettre tout le monde d’accord, savoir prioriser, communiquer avec le management, aller aider dans des incidents et post mortems…​ Des journées bien chargées en somme.

Des journées bien chargées, et assez diverses. Enormement de staff engineer et plus le disent: ils font moins de "tech pure" qu’avant. Ceux côté dev vous dirons même peut-être "c’est devenu bien rare que je code". Ce sont des personnes qui vont plus être là en support, pour coordonner et conduire des changements, pour proposer une certaine vision tech. Vous ne faites au bout d’un moment plus partie d’une équipe, vous êtes en dehors.

Mais comment développer l’expertise technique si vous ne pratiquez plus ?

Prenons l’exemple fictif d’Yvain, SRE dans une équipe s’occupant de la stack d’observability de l’entreprise (et chevalier sur son temps libre).
Yvain a une très grosse expertise sur certains sujets liés au monde de monitoring et a un fort impact dans son équipe et ailleurs grâce à la performance des outils mis en place (tracing, logging, SLO, whatever). Yvain a aussi la chance d’avoir pas mal baroudé dans ses boîtes précédentes et donc a des connaissances assez larges qui lui permettent d’intervenir sur mal de sujets d’autres équipes.

Rapidement Yvain va passer Staff engineer, et plus ensuite. Il commence donc à travailler sur toutes sortes de problématiques transverses et interagit avec beaucoup d’équipes sur toutes sortes de sujets. D’ailleurs, il n’a plus trop le temps à consacrer à l’équipe d’où il vient à la base, ce n’est plus vraiment son rôle même.

Un jour, Yvain vaque à ses occupations habituelles de staff et se pose une question. Oui, il réussit à porter des sujets transverses, mais quid de son expertise précédente ? Aujourd’hui, ce n’est plus lui qui travaille directement sur l’évolution de la stack d’observability de l’entreprise, pourtant il était très bon à ça et il sait qu’il y avait beaucoup plus à faire pour arriver à l’état de l’art. Mais ce n’est plus son rôle, au mieux il peut donner un coup de main à l’occasion.

Est-ce que le risque n’est pas d’envoyer vos meilleurs éléments dans des rôles où l’excellence technique et leur capacité délivrer leur est finalement moins utile, car accès sur l’accompagnement et l’alignement (et la politique associée) ? Est-ce qu’on ne devrait pas au contraire encourager des individus à devenir de vrais experts reconnus sur leurs sujets (ce qui demande énormément de pratiques et veille au quotidien), et ensuite avoir un impact transverse grâce à l’excellence des solutions qu’ils mettent en place dans un scope précis ? Est-ce que l’impact "vertical" n’est pas plus intéressant que l’impact "horizontal" en sautant de sujet en sujet ? Est-ce que le discours "fini d’aller mettre les mains dans le cambouis à partir d’un certains niveau" n’est pas en réalité contre productif ?

Signé: un senior staff.