Suite de l’article précédent sur le Staff Engineer. Aujourd’hui, voyons un peu le métier au quotidien avec quelques aventures inspirées de la vie réelle…
Il est 10h15 et Célia, Staff Engineer chez Doctolib, repose la question à l’ensemble des personnes connectées sur le Google Meet :
« – est-ce qu’il y a eu une opération de maintenance ces dernières 24 heures chez le prestataire de télétransmission ? »
« – nous n’avons pas l’information, et il faudrait quelqu’un des équipes connecteurs pour vérifier »
« – ok, je sais qui pourra nous répondre, je prends »
« – merci pour ton aide Célia »
Il y a 9 minutes, une crise a été déclenchée par les équipes du support téléphonique. Les clients signalent que la télétransmission ne fonctionne pas ce matin. L’impact est direct pour plusieurs praticiens, qui ont l’habitude de gérer l’administratif avant de partir en déplacement toute la journée, pour visiter des patients.
Célia demande s’il y a eu une mise à jour aujourd’hui sur la passerelle de synchronisation, car c’est un domaine qu’elle connaît bien. Elle est Staff Engineer dans l’équipe qui gère la télétransmission, le moteur de facturation pour les médecins. C’est pour cela qu’elle propose de contacter directement l’équipe SRE-Core et de faire la vérification.
Pendant ce temps-là, l’Incident Manager, votre serviteur, demande à ce qu’une communication officielle soit envoyée aux clients, afin d’avertir de l’incident.
Célia revient quelques minutes plus tard et confirme qu’il y a eu une mise à jour la veille. A priori, un noeud n’aurait pas été relancé, ce qui perturbe la synchronisation des données.
Nous convenons de lancer un redémarrage forcé et de faire un point dans 4 minutes. Pendant ce temps-là, les clients attendent.
Mais Célia a eu le bon réflexe.
Il est 9h05 et sa journée de Staff Engineer commence…
Après ce démarrage exceptionnel, la journée est plus « calme ». Elle enchaine d’abord un point hebdomadaire avec les développeurs de plusieurs équipes. C’est l’une des composantes de ce rôle : il faut s’astreindre de venir rencontrer chaque semaine ou presque, les équipes de son domaine. Ce moment de 30 minutes est organisé autour d’un projet Asana partagé. Célia peut proposer des sujets à l’ordre du jour. Les équipes en retour peuvent pousser des questions ou soulever des points techniques à discuter.
Le Staff Engineer joue parfois le rôle de « Ministre des Affaires Etrangères » pour son groupe. Il va chercher et ramène de l’information.
Il prend des points d’action et se charge de trouver les bons acteurs pour résoudre ses sujets. Le piège serait de vouloir tout faire tout seul, mais on y reviendra plus tard.
Deuxième réunion avec les autres Staff Engineer. A l’ordre du jour : la migration vers TypeScript. Les Staff Engineer sont chargés d’aider plusieurs équipes de 5 à 7 développeurs. D’abord, où en est-on des ateliers proposés lors de la dernière réunion ? L’équipe décide de lancer une « guilde TypeScript » avec un appel au volontariat sur le channel slack des développeurs. Ce système de guilde pourra alors suivre chaque semaine l’avancé de la migration, relever les points de frictions, et aider les débutants. Le rôle des Staff Engineer sera d’assurer le bon fonctionnement de la guilde, et d’y participer. Nous nous rendons compte aussi que nous n’avons pas mis en place de tableau de suivi sur l’avancé de la migration. Christophe propose de créer un board sur Periscope, qui compte le nombre de fichier TypeScript versus JavaScript. Un autre propose d’ajouter une segmentation par équipe, pour suivre la dynamique et aider les équipes qui n’avancent pas sur le sujet. En tant que Staff Engineer, il est important de penser « observabilité ». Nos actions doivent servir à améliorer un indicateur, facile et rapide à lire, pour tout simplement expliquer notre travail. Les Principal Engineer coordonnent et reportent cela au niveau de l’ensemble des domaines, pour les 280 développeurs de l’entreprise.
Après la pause déjeuner, Célia assiste comme chaque lundi à la présentation des « Tech Scoping » de son domaine (une dizaine d’équipe par domaine). Chaque fonctionnalité importante est pilotée comme un mini-projet de 2 à 4 semaines. Au sein des équipes de développement d’ailleurs, chaque développeur sera amené à « piloter » de A à Z un projet. Pour cela, il/elle prépare un Tech Scoping, publié sur Confluence. Le document identifie le What/Why et le How. Il liste les risques et vérifie aussi l’impact sur la donnée, sur la production et sur la sécurité.
Cela demande une à deux semaines de préparation pour les développeurs. Le Staff Engineer intervient ensuite pour aider/valider et vérifier que le Tech Scoping est réalisable, n’ouvre pas de risque, et sera correctement exécuté. C’est un rôle de validateur technique. Elle assiste avec une soixantaine de développeurs à 3 présentations. Chacun peut poser des questions.
Et elle voit un risque sur une migration de colonne côté DB, point qu’elle se marque, et sur lequel elle contactera ensuite la personne une fois la réunion terminée.
Elle passe ensuite 2 heures seule sur un bout de code, pour l’équipe SPICE. Il y a 10 jours, Victor l’a contacté pour lui présenter les difficultés à faire migrer du code source d’une version 1 à une version 2 de l’API de gestion des documents. Il y a environ 70 fichiers. Victor aimerait que Célia force les managers et impose la migration. Ce n’est pas son rôle, et elle va devoir trouver une autre approche pour lancer la migration. Tout d’abord, depuis 4 jours, elle a beaucoup discuté avec Victor afin de lister les points qui ralentissent l’adoption et la migration.
Elle constate en effet que Victor a tenté de passer par les managers, et qu’il a été ghosté (comme disent les jeunes).
Après réflexion, elle a proposé le plan d’action suivant à Victor :
- créer une liste de l’ensemble des fichiers JavaScript utilisant actuellement l’API v1 ;
- associer/retrouver l’équipe avec le fichier de CODEOWNERS sur GitHub. Elle montre au passage l’utilisation d’un plugin sur RubyMine à Victor pour cela ;
- créer un board sur Périscope pour suivre le nombre de fichiers avec la v1 versus la v2 ;
- revoir la documentation actuelle, qui est trop complexe ;
Cet après-midi cependant, honnêtement elle galère avec le code à migrer. Si la nouvelle API est codée avec TypeScript, malheureusement le code « client » lui est toujours en JavaScript. Il y a bien la doc, mais il manque une vue plus facilement utilisable, pour celui qui souhaite migrer le code.
Après analyse, il est aussi impossible de migrer automatiquement le code. Le changement de paradigme et la nécessité de déclarer une configuration rend l’exercice plus compliqué.
Elle programme un point pour le lendemain, afin de discuter avec Victor sur ses observations. Son objectif est que Victor soit lui-même convaincu et qu’il propose une autre documentation, plus simple, ainsi qu’une Pull-Request de référence pour montrer le avant/après.
Son rôle ici est de poser un diagnostic, de proposer une solution, et d’aider Victor à terminer le travail. Ce n’est pas de faire la migration en tant que tel.
Elle pourra cependant en parler avec les autres développeurs en point hebdomadaire. Enfin, elle suggère à Victor de trouver un « champion » motivé dans chaque équipe concerné, et de le contacter directement pour coordonner la migration.
Un peu de disruptif parfois c’est bon pour toute l’organisation…
En fin d’après-midi, il y aura le Tech Time. C’est un événement toutes les deux semaines, qui dure une heure, avec l’ensemble des développeurs de l’entreprise. Tout se fait en remote via Google Meet. Durant cette heure, chacun peut présenter un sujet, avec un slot de 5 minutes à 10 minutes.
Elle contacte Fabien, un développeur d’une feature team, afin de vérifier qu’il a bien pris un slot pour présenter son plugin pour RubyMine. C’est elle qui l’a encouragé à venir parler devant les autres, et à faire connaître son travail. Cela grâce aux réunions de suivi de la semaine. Elle a aidé Fabien à préparer sa présentation, en lui suggérant d’enregistrer la démo, pour ne pas planter la présentation devant l’ensemble des développeurs. Faut dire aussi que Célia a l’expérience de Devoxx France…
Enfin pour terminer cette journée bien remplie, elle doit conduire un entretien de recrutement de System Design avec Edgar, un collègue en Allemagne. Célia a été sollicité comme les autres Level 4 chez Doctolib pour faire passer cet entretien de recrutement. Elle est en binôme avec Edgar qui a un peu plus
d’expériences sur cet exercice. Aujourd’hui ils vont passer 1h15 avec Andy, un candidat pour un poste de niveau 2. L’entretien est intéressant et se déroule en Anglais. Elle se marque de compléter la fiche du candidat le lendemain vers 9h, ce qui lui prendra 30 minutes.
En fin de journée, comme Florent lui avait montré lors de son arrivée, elle prend 10 minutes pour faire un bilan de sa journée. Elle décide d’annuler sa participation le lendemain à une formation afin de se garder plus de temps pour le problème de migration de l’API v1 vers v2. C’est elle qui gère son agenda et sa semaine, et qui doit donc préparer et ajuster en permanence son calendrier. La formation est proposée toutes les 2 semaines, elle pourra rattraper cela plus tard.
Elle décide aussi de s’ajouter un créneau d’1 heure pour relire un article sur CQRS, écrit par son collègue John. Il en a parlé au stand-up ce matin et elle a proposé de l’aider avant la publication sur Medium.
La veille techno est importante et elle se réserve 2 heures par semaine au minimum pour regarder des conférences, lire des articles ou même écrire des articles de blog.
Sur ce, il est temps de refermer l’ordinateur et d’aller courir un peu, la journée a été bien chargée.
Le batch de télétransmission est passé à 17h, et demain matin sera donc plus calme qu’aujourd’hui.
Fin de la journée.
Synthèse et différences avec le rôle de Principal Engineer
Le Staff Engineer et par extension les Senior Staff Engineer/Principal Engineer sont autonomes. Leur niveau d’autonomie augmente avec leur séniorité. Au niveau d’un Principal Engineer vous êtes le seul acteur de votre calendrier, et vous rendez compte de vos actions chaque semaine à vos collègues et au CTO. Pour un Staff Engineer, vous travaillerez sous la responsabilité d’un Senior Engineering Manager ou d’un Engineering Director. Vous serez plus le bras « armé » pour adresser les sujets techniques et d’organisation de plusieurs équipes.
L’intervention sur les crises est important. Cela vous force à agir en tant que Problem Solver. Les Principal Engineer peuvent en plus jouer le rôle d’Incident Manager. Là il s’agit de coordonner en situation de crise plusieurs équipes, de rester calme et de faire preuve d’autorité pour gérer les personnes dans la salle de crise.
Le Staff Engineer doit absolument aller chercher les sujets techniques auprès des équipes. Pour cela, il faut s’astreindre une politique régulière de prise de contact et de rendez-vous avec les développeurs. Le Principal Engineer procède à l’identique, mais doit en plus se coordonner avec les Senior Engineering Manager. Par contre, le Principal Engineer vient rencontrer et aider si nécessaire les Staff Engineer dans un domaine.
Un Staff Engineer peut faire partie d’une équipe transverse pour résoudre par exemple un problème de qualité de code, pendant 5 semaines. Il sera alors en service et en support des autres équipes qui ne peuvent pas se « débrancher » pendant cette durée. Le Principal Engineer lui, est à l’initiative de la création de cette équipe. Il est allé chercher et il a obtenu cette équipe auprès de l’Engineering Director. Il a aussi présenté l’initiative aux équipes produits et au support, afin de s’assurer que tout le monde comprenne l’initiative. L’impact est global au niveau de la tech.
Au sein d’un domaine (10 équipes, 60 développeurs), le Staff Engineer peut présenter et piloter des initiatives techniques. Par exemple, la mise en place d’un outil de calcul du temps de chargement des pages webs. Il identifie la solution, développe et met en production l’outil. Il peut aussi présenter l’intégration avec les équipes de la Data, pour créer des tableaux de bord de suivi des performances.
Le Principal Engineer de son côté sera chargé de reprendre l’initiative, d’identifier d’autres domaines où cela sera utile. Il pourra faire une présentation ou mettre en relation Célia, notre Staff Engineer, afin qu’elle aille faire sa présentation dans d’autres domaines. Il pourra ainsi contribuer à améliorer le suivi de la performance pour l’ensemble de l’entreprise.
Prendre la parole en public est quelque chose de grisant et de parfois, un peu nouveau pour un Staff Engineer. Cela commence par des prises de parole avec les autres développeurs dans son domaine. Mais sur certains sujets, le Staff Engineer pense qu’il pourra en parler en conférence. Le Principal Engineer est passé par le même parcours et il parle même maintenant de l’entreprise à l’extérieur en conférence. L’impact est global, on parle de l’entreprise en général.
Le Staff Engineer travaille avec un Engineering Director, main dans la main. Le Principal Engineer travaille avec un responsable de l’architecture et le CTO directement. L’un doit porter la vision de son domaine. L’autre doit créer la vision de l’ensemble des domaines.
Ce sont 2 rôles passionnants, et l’expérience aide à se sentir à l’aise dans ce rôle. L’important est d’ajuster son altitude et son attitude. Vous devez être positionné à la bonne hauteur, selon les attentes de votre rôle. Et vous devez toujours avoir une attitude pour inspirer et aider les autres.
J’espère vous avoir éclairé sur la différence entre les 2 rôles.
La suite, le complément du précédent article…
Merci pour ces infos, merci d’avoir été aussi rapide.
Bravo !
Super intéressant ! Le support est hyper réactif pour identifier/remonter un incident aussi tôt et aussi rapidement.
Par contre le choix de « poker » quelqu’un pour savoir si une maj’ a été faites sur l’infra est une question de rapidité ? Vous n’avez pas un board indexant ces changements ? Ça pourrait être intéressant
A noter que j’ai changé un peu l’histoire, car mon scénario laisse croire a tord que l’on anticipe pas. Un scénario plus réaliste est la panne d’un service externe.