Senior avec 6 ans d’expérience, et après ?

Le sujet récurrent dans l’IT : si on est senior après 6 ans d’expérience, quel est l’avenir du développeur(euse) passé 10 ans ? 

Les vieux et vieilles développeurs(euses) sont-ils voué(e)s à partir élever des chèvres dans l’Ardèche ou pire, deviennent-ils tous manager ? 

S’il est vrai que la voie vers le management reste dans beaucoup d’entreprises la voie privilégiée, il y a d’autres modèles aujourd’hui. 

Ce billet sera fait en deux parties assez distinctes. 

Dans un premier temps je vous propose de parler des rôles de Staff Engineer, Principal Engineer, Fellow, Distinguished, de la notion d’impact et de fameuse question, faut-il devenir manager pour progresser ? 

Ensuite j’aimerais aller au-delà de ça. Je souhaite aborder comment un(e) Software Engineer peut apporter beaucoup d’impact. Ce sera directement illustré via ce que nous faisons chez Malt.

La double ladder ou dual ladder 

Au début des années 10 (2010 ^^) en France le chemin de progression était systématiquement le même, la technique devait conduire à l’expertise mais ensuite au management et tant pis si cela finissait par créer des mauvais managers via le fameux principe de Peter.

C’est vers la seconde moitié des années 10 en France que j’ai commencé à voir dans certaines entreprises des chemins de progression possible pour l’expertise technique. C’est resté rare, et si on parle salaire le plafond était plus vite atteint pour un expert technique qu’un manager.   

En fondant Malt, je savais déjà que je souhaitais innover sur ce point lorsqu’on a fait nos premiers recrutements tech en 2014, car il était évident pour moi que l’impact d’un très bon dev pouvait être crucial dans une entreprise. Si on s’accorde à dire que « software is eating the world« , alors avoir les meilleurs développeurs est un avantage concurrentiel, ce que les GAFAM ont d’ailleurs bien compris. 

Mais c’est en 2017 après une discussion avec Pierre-Yves Ricau de Square à SF que j’ai pu poser des mots et des concepts dessus. 

Je découvrais alors chez Square le concept de double ladder (ou dual ladder) et l’expression « contributeur individuel » (que je nommerais IC – individual contributor – par la suite).

Les principes sont simples :

  • on peut évoluer vers le haut de l’échelle dans tous les métiers, soit en tant que manager, soit en tant que contributeur individuel 
  • on peut évoluer en horizontal via les barreaux de l’échelle pour passer manager ou contributeur individuel 
  • un barreau correspond à un niveau d’impact attendu et un niveau de salaire, qui sera donc équivalent pour un manager ou un contributeur individuel

En 2017 chez Malt on introduisait donc ce concept de dual ladder et de career path (chemin d’évolution de carrière) qui donnait la part belle à l’évolution pour un contributeur individuel.

La version actualisée 2021 de ce career path ressemble à cela : 

Dans cette version 2021, vous noterez une branche “leadership”. C’est toujours une évolution de la branche IC mais nous avons souhaité mettre en avant le fait que les engineering leaders créent leurs succès avec les autres.

C’est tout l’enjeu des IC passé le cap de Senior, c’est d’être capable de rendre tout le monde plus productif et c’est là où l’expression 10x engineer prend tout son sens. 

La notion d’impact 

Si on parle d’expérience à travers le nombre d’années, on s’attend globalement à passer Senior entre 6 et 10 ans d’exp. 

Il serait même totalement illogique d’être encore Junior après 3 ans d’expérience ou de ne pas être senior après 10 ans. 

Mais passé le statut de Senior Software Engineer, la progression n’est plus automatique. On peut rester des années Senior et ce sera totalement normal (même si la rémunération peut augmenter). 

Pour évoluer il faut changer son niveau d’impact ce qui est loin d’être simple d’une part, et correspond presque à un nouveau métier d’autre part. 

Si je simplifie, le niveau d’impact est le suivant (chaque niveau implique un impact sur les niveaux précédents) :

  • Junior Software engineer : individuel, c’est une phase d’apprentissage personnel
  • Software engineer : phase de contribution au sein d’une petite équipe (la squad par exemple)
  • Senior Software Engineer : un impact sur l’équipe et les guildes (communautés de pratique)
  • Staff et Senior Staff :  une influence majeure sur l’équipe produit avec un relais en dehors
  • Principal : l’impact est désormais étendu à l’ensemble de l’entreprise
  • Fellow/Distinguished : un impact externe avec une reconnaissance en dehors de l’entreprise (sur sa propre industrie par exemple)

Les notions de Staff, Principal, Fellow et Distinguished ne vous sont pas familières ? 

C’est sans doute normal car ces appellations sont encore assez peu courantes en France. Pour autant, ces appellations sont de plus en plus répandues et standardisées dans la tech mondiale (source en fin de billet).

Si vous avez un doute, je vous invite à rechercher sur linkedin et vous trouverez des exemples, y compris en France. On va les aborder un peu plus loin.

Si on s’attarde sur la notion d’impact on peut noter schématiquement que l’évolution de carrière passe par une ouverture de plus en plus grande vers l’extérieur et une nécessité d’influence au sein de groupes de plus en plus larges. Le raccourci est simple entre cette ouverture vers l’extérieur, la gestion des rapports humains, la coordination et le management. 

Mais alors, est-ce qu’effectivement être développeur expérimenté passe par le management, y compris chez Malt ?

Est ce que c’est effectivement une fatalité de devenir de moins en moins hands-on (les mains dans le cambouis) ?

Les contributeurs individuels, pas des managers ? 

Tout d’abord j’aime bien rappeler la définition du management.

Wikipedia nous dit :

« Le management se définit comme l’ensemble des techniques d’organisation et de gestion pour conduire, piloter l’action des individus. »

Bref, lorsque vous mettez en œuvre des actions pour vous coordonner (méthode agile par exemple), pour améliorer la qualité (pair programming, peer review etc…), vous utilisez « des techniques d’organisation et de gestion », donc du management.

Selon moi, la caractéristique de la progression de junior vers senior et plus, c’est en premier l’acquisition des compétences de bases pour son métier, les fameuses hard skills (IDE, languages, concepts etc…) et c’est cela qui fait passer au statut de senior en 6 à 10 ans. 

(Je souris d’ailleurs toujours un peu quand je vois des leads tech avec 2 ans d’expérience…)

On ne s’arrête jamais d’apprendre ces fameuses hard skills par la suite, loin s’en faut. La veille technologique reste fondamentale pour rester au niveau. Mais l’étape suivante avec les années passe par l’acquisition des techniques d’organisation et de gestion, donc du management. Penser qu’on peut se passer de savoir communiquer, négocier, convaincre et que l’expertise technique suffit, c’est très réducteur.

La branche « IC »qui passe par Staff, Principal et Fellow n’est pas une branche de (people) management. Mais pour autant, à partir de Staff engineer on attend un impact large. Et pour cela, à partir de ces niveaux, il faut aussi développer des compétences en management :  pilotage, organisation et coordination d’équipe, développement des autres (coaching, mentorat), animation, négociation, etc.

On attend donc des personnes à ces niveaux d’être capable de 

  • communiquer sur les buts à atteindre
  • embarquer les autres autour de leurs idées
  • créer de l’alignement et faciliter la prise de décision collective
  • coordonner les efforts
  • se sentir propriétaire de ces résultats

Le métier à partir de Staff engineer évolue, et la part passée à ne plus développer en solo augmente. On attend d’un(e) Staff Engineer (et plus), une excellence technique, une vision technologique mais aussi une capacité à faire grandir des équipes entières. Si je caricature, je dirais qu’on développe, mais on développe aussi de plus en plus de l’humain et des groupes d’humains. Et c’est ça aussi être hands-on.

Si les parallèles sont nombreux entre par exemple le Senior Engineering Manager et le Staff Engineer, les différences sont nombreuses également :

  • L’Engineering manager (et les niveaux supérieurs) est attendu sur ses compétences en management, ses capacités d’organisation et d’influence. Il va travailler à fluidifier la communication entre groupes d’individus, gérer la croissance individuelle de chacun (people management), organiser le recrutement, mais aussi gérer les soucis de performance des individus et des équipes. Il va travailler sur la mise en place des bonnes pratiques (Agilité par exemple)
  • Le Staff Engineer est attendu sur ses compétences et son influence technique. Il doit être capable de coordonner des initiatives technologiques sur plusieurs équipes. Il va contribuer également au développement des individus de l’équipe par une assistance régulière, du pair programming, des conférences internes. 

Donc oui, le Staff Engineer a des compétences en management avec l’objectif d’élaborer une vision technologique et de la mettre en œuvre. 

Et pour cela, il/elle peut coordonner de façon directe ou indirecte de larges groupes d’individus. 

Pour la petite anecdote, c’est mon parcours de CTO. 

Il y a de très bons CTO qui sont passés soit par la branche management, soit par la branche IC. Pour ma part, je suis passé par la branche IC et aujourd’hui encore je ne me considère pas comme un people manager. 

J’ai dû apprendre au fil des années à cultiver mes soft skills pour que mon expertise produise de l’impact. 

Principal Engineer, Distinguished et Fellow un impact grandissant

Parlons rapidement de ces positions. Ces titres ne sont pas très répandus en France (bien que très répandus par ailleurs) mais je pense qu’en lisant ces définitions vous allez reconnaître des personnes que vous connaissez ou avez connu.

Le Principal Engineer est l’évolution du Staff Engineer. Si le Staff Engineer a un impact sur la technologie au sein de l’équipe produit, le Principal Engineer a une forte compréhension du business, et ses initiatives sont alignées sur les intérêts économiques de l’entreprise. Il sait traduire les besoins métiers en solutions technologiques et en KPI.

Il va être le moteur du déploiement d’initiatives qui vont au-delà de l’équipe produit. Il va discuter très régulièrement avec les équipes finance, support, commerciales. Il ou elle a constamment une longueur d’avance sur les besoins de l’entreprise et sait les traduire en solutions qui vont améliorer l’efficacité de l’entreprise dans les années à venir. 

C’est également une personne qui va porter la communication et permettre le succès d’initiatives techs à grande échelle. 

Distinguished et Fellow en plus d’avoir un impact significatif pour leur entreprise via une expertise technologique ont en principe une aura externe. 

Je n’en ferai pas une description exacte puisqu’il s’agit de titres un peu honorifiques. Il n’existe pas de fiche de poste précise.

On peut citer par exemple Kent Beck chez Gusto (créateur de XP, le canevas XUnit entre autres), James Gosling chez Amazon (créateur de Java), Gavin King chez IBM (créateur d’Hibernate, Ceylon et Seam entre autres). 

Inventer un nouveau langage n’est pas nécessaire mais devenir Fellow reste un accomplissement d’une belle carrière et d’un investissement personnel conséquent (dépôt de brevet ayant une large portée, leader sur des projets open source majeurs, etc.)

Software Engineer, votre mission si vous l’acceptez… 

Maintenant qu’on a vu comment nous voyons les choses sur l’évolution de carrière chez Malt pour les personnes souhaitant se concentrer sur leurs contributions individuelles, je souhaitais aborder un thème qui me paraît complémentaire.

J’aurais pu faire un second billet mais cela me semblait difficile de « juste » parler des paliers de séniorité sans parler du rôle de dev dans une équipe produit. Ce serait comme de parler uniquement de technique sans parler de « à quoi ça sert ».

Comme je le disais dans la partie précédente, les premières années pour un développeur permettent d’apprendre les fondamentaux de son métier, la technique, la veille, la collaboration, la méthode.

Ensuite il faut se concentrer sur le fait d’avoir de l’impact et cela passe par sa contribution au produit.

Attention je ne dis pas qu’on arrête d’apprendre sur les hard skills une fois atteint un pallier, loooiiinnn de là. C’est un travail constant de veille, même si je pense qu’on le fait aussi plus intelligemment. 

Mais revenons à nos moutons. Chez Malt un développeur peut contribuer sur deux activités clés : la discovery et le delivery.

Le Delivery 

Le delivery regroupe de façon très large de nombreuses activités : le développement en lui-même (coder, tester etc…), l’industrialisation, la mise en production, le monitoring etc…

On parle également de Build et de Run. 

C’est un sujet qui me semble aujourd’hui très largement documenté. Il existe un large panel de méthodes, de pattern, d’organisation. Les plus aguerris apprennent à piocher dedans en fonction du contexte. 

Chez Malt l’équipe de dev est responsable du delivery au sens large. 

Vous noterez que ce n’est donc pas le PM qui est le responsable du delivery. Il est consulté, notamment sur les plannings, mais il/elle ne gère pas l’équipe de dev, ce qui lui permet de se concentrer sur la phase de Discovery. 

Si toute l’équipe de dev contribue, le/la Lead Engineer est le relais de communication avec le product manager. 

C’est à lui/elle de mener les discussions dans l’équipe de dev pour déterminer comment on va industrialiser et comment on va créer un plan de bataille pour travailler de front, la dette, le build des solutions vues en discovery, le travail de fond, le support niveau 3 etc… 

L’équipe de dev, représentée par son/sa Lead Engineer, doit travailler sur les questions clés du delivery : fiabilité, sécurité, scalabilité et performance.

Son rôle est donc clé dans l’articulation entre discovery et delivery.

L’engineering manager de son côté travaille pour aider le/la Lead engineer, fluidifier la communication avec d’autres équipes, organiser les cérémonies nécessaires (rétro par exemple), aider à la mise en place de métriques d’équipe, se coordonner avec le VP Engineering pour le staffing des squads de sa tribe.

Dans certaines entreprises le/la Lead Engineer et l’Engineering Manager sont incarnés par une seule personne. Chez Malt nous avons choisi de séparer le rôle de management pur (incluant people management, recrutement, 1:1 etc…) du Lead Engineer. 

La Discovery

Si la phase de Delivery n’est pas une grande découverte pour la plupart, je remarque que la phase de Discovery n’implique pas toujours les équipes de dev qui sont parfois vues uniquement comme des exécutants en bout de chaîne, ce qui est sans doute l’une des plus grosses erreurs qu’une société puisse faire. 

J’ai malheureusement observé de nombreuses situations où l’équipe de dev découvre des solutions à implémenter lors de sprint plannings ou dans des kicks offs organisés en grande pompe.

C’est tellement dommage d’embaucher des Software engineers pour ne pas les impliquer dans la Discovery. Leur plus grande valeur n’est pas de « juste » coder, mais de concevoir des solutions technologiques pour répondre à des problèmes, d’où le “Engineer” dans Software Engineer.

Chez Malt les développeurs chevronnés (représentés par son/sa Lead Engineer) doivent s’impliquer dans la Discovery.

Pour rappeler brièvement en quoi consiste la Discovery, il s’agit d’un ensemble d’activités, piloté par le Product Manager, visant à :

  • déterminer l’ensemble des problèmes à résoudre, l’objectif étant « Design the right thing »
  • déterminer l’ensemble des solutions afin de « Design things right »

L’équipe de dev va être mise à contribution pour sa connaissance du produit existant, mais aussi la compréhension des besoins clients.

Elle doit être capable de mettre en place des solutions simples et rapides pour mettre en place des AB Tests, extraire de la donnée, faire des prototypes, construire des maquettes (basse ou haute fidélité).

C’est une étape qui nécessite pragmatisme et ingéniosité pour tester rapidement des hypothèses. On ne cherche pas à construire dans cette étape un produit industrialisé et scalable. 

Une équipe mature devrait avoir de multiples expérimentations en cours chaque semaine, et l’équipe de dev peut aider à cela. 

Je précise évidemment que le/la PM et le/la Product Designer peuvent aussi se passer de développement une grande partie du temps (interviews, nocode, maquette interactive avec Figma etc…). 

A cette étape l’équipe de dev est responsable de la question de la faisabilité et doit permettre rapidement de trouver les solutions les plus intelligentes ET faisables tout en discutant avec le/la PM qui est responsable de la valeur et la viabilité, et avec le/la Product Designer qui est responsable de l’utilisabilité.

Voici qui conclut ce billet qui avait pour objectif de présenter comment nous envisageons chez Malt la progression individuelle des contributeurs individuels après le fameux niveau de Senior. 

L’appellation Senior est trompeuse, le chemin est encore long, et c’est heureux vu le temps de carrière qui reste ensuite. L’un des principaux indices de progression est axé autour de l’impact que l’on peut apporter.

Et cet impact chez Malt se traduit notamment dans son apport à deux phases importantes du produit, le Delivery (classique sans doute), mais aussi la Discovery. 

Et si vous voulez voir ce que ça donne de l’intérieur, je vous invite à regarder nos postes ouverts : https://jobs.lever.co/malt 

Quelques références intéressantes :

Une réflexion sur “Senior avec 6 ans d’expérience, et après ?

  1. Pingback: Les salaires dans la tech | Eventually coding

Laisser un commentaire