Après une dizaine d’années en tant que développeur, vous serez un jour « Senior quelque chose » et face à un choix. Vous serez devenu une personne pleine de compétences techniques, autonome, capable d’écrire du code relativement correctement, animée par la passion de votre métier. Et vous devrez alors faire vos premiers choix pour la suite de votre carrière.
Je ne prédis pas l’avenir, mais je suis passé par là.
La moyenne d’âge des développeurs et développeuses augmente. Le nombre d’entreprises de la « tech » aussi, il est donc logique de se poser quelques questions sur la gestion de notre carrière.
Je propose de vous partager ma propre expérience chez Doctolib. Nous sommes aujourd’hui 280 personnes dans la branche développement, et presque 550 au total avec les équipes produits/design.
D’abord je vais présenter un outil afin de vous expliquer les choix de carrière qui s’ouvrent à vous. Ensuite, je présenterai la carrière de contributeur individuel (IC / Individual contributor) en complément. L’objectif étant de vous montrer un exemple d’organisation et de reconnaissance du niveau de chacun, afin d’ouvrir largement la discussion sur nos plans de carrières. Enfin je vous raconterai comment nous sommes évalués par nos pairs pour passer à un niveau supérieur.
J’ai recréé le triangle suivant pour pouvoir expliquer qu’il existe 2 types de parcours chez Doctolib. D’une part la voie du management, d’autre part la voie du contributeur individuel.
[Article édité le 21 juillet] à noter qu’un Engineering Manager peut passer vers la track IC (Individual contributor) en bleu et inversement, comme le précise Benoît en commentaire de cet article.
Initialement, vous démarrez uniquement avec des compétences techniques. Votre impact sera limité à votre équipe, et vous ne serez pas en charge d’autres personnes. Notre métier demande plusieurs années pour pouvoir atteindre une bonne autonomie. Vous pourrez ensuite former et partager vos connaissances.
C’est pour cela que lorsqu’un développeur se dit « Sénior » après 6 ans, je me dis qu’il/qu’elle n’est qu’au début de sa carrière.
Certes, vous êtes autonome, vous pouvez coder et trouver rapidement la solution à des problèmes. Cela vous confère donc le titre de « développeur sénior ». Je pense pour ma part, qu’avec le recul, j’ai terminé de me former et d’apprendre durant ce premier cycle. Oui, il faut plusieurs années pour maîtriser les concepts généraux du métier de développeur (réseau, modélisation, développement, travail en équipe, tests, conception et analyse, etc). Et surtout, nous apprenons à apprendre…
L’autonomie technique est le premier palier, qui permet ensuite de se positionner sur 2 voies distinctes. Si vous êtes plus animé par l’envie d’encadrer, d’aider et de coacher vos pairs, alors la voie du management est intéressante. Si vous avez envie de poursuivre sur la voie technique, mais d’impacter plus largement votre entreprise, alors la voie du contributeur individuel est pour vous.
D’abord, pourquoi avoir envie de « plus » ? Un meilleur salaire ? Plus de reconnaissances ? Plus de challenges techniques ? Je vous laisse répondre à ces questions. Tout le monde n’a pas forcément envie d’être « chef de… » ou de devenir la personne référente de l’entreprise.
Passé ce quart d’heure d’introspection, vous serez aussi confronté à ces choix car votre propre entreprise change. Elle est rachetée par un concurrent, elle fait faillite, ou alors elle lance un produit qui a du succès… Soyons réaliste : vous changerez une dizaine de fois d’entreprise. Peut-être moins, mais j’en doute.
Le Management comme l’Expertise vous demanderont ensuite d’avoir de plus en plus de Leadership. Par ailleurs, lorsque l’on parle d’expertise, ce n’est pas uniquement technique. Vous pouvez très bien avoir plusieurs compétences dans lesquelles vous êtes expert. Pour mon profil par exemple, je suis noté Level 5 sur la partie technique, et Level 6 sur la partie liée à ma capacité à communiquer/coordonner et impacter globalement l’organisation.
Comment devenir Staff Engineer / Principal Engineer ?
Tout d’abord, vous devez être quelqu’un avec qui les autres développeurs ont envie de travailler. Sincèrement. Cela veut dire que vous êtes sorti de votre propre zone technique, pour aller former et aider d’autres personnes. Cela me semble primordial pour pouvoir prétendre à une promotion.
Etre la personne avec laquelle les autres développeurs ont envie de travailler.
Didier Girard – Voxxed Days Luxembourg 2022
Ensuite, observez votre structure hiérarchique. Mon expérience est que vous ne pouvez obtenir votre nouveau rôle, que si votre responsable est lui-même en position de vous nommer, et qu’il a même déjà proposé d’autres personnes avant lui. Dans une startup, où le CTO (ou la CTO) occupe un rôle central, il sera difficile je pense de trouver sa place. Ce sera plus facile dans une structure assez importante avec au moins 50 développeurs.
Pourquoi je parle de taille d’entreprise ?
Car selon moi, la troisième raison qui vous permettra de devenir Staff Engineer, ce sera votre impact sur les équipes. Je vais expliquer ce que j’appelle « l’impact » car c’est la clé pour comprendre la mission d’un Staff Engineer, ou d’un Principal Engineer.
Chaque action que vous faîtes au quotidien, a un impact. Dans votre équipe tout d’abord avec de nouvelles idées techniques ou organisationnelles que vous proposez. Ensuite au niveau de plusieurs équipes, avec par exemple la mise en place d’un outil ou d’une pratique de développement logicielle. Puis ensuite au niveau de l’entreprise elle-même.
Avoir un impact sur toute votre entreprise est beaucoup plus difficile que d’intervenir sur une ou deux équipes. Cela demande de nombreuses compétences : technique, communication, marketing de vos idées, intelligence sociale pour comprendre les relations et de l’expérience. Avoir un impact sur votre industrie demande des années de travail. C’est ce que nous avons fait avec Antonio et Zouheir, avec la conférence Devoxx France.
Grâce à Nicolas Romanetti, j’ai retrouvé cet article sur les Levels chez Honeycomb.io. Et il y a surtout ce diagramme, que je trouve très utile pour expliquer l’impact.
Vous passez de l’exécution d’une tâche, à la mise en place de processus, puis la découverte de solution, et enfin, l’anticipation des problèmes. C’est l’axe vertical.
Sur l’axe horizontal, de la tâche unitaire, à l’impact sur l’entreprise : vous pouvez voir que votre scope sera de plus en plus large.
Lorsque vos contributions seront remarquées, ou quantifiées avec un outil de suivi, vous pourrez alors vous diriger vers ce chemin. J’ai eu l’impression cependant de devoir souvent faire mes preuves et occuper ce rôle avant d’être reconnu. Votre qualité technique sera alors une des composantes de votre profil, mais ne sera plus la plus importante. Arrivé dans le rôle de Staff Engineer, vos objectifs changent. Vous devez trouver des sujets pour faire avancer les autres, et faire avancer la tech dans son ensemble.
As-tu le temps de coder ?
Est-ce que je code encore ? En fait, quel est l’intérêt que je code seul pour l’entreprise ? La seule situation où j’ai réellement passé du temps à coder seul, ce fut à mon arrivée chez Doctolib. J’ai dû trouver une solution pour alléger le nombre d’appels sur le cache des Agendas de Doctolib. Nous étions en pleine campagne de vaccination. La base de données sur la partie Lecture nous posait pas mal de soucis chaque jour. J’ai proposé de mettre en place Redis pour pouvoir gérer un cache applicatif très simple. Cela m’a amené à écrire du code, à devoir convaincre d’autres développeurs, à faire des tests et à montrer le bien fondé du projet. Il impacte encore aujourd’hui la production de Doctolib.
Mais une fois le clavier reposé, en fait je crois sincèrement qu’il ne faut surtout plus coder seul. Sinon, cela nous enferme dans un rôle de pompier/sauveur et ne permet pas forcément de faire grandir les autres. En fait, à un moment de ta carrière, on s’en fout de savoir que tu es bon en Java, ou en Ruby. Par contre, est-ce que tu es capable de former et d’aider 3 personnes ? 10 personnes ? 30 personnes ? Est-ce que ta façon de travailler inspire les autres ? Et est-ce que tu es capable de débloquer des situations techniques et organisationnelles grâce à ton expérience ?
La composante Leadership est bien plus importante que la partie technique. Faire faire aux autres, et coordonner. C’est plus difficile que de faire soi-même rapidement sans faire grandir les autres.
Comment évaluer le travail et la contribution de chacun ?
C’est bien sympa tout cela, mais comment évaluer et promouvoir correctement les contributeurs individuels ?
Concernant Doctolib, que j’ai rejoint début 2021, nous avons mis en place un outil de suivi et d’aide pour les managers. Une équipe pilotée par le VP of Engineering est chargée de créer des outils, des processus et de former les managers pour qu’ils/elles puissent gérer la carrière de leurs collaborateurs.
Les Engineering Manager sont responsables de 5 à 8 personnes. Ils travaillent sur l’axe « Technique + Management ». Un « EM » est chargé du suivi, des entretiens hebdomadaires et mensuels, d’évaluer la performance, et d’accompagner chacun dans son quotidien. En plus de cela, un EM est aussi la personne référente technique et doit travailler main dans la main avec le Product Manager, son équivalent côté Produit.
L’une de ses missions est de faire grandir son équipe, et donc, d’accompagner chacun pour progresser.
Nous avons ensuite une grille pour les contributeurs individuels. La grille permet de se situer par rapport aux autres dans l’organisation. Elle détermine aussi les échelles de salaire pour chacun.
Voici la grille actuelle (Q2 2022) avec les différents niveaux :
Vous pouvez comparer cette grille avec d’autres entreprises comme Google ou Facebook avec ce lien sur Levels.fyi
Il est aussi intéressant de mettre en perspective la track du management et les niveaux respectifs :
Un autre diagramme met aussi en avant l’importance des « soft skills » selon les rôles/les postes. Ce diagramme montre que, plus vous souhaiterez passer à un niveau supérieur, plus vos compétences inter-personnelles seront importantes. Bien plus que vos pures compétences techniques. Je reconnais cela dans le rôle et dans le travail que nous faisons chaque jour. Une bonne part de notre travail est de coordonner, écouter et communiquer entre les équipes.
Les différentes tracks sont définies par niveau. Chaque niveau est défini en utilisant la matrice de Radford
- description du niveau
- scope et définition de la ligne de report
- compétences et connaissances attendues
- complexité du poste
- cadre définissant le niveau de supervision à mettre en place
- expérience
Un Senior Software Engineer Level 3 chez Doctolib sera par exemple caractérisé comme suit :
Description du niveau :
Level 3 Engineers are fully autonomous on complex projects within the team.
They should be seen as a bar raiser for their feature team, usually the most senior people you’ll find on a feature team.
They act as a coach to other team members, technical leader on projects. They can be assigned specific roles within the domain (e.g. Technical task Domain Owner), as they grow in seniority.
Scope / reports to :
Still within a feature team, but may report to a Senior Engineering Manager.
Still accountable to the work distribution with some flexibility (based on manager).
Skills :
Uses skills as a seasoned, experienced professional with a full understanding of industry practices and company policies and procedures; resolves a wide range of issues in imaginative as well as practical ways. This job is the fully qualified, career-oriented, journey-level position
Complexité du poste :
Works on problems of diverse scope where analysis of data requires evaluation of identifiable factors. Demonstrates good judgement in selecting methods and techniques for obtaining solutions. Interacts with senior internal and external personnel
Pilotage / encadrement :
Normally receives little instruction on day-to-day work, general instructions on new assignments
Nombre d’années d’expérience minimum requis :
Typically requires a minimum of 5 years of related experience.
Chaque poste est ainsi caractérisé avec des documents consultables sur Confluence. Nous pouvons voir les attentes pour chaque niveau, ce qui aide ensuite chacun à construire ses propres objectifs.
Vous connaissez maintenant les différents niveaux, parlons des promotions.
Comment se passe l’évaluation et la promotion au niveau supérieur ?
Lorsque quelqu’un souhaite être promu, il va alors préparer un « promotion case » qui sera ensuite évalué par un comité, le « promotion committee« .
Il y a 2 sessions par année, ce qui permet de grouper les évaluations par niveau.
Le promotion case est un document intéressant, et forcément un peu différent selon le chemin emprunté. Pour rester sur le sujet des « Staff Engineer », la version de ce document pour ce profil va se focaliser sur l’évaluation des 3 critères suivants :
- compétences techniques (avec 4 sous-critères)
- travail en équipe et réalisation de projets ( 4 compétences)
- influence (4 compétences)
Un Senior Software Engineer sera d’abord quelqu’un qui sera évalué sur les compétences techniques. Cela couvre 4 sous-critères :
- software engineering : identifie les bonnes solutions techniques et met en oeuvre de quoi résoudre des besoins
- craft : travaille en appliquant des techniques pour garantir la qualité. Capable de revoir et d’améliorer les pratiques logicielles
- operations : participe aux opérations quotidiennes de Doctolib, prend des actions en cas d’incidents ou de bugs, aide à améliorer les process pour réduire les incidents
- security : s’assure du respect de la sécurité, de la protection des données, des normes et de la qualité du logiciel.
Pour devenir Staff, vous voyez que 2 domaines importants sont ajoutés :
- compétences techniques
- travail en équipe et réalisation de projets
- influence
Travail en équipe et réalisation de projets
Ce critère mesure votre capacité à travailler en équipe, à mener à bien des projets dans l’équipe ou plus globalement, dans le domaine. Votre communication, la prise en compte des utilisateurs, ou votre stratégie sont évalués.
Influence
Votre influence est importante, car le rôle de Staff Engineer demande des capacités de communication et de présentation. Certains d’entre nous s’investissent dans le recrutement, donnent des présentations ou effectuent des interventions externes dans les écoles/universités, etc.
Promotion committee
Le « promotion committee » est composé de plusieurs personnes, de niveau supérieur. Elles consultent en général le manager pour pouvoir valider et confirmer les différents points. Et il est normal que des personnes proposées ne soient pas acceptées. Il est alors important d’expliquer les points à compléter, pour la prochaine évaluation. Comme ce travail est collégial, il est bien reçu par les collaborateurs.
A titre personnel, lorsque je dois évaluer si une personne peut devenir niveau 4 pour le poste de Staff Engineer, je vais vérifier que je suis capable de citer au moins un projet sur lequel la personne a joué un rôle important. Et si c’était vers un level 5, j’attendrai que la personne ait été la clé de la réussite du projet transverse. La partie technique pèse bien entendu dans l’évaluation.
Exemples :
Untel est proposé au level 4 car il a amené TypeScript dans son domaine, il a organisé des formations et il est référent sur le sujet.
Untel est proposé level 5 car elle a migré l’ensemble des services d’envoi des SMS de Doctolib, en montant une task-force interne sans interrompre le service et en réduisant la facture de 11%
(ces 2 cas n’existent pas dans la réalité, ne cherchez pas 😉 )
Et les salaires ?
Ces grilles évidemment sont utiles pour définir des grilles de salaire. Je vais travailler pour que ces grilles soient publiques, et que Doctolib puisse se poser comme une référence pour le marché Européen. Cela permettra d’avoir un cadre reconnu et ouvert, pour que l’ensemble de notre industrie prenne conscience de la valeur de notre métier.
Dans le milieu hospitalier, un chirurgien peut gagner entre 70k et 140 000 EUR brut par an. Les 2 Principal Engineer que je connais (et qui travaillent pour des entreprises américaines, en étant en France) émargent à plus de 150 000 euro brut par an, avec une part variable. Je connais aussi 2 Senior Staff Engineer qui sont entre 90k et 110k par an. Cela correspond évidemment à des années de travail, et au fait que ces profils peuvent réellement changer l’avenir technique d’une entreprise. Lorsque votre entreprise pèse plusieurs milliards, c’est finalement un bon investissement.
Est-ce que vous êtes bien payé ? Je ne sais pas. J’espère cependant que la présentation du parcours de contributeur individuel, ainsi que des attentes des entreprises selon les niveaux, vous aideront dans votre parcours professionnel. Un salaire se négocie par rapport à ses contributions et à sa capacité à évoluer. Si vous n’arrivez pas à évoluer, posez-vous la question de trouver un autre poste. Le marché reste dynamique, et j’espère que vous pourrez trouver le job de vos rêves. Sur l’ensemble des plans.
Lire la suite et découvrir le quotidien d’un Staff Engineer
Découvrir Doctolib
Liste des postes ouverts au recrutement
1 like
Merci pour l’article !
Je cherche à imaginer ce que ça peut donner dans une structure différente ; typiquement : une ESN…
Sur le carreer path et les comités de passage, pas de soucis. Mais sur l’impact…
Est-ce que tu pourrais expliquer la vie d’un Staff Engineer au jour le jour ? Passes t’il d’équipe en équipe pour accompagner, dispenser sa connaissance… ? Est-ce d’autres rituels qui « suffisent » ?
@Sebastien, sur l’impact en ESN je peux citer plusieurs exemples pour l’illustrer :
– X fait une veille régulière sur l’outil Y, il/elle blogge et fait des conférences dessus. L’éditeur finit par le/la remarquer et propose un partenariat exclusif avec son ESN pour la formation et la distribution en Europe
– X propose de monter une entité formation au sein de l’ESN, créé un mini site marketing pour l’alimenter, regroupe les autres consultants capable d’en donner, trouve les salles. L’activité formation se développe et représente Y% du CA annuel de la boite
– X est à l’initiative des Truc Tech days, journée d’échange mensuelle permettant de partager la veille de chacun sous forme de mini conférences
– X développe un outil pour faire du déploiement automatisé, il finit par en faire un produit sous forme de spinoff de l’entreprise
Tout ces exemples sont réels et je peux citer les personnes derrière 😉
Merci @Hugo pour ces exemples.
Ce sont finalement des situations que j’ai pu voir où côtoyer.
J’entendais tellement le débat (évoqué aussi par l’article) du « tu codes, tu codes plus » que j’étais un peu perdu dans mon positionnement…
Important de noter qu’à Doctolib, et surement autre part aussi, il est possible de passer d’un path à l’autre.
On a d’ailleurs plusieurs exemples de personnes managers (branche « management » sur le 1er graphique) qui repassent du côté contributeur individuel (branche « leadership »).