Ce document décrit le poste de Staff Software Engineer chez Inch. Cette version est quasiment identique à la version interne à part à quelques endroits indiqués par le mot SNIP.
Les niveaux de début de carrière d'un ingénieur logiciel (on va dire dev par la suite) sont relativement bien connus, en gros :
- Junior Software Engineer
- (Mid-level) Software Engineer
- Senior Software Engineer
La progression se fait sur la base de l'expérience et on attend d'un bon dev qu'il passe mid entre 2 et 5 ans d'expérience et senior entre 5 et 10 (en gros).
Un dev senior a 2 possibilités pour évoluer : faire du management ou rester dans l'expertise technique. Ce document décrit la 2e voie.
Quelques points à comprendre dès le départ concernant le management :
-
Une "équipe" de développement (projet ou run) est typiquement de 3 à 10 personnes.
-
Une "équipe" est menée par un "lead". Lead n'est pas un niveau ni un poste de management, c'est un rôle technico-organisationnel qui est pris par un dev Senior ou plus à un moment donné.
Les noms des niveaux après Senior diffèrent selon les entreprises mais on a par exemple :
- Staff Software Engineer
- Senior Staff Software Engineer
- Principal Software Engineer
- Distinguished Software Engineer
- Fellow
Dans de grandes entreprises tech le niveau "Distinguished" correspond à VP et Fellow correspond à SVP ou CXO. Dans la grille de Inch, Staff correspond au niveau F. On voit parfois que la différence se fait sur le scope de l'impact :
- Staff / Senior Staff -> impact sur l'équipe produit / tech
- Principal -> impact sur toute l'entreprise (stratégie)
- Distinguished -> impact en-dehors de l'entreprise (aura)
Ces niveaux forment une "pyramide" dont chaque étage doit être beaucoup plus petit que le précédent (e.g. facteur 5) sinon ils ne veulent plus rien dire.
Étant donné la taille de Inch, seul le niveau Staff a du sens. Le niveau Principal (qui est en général le 2e créé) ne le sera que quand l'entreprise sera de taille suffisante pour avoir plusieurs équipes techniques (au moins 12 devs, idéalement plutôt vers 30). Du coup certains attendus en terme de stratégie et d'aura se retrouvent dans le profil Staff chez Inch.
Une chose importante est que Senior est un "terminal level", c'est-à-dire qu'on n'attend pas nécessairement qu'un développeur Senior devienne Staff dans un temps donné. Un développeur peut théoriquement très bien rester toute sa carrière dans l'expertise au niveau Senior.
La progression Junior / Mid / Senior est très liée à l'expérience et aux compétences techniques (et humaines pour Senior). Mais la valeur de l'expérience marginale décroît avec les années, et est de plus en plus difficilement mesurable.
Le niveau de Staff est quand même partiellement lié à l'expérience (on va en général attendre au moins 8 ans d'exp d'un Staff) mais surtout à l'impact au sein de la société. Ce qui signifie qu'il est très rare d'embaucher quelqu'un à ce niveau, et qu'il n'est pas anormal que quelqu'un qui est Staff dans une entreprise repasse Senior pendant quelques années en en changeant.
À noter : que bien que Staff ne soit pas un niveau de management il nécessite plus de compétences "humaines" (soft skills) que les niveaux précédents (voir plus loin).
Staff est un niveau de spécialisation technique et donc tous les Staff ne se ressemblent pas. Pour comprendre les différences voilà quelques axes.
Un dev peut se spécialiser dans un domaine ou une technologie donnée (ou quelques-uns) et devenir un vrai expert du sujet. Par exemple, il peut connaître son langage et son framework sur le bout des doigts et contribuer au core ou à son écosystème, ou devenir un vrai expert d'un métier en parallèle. On parle alors d'experts (depth).
D'autres au contraire étendent leurs connaissances plutôt horizontalement et connaissent de nombreux domaines, technologies et bouts de la stack. On parle de généralistes (breadth).
En réalité on a souvent un mélange des deux : des devs avec de très larges bases et quelques sujets de spécialité. On parle de T-shaped.
Will Larson définit 4 types de "Staff+" : les "tech leads", les "architectes", les "solutionneurs" et les "mains droites".
On attend d'un Staff les savoir-faires suivants :
-
Appréhender un système complexe et mal documenté rapidement, par exemple identifier la cause d'un bug dans une base de code mal maîtrisée.
-
Comprendre ce qui limite un système, anticiper les blocages et proposer des évolutions architecturales réalistes et pragmatiques en tenant compte de l'existant et des ressources disponibles.
-
Connaître et comprendre les principes d'architecture logicielle et système haut niveau (Loi de Conway, Loi de Gall, modèles de permissions, types de flux de données...)
-
Communiquer avec son équipe en tant que Lead, organiser un projet ou mettre en place de nouveaux process.
-
Communiquer avec le management : rapporter ses résultats et ceux de son équipe, donner de la visibilité sur la charge et les projets en cours.
-
Communiquer hors de l'entreprise, par exemple : avec des clients, avec des prospects, avec des candidats, avec des investisseurs, avec des projets Open Source... (note : correspondrait plus au niveau principal / distinguished dans une entreprise plus grosse)
-
Gérer une crise, par exemple organiser la réponse à un incident de production.
-
Analyser une opportunité de développement en prenant en compte tous les paramètres au niveau de l'entreprise (cash flow, stratégie et positionnement, vision long terme...). Penser à 2 mois / 6 mois / 18 mois. (note : correspondrait plus au niveau principal dans une entreprise plus grosse)
-
Comprendre les concepts de backlog, de vélocité / capacité / pression. Savoir prioriser, comprendre quand dire oui et quand dire non. Savoir jusqu'à quel point défendre son opinion en fonction du sujet, quand avoir raison.
-
Penser les développements et les choix en prenant en compte les impacts sur la maintenabilité, la stabilité, l'évolutivité, la complexité et la performance globale.
-
Savoir anticiper les recrutements et les risques de départ. Comprendre qu'un recrutement prend 6 mois (recherche + préavis) + 6 mois pour devenir vraiment efficace. Comprendre qu'à l'échelle de Inch tout le monde n'est pas remplaçable, mais savoir réduire le risque pour l'entreprise en cas de départ imprévu y compris le sien.
-
Faire de la veille, mettre en place de nouveaux outils ou process quand c'est nécessaire. Ne pas le faire ou les retirer quand le bénéfice n'est pas évident. Canaux de veille utilisables : HN / Lobste.rs / Tilde, blogs, podcasts, meetups, feed GitHub, réseaux sociaux...
-
Être visible. Communiquer en interne sur ses avancées et celles de son équipe, à l'oral et à l'écrit si besoin.
-
Développer un réseau. À ce stade d'une carrière, un développeur doit connaître des gens à contacter pour avis sur des sujets très pointus, du recrutement, etc. Ce genre de réseau s'acquiert par les expériences précédentes, la participation à des meetups et conférences, des projets Open Source, etc. (note : correspondrait plus au niveau principal / distinguished dans une entreprise plus grosse)
On attend d'un Staff qu'il coche certaines cases parmi les suivantes :
-
Être l'expert de référence sur une ou plusieurs parties significatives de la stack technique ou sur un sujet technique (frontend, backend, infra / déploiement, sécurité...)
-
Être l'expert de référence sur une ou plusieurs parties significatives de la codebase du produit (SNIP)
-
Avoir réalisé ou mené un développement ou une évolution très marquant(e) pour l'entreprise, reconnu au-delà de la simple équipe technique. Souvent on confiera volontairement ce genre de projet visible et compliqué à un Senior prêt à évoluer (Staff Project) ; dans certaines sociétés c'est obligatoire.
-
Mentorer un / des juniors. Ce point est dans "achievements" et pas "compétences" : tout Staff (et même Senior) doit être à même d'aider un junior à progresser ou comprendre quelque chose ponctuellement, mais certains développeurs peuvent être de véritables "accélérateurs" pour les juniors avec lesquels ils travaillent.
- StaffEng (Will Larson) - le site et le livre
- Levels.fyi
- Career Ladders
- Engineering Organization Tracks - Présentation (interne - SNIP)
- Engineering Ladders framework
- Handbook de Basecamp
- Ladder de Mozilla
- Ladder de Rent The Runway
- Ladder de Kickstarter
- Ladder de Criteo
- Fonctionnement de GitLab
- Fonctionnement de Spotify
- Growth Framework de Square
- Dropbox Engineering Career Framework
- Google =)
- Hugo Lassiège chez Malt
- Nicolas Martignole sur le poste Principal Engineer chez Doctolib
- Understanding Project Management Will Improve Your Developer Job
- If Management is the Only Way Up, We’re All F’d
- The Conjoined Triangles of Senior-Level Development
- Werner Vogels on skills
- Software Architect – A Role, Not a Job
- Devenir Staff Engineer : comment et pourquoi ?