L'Impact individuel dans une équipe engineering
Quel a été votre impact dans les 6 derniers mois ?
Cette question vous paraît difficile ?
Comme je le disais dans le chapitre précédent, il arrive que les développeurs(euses) ne participent pas à la création du produit, alors même que les produits de demain ne peuvent se concevoir sans les ingénieurs qui les réalisent.
Et si les raisons peuvent être diverses, parfois ce sont les développeurs(euses) eux-mêmes qui se mettent en retrait et appréhendent incorrectement l'impact qu'ils peuvent apporter ou comment le créer.
La première partie de carrière en ingénierie consiste à acquérir des compétences techniques et des méthodologies de travail. La pente est rude, d’autant qu’on prend vite conscience que ce travail doit se poursuivre toute la vie pour se tenir à jour.
Mais ce n’est en réalité pas le bout de la route.
L’impact que l’on peut créer ne dépend pas que de l’expertise, même si celle-ci est nécessaire.
Tout est question d’impact
Je vais beaucoup parler d’impact dans ce livre, c’est même l’un des termes principaux de son titre. Alors, je pense que c’est nécessaire avant d’aller plus loin de mettre une réalité en face de ce mot pour qu’il ne reste pas qu’un concept vaporeux dans un coin de tête.
La définition la plus simple serait de parler de “l’ensemble des effets positifs de vos actions sur le produit ou le business de votre entreprise”.
Ok, ça reste encore très flou.
Prenons des exemples.
- Baisser de 50% le temps d'exécution des tests d’acceptation améliore la productivité générale de l’équipe
- Contribuer à améliorer la conversion du funnel d’inscription de votre produit par 10% augmente les résultats financiers de votre entreprise
- Animer régulièrement des “talks” internes permet d’améliorer les connaissances de l’équipe
- Proposer une solution technique pouvant résoudre des soucis de performances de l’application et ainsi augmenter les scores PageSpeed au-dessus de 95, et par extension diminuer le taux de rebond de 20% sur les pages d’un site d’e-commerce améliore le revenu
- Avoir facilité et/ou piloté un projet technique complexe multi équipes pour que celui-ci… juste aboutisse
- Trouver une solution technologique pour débloquer une situation business
TIP
Parfois il n’est pas possible de chiffrer l’impact, mais vous remarquerez que j’ai très souvent essayé de le faire. Sans chiffres, il est très difficile d’être objectif sur l’impact généré. J’en reparle dans un chapitre consacré à l’importance de la mesure.
Je prête attention à ce type de détails quand je regarde un CV, car je trouve assez intéressant la façon dont une personne présente ses anciennes réalisations.
Certains vont écrire ça :
- Encadrement d'une équipe de 10 personnes.
- Responsable technique sur plusieurs nouvelles fonctionnalités : prise de décision sur le choix des implémentations techniques,
- échanges avec les prestataires externes
- mise en place de KPI et de reporting
- Élaboration et suivi de la feuille de route en fonction des besoins de l'entreprise
- Migration de l'ancienne architecture vers une nouvelle décidée en réunion d'architecture
- Rédaction d'épopées et d'histoires d'utilisateurs pour alimenter le backlog Kanban
Et d’autres vont écrire ça
- Amélioration du NPS de l'application mobile B2B (de -30 à +7) et réduction du taux de "no show" des réservations en ligne (-30%).
- Contribution à la croissance de 0€ à 10M+€ de GMV
- Création de l'activité de formation au sein de l'entreprise qui génère maintenant 10% du chiffre d'affaires.
Si le contexte de l’entreprise ne permet pas toujours d’avoir une vision claire sur son impact, ça n’en reste pas moins significatif quand une personne arrive à l’afficher de cette façon.
C’est ce qu’on devrait tous rechercher in fine. Quel est l’impact que je produis ? Et pas uniquement quelle a été ma fonction dans l’entreprise. A l’inverse, le fait d’avoir porté tel ou tel titre auparavant n’a pas forcément autant de valeur de mon point de vue.
Des impacts différents par archétypes
L’impact qu’on peut avoir en tant que senior ne revêt pas la même forme pour tout le monde. Certains seront capables de résoudre des problèmes techniques complexes, d’autres vont avoir des facilités à coordonner des initiatives larges, d’autres encore auront un impact très positif sur les méthodes et outils.
Il est usuel de parler de types de sénior, d’archétypes. J’aime bien me référer au site staffeng.com qui liste 4 types d’archétypes : le tech lead, l’architecte, le solver, le right hand. A ces 4 là je rajouterai : l’explorateur et le product engineer.
Bien évidemment, ces archétypes sont des visions exagérées de la réalité et un individu peut avoir des caractéristiques de plusieurs archétypes.
Je vous propose de voir des exemples d’impact que peut apporter chacun de ces archétypes.
Pour les 4 premiers, je vous invite à vous référer au site staffeng.com pour plus de détails.
Tech Lead
Le tech lead se caractérise par ses qualités d’organisation et de coordination. C’est une personne qui sait prendre du recul et trouver des solutions pour amener des sujets complexes au bout.
Exemple :
Nicolas Payot - Frontend Guild lead at Malt
Date : 2022
Topic : Coordination de la migration Vue2 vers Vue3 sur une équipe de 100 personnes
En 2022, Malt utilisait plusieurs technologies côté frontend, dont Vue.js en version 2.
Nicolas est lead de la guilde Front. Une guilde est une communauté de pratique et le lead a le rôle d’animer cette communauté afin de faire émerger les bonnes pratiques et une vision technologique commune.
A l’été 2022, Nicolas a animé une discussion autour de la fin de support de Vue 2, prévu fin 2023 et de la nécessité d’anticiper cela.
Parmi les tâches importantes représentatives d’un tech lead, des présentations ont été faites et des prototypes ont été réalisés pour répertorier les changements. Nicolas a également coordonné tous les travaux sur les librairies transverses pour assurer leur compatibilité entre Vue2 et Vue3 afin d’assurer une transition la plus simple possible une fois démarré dans une équipe.
La taille de la codebase représentait également une difficulté importante. Le chantier concernait 80k lignes de code, sur 11 applications. C’était exclu de le réaliser de façon centralisée. Nicolas a donc dû travailler avec les Tribes Director (lead PM) pour convaincre de l’enjeu et permettre de prioriser ce travail dans les roadmaps produit.
Grâce à ce travail important de coordination à l’échelle d’une équipe de 100 personnes, la migration Vue3 s’est déroulée sur 4 mois avec une perturbation limitée du travail sur les équipes.
L’Architecte
Les architectes sont à l’aise avec le design de solutions. Ils et elles travaillent sur des sujets longs termes, sur la scalabilité et tout autre sujet nécessitant de prendre du recul.
Exemple :
Nicolas Grisey Demengel - Staff Engineer at Malt
Date : 2020
Topic : Standardiser les appels aux services externes
En 2020, Nicolas a fait un constat sur nos appels de web services dont le traitement posait de nombreux problèmes :
- la reprise sur erreurs. Que faire en cas d’échec de l’appel ?
- comment anticiper le rate limiting à l’échelle d’un système distribué
- la déduplication de messages
- comment garantir que l’ordre a été pris en charge malgré l’asynchronisme ou la lenteur du service final ?
- peut-on grouper les appels pour optimiser ?
- comment gérer une erreur persistante après retry sans bloquer un utilisateur ?
Ce travail a abouti sur un système de queue de commande qui est désormais un standard chez Malt.
Ce travail a drastiquement amélioré la robustesse de nos systèmes et surtout standardisé les solutions qui étaient parfois mises en place d’ici et là.
C’est aujourd’hui 40k appels par jour qui passent par cette command queue pour environ 15 services externes. Le taux d’erreur moyen est de 0.2%, mais seulement 0.02% qui doit être regardé à la main, le reste étant géré par les mécanismes de retry de la queue de commande. La command queue a permis de réduire à 0 les cas d’erreurs lié aux rates limiting, qui finissaient en général en quarantaine pour un traitement manuel.
Si vous souhaitez plus de détails, ce travail a été décrit sur le blog de Malt.
Le Solver
Cet archétype regroupe les personnes capables de résoudre des problèmes complexes. L’architecte travaille sur le long terme en avance de phase. Le solver travaille sur un sujet existant et souvent urgent. S’il y a un problème complexe qui nécessite beaucoup de méthodologie et d’expertise technique, on fait fréquemment appel à eux.
Exemples :
Guillaume Darmont - Principal Engineer chez Enedis
Date : 2014
Topic : Système de sérialisation longue durée d’informations métier
En 2014, un projet utilisait beaucoup de communication interservices avec des échanges d’informations en Json. Ce Json représentait des entités métiers et changeait régulièrement en fonction des évolutions du code. Chaque changement impliquait de supprimer les anciennes données stockées dans le précédent schéma, car celles-ci n’étaient plus compatibles avec le nouveau schéma. Il était nécessaire de résoudre ce problème avant la mise en production 2 mois plus tard.
Guillaume est intervenu pour trouver une méthode de sérialisation longue durée et rétrocompatible. Les données devaient pouvoir être stockées dans différents types de systèmes : base de données colonne ou relationnelle, cache mémoire distribué, broker de message, etc. La base de code existante et le délai de quelques semaines rendait impossible une réécriture du modèle métier Java existant à partir d’un schéma type Avro ou Protobuf.
Les objectifs du système de sérialisation étaient :
- De s’intégrer de manière transparente dans la base de code existante, sans modification du modèle métier, afin de ne pas ralentir les développements.
- D’avoir une compatibilité ascendante et descendante, nécessaire pour les montées de version applicative et le stockage longue durée.
Guillaume a travaillé pour mettre en place :
- La définition d’un protocole binaire de stockage
- Le développement des composants de transformation d’une version à l’autre du modèle
- Le développement d’un serveur et de son client, avec un protocole de requêtes/réponses dédié
- Le développement de différents composants pour intégrer ce système au sein des applications et briques de stockage existantes.
Son action a permis au projet de sortir dans les délais et surtout il est toujours utilisé 8 ans après pour ses fonctionnalités et sa fiabilité.
Le Right Hand
Ce rôle n’est pas le plus simple à appréhender, car il est très polyvalent. Il n’apparaît qu’à partir d’une certaine taille d’équipe pour jouer les électrons libres et se faire le représentant de la vision technologique ou organisationnelle. Ce type de personne fait parfois partie de ce qu’on appelle le CTO office. C’est souvent un(e) Staff ou Principal Engineer.
Exemple :
Nicolas Martignoles - Principal Engineer chez Doctolib
Date : 2022
Topic : Stratégie technologique chez Doctolib
Doctolib en 2022, c'est 77 équipes Produit et l’alignement sur une même vision technologique est un enjeu crucial.
Le rôle de Nicolas chez Doctolib comprend une grande part de discussion avec les équipes. Lui-même travaille comme Principal engineer avec d’une part des sujets très identifiés : migration vers Datadog, travail de performance sur Redis etc… mais aussi en électron libre avec les équipes. Je vais citer ici directement Nicolas :
... Je garde du temps pour parler aux personnes "en vrai". Mon agenda est parfois bloqué avec un créneau de 2h, que je consacre à aller physiquement discuter et échanger avec les développeurs. Mon rôle ne fonctionne pas sur l'autorité. Les gens doivent avoir envie de venir me voir et doivent savoir ce que je peux faire (ou non). Cela passe par de l'influence, que l'on travaille en prenant la parole, en écrivant et en allant surtout discuter avec les gens. Il n'y a pas de cellule de "sachant" chez Doctolib qui attendraient sagement du travail. C'est à nous d'aller chercher les sujets, et d'impacter l'ensemble de Doctolib.
Ce qui est intéressant et représentatif de l’impact d’un “Right Hand” c’est tout ce travail important d’immersion dans les équipes, de collecte des problèmes à résoudre, d’influence sur les bonnes pratiques qui permet ensuite de concrétiser un alignement technologique sur des dizaines d’équipes.
L’explorateur
Cet archétype est très rarement listé et/ou parfois confondu avec le Product Engineer. Charity Majors est la seule qui en fait un peu mention
some are good at bootstrapping new projects
Je vais donc le détailler un peu plus.
L’explorateur est celui ou celle qui va explorer des pistes non balisées. C’est typiquement la personne idéale en début de startup, mais pas seulement. Cette personne, comme le Product Engineer, se caractérise par sa capacité à prototyper rapidement, tester, jeter. On rencontrera cependant le ou la Product Engineer plus fréquemment dans une structure déjà établie et notamment en partenariat avec un(e) Product Manager. L’explorateur joue plus le rôle d’électron libre. Il ou elle peut regarder dans des directions non envisagées à l’origine. C’est aussi ce que j’appellerai un(e) “entrepreneur”. L’explorateur n’est souvent pas un(e) “finisseur”. Il ou elle change régulièrement de sujet. Ce sont des personnes qui peuvent facilement disrupter un sujet, mais ce sont aussi des impatients qui ne voudront pas passer du temps à accompagner le changement généré. Cette versatilité peut parfois causer quelques frustrations ensuite aux personnes qui vont finaliser le travail démarré.
Exemple :
Jean-Baptiste Lemée - Co-CTO chez Malt
Date : 2016
Topic : Le Punchout
En 2016, Malt travaillait déjà avec de grands groupes et la plupart utilisent des ERP, notamment pour les achats.
Certains souhaitaient utiliser leur système d’achat pour y ajouter la possibilité de payer des prestations freelance sur Malt. En 2016, c'était un monde totalement inconnu pour nous.
C’est Jean-Baptiste qui travailla seul sur le sujet pour comprendre ce qui se cachait techniquement dernière les ERP et défrichera le protocole CXML qui définit un protocole d’échange, en théorie compatible avec tous les ERP. Il développera un prototype rapidement pour intégrer tout un flux d’achat et de contractualisation d’un ERP en punchout sur Malt et ce sera mis en production avec un client dans la foulée.
Ce travail d’explorateur, même s’il a dû être refait en grande partie, nous a fait acquérir une énorme connaissance sur le sujet et a démontré que cela pouvait marcher avec un client.
Aujourd’hui, nous continuons à étendre l’usage du Punchout parmi les grands groupes. Ce qui nous a procuré un véritable avantage concurrentiel.
Le Product Engineer
Cet archétype n’est pas détaillé sur le site staffeng.com donc pour celui-ci je vais vous renvoyer sur Pragmatic Engineer pour une explication détaillée.
C’est le ou la partenaire idéal du Product Manager. C’est l’un des archétypes qui sait le mieux faire la jonction entre la technique et le business de son entreprise.
Le Product Engineer partage plusieurs caractéristiques avec l’explorateur, comme sa capacité à savoir identifier le Minimum Viable Product pour avancer rapidement
Mais à l’inverse de l’explorateur, c’est une personne capable de s’attacher aux détails et passer du temps à peaufiner un produit avec le Product Manager pour résoudre toutes les opportunités ouvertes tant que le bénéfice attendu n’est pas atteint.
Exemple :
Sahbi Ktifa - Staff Engineer chez Malt
Date : 2022
Topic : Développement de l’usage de l’avance de paiement
Malt propose une fonctionnalité d’avance de paiement sur les missions. Concrètement, un freelance utilise Malt pour contractualiser sur la plateforme et sera payé à j+5 par Malt qui prend en charge le paiement dès la fin de mission, en s’appuyant sur un partenaire.
Cette fonctionnalité était auparavant utilisée uniquement pour des clients de grande taille, car le partenaire ne permettait pas de travailler avec tous les types d’entreprises.
La fonctionnalité avait plusieurs défauts. Elle avait été développée plusieurs années auparavant et ne proposait aucune abstraction. De plus le workflow utilisateur n’était pas très fluide, nécessitant l’envoi de documents pour la vérification d’identité, la directive KYC (know your customer).
Fin 2022, la fonctionnalité permettait de traiter 35% des flux financiers malgré ces défauts.
Sahbi Ktifa est tech lead dans l’équipe qui s’occupe notamment du paiement chez Malt. En 2022, la squad de Sahbi a dû gérer plusieurs changements.
Tout d’abord l’avance de paiement devait fonctionner pour de nouveaux pays, ce qui n’était pas possible avec le partenaire historique. Ensuite sur les nouveaux marchés, il fallait être en mesure de travailler avec des entreprises de plus petite taille.
En tant que tech lead de son équipe, Sahbi a travaillé sur la modélisation des flux d’avance de paiement pour créer un scénario idéal, avec des points d’extension de façon à pouvoir ajouter autant de nouveaux partenaires de paiement que nécessaire et en supprimant toutes les frictions de l’ancien workflow.
Le travail réalisé a permis de monter à 70% des flux financiers bénéficiant de l’affacturage, sur tous les pays ouverts. L’intégration d’un nouveau partenaire d’avance de paiement ne nécessite plus que 2/3 semaines.
Fin 2022, le partenaire historique a malheureusement fermé. C’est aussi grâce au travail effectué que cet incident s’est résolu de façon transparente.
Un impact grandissant avec l’expérience
Vous aurez peut-être noté dans mes exemples qu’ils n’ont pas tous la même portée.
Prenons un exemple célèbre : Kent Beck. Parmi ces réalisations, il est notamment à l’origine de tous les frameworks de tests XUnit. C’est aussi l’auteur de la méthode Extreme Programming
Effectivement, on peut dire que Kent Beck a eu un impact important sur l’industrie.
Mais est-ce nécessaire pour chacun d’avoir un impact à ce niveau ?
Bien sûr que non. L’impact grandit avec la séniorité.
Durant notre carrière, on peut avoir successivement des impacts sur soi, son équipe, son département, son entreprise et son industrie.
Sans chercher à être exhaustif, prenons un exemple précis pour illustrer ces niveaux d’impacts.
Un “chapter” ou une “guilde” dans le diagramme plus haut, c'est une communauté de pratique. C’est, par exemple, l’ensemble des personnes intéressées par le développement frontend, ou la sécurité.
- Participer à la guilde pour en apprendre les bonnes pratiques, c’est un impact individuel.
- Collecter les informations et faire en sorte que ces bonnes pratiques soient appliquées dans votre squad, c’est un impact d’équipe.
- Contribuer activement à la guilde avec des Pull Requests, une participation aux discussions de design créé un impact au sein de cette guilde
- Initier une guilde, rassembler les personnes autour d’un thème et assurer l’animation constitue un impact au niveau d’un département produit.
- Apporter des initiatives de guilde qui permettent des gains significatifs de productivité, ou des gains business (par exemple améliorer les pratiques autour de la web performance et faire gagner en SEO) a une portée Entreprise
- Généraliser le travail effectué pour en faire une bonne pratique en dehors de l’entreprise constitue un impact sur l’industrie (Par exemple Kent Beck avec le framework xUnit)
C’est un exemple filé à travers le prisme d’une guilde. Mais comme vous l’avez vu plus haut, il y a de multiples façons de créer de l’impact, selon vos archétypes.
Career path et impact
Il est usuel, en tout cas c’est ce qu’on fait chez Malt d’aligner niveau d’impact et career path :
- Junior - Impact individuel
- Confirmé - Impact d’équipe
- Senior - Impact transverse (entre guilde et équipe produit)
- Staff - Impact transverse (entre équipe produit et entreprise)
- Principal - Impact transverse sur l’entreprise
- Distinguished/Fellow - Impact sur l’industrie
Il faut bien comprendre malgré tout que c’est très contextuel. Etre Principal Engineer ou CTO dans une entreprise de 20 personnes ne se transpose pas dans une entreprise de 10 000.
Il faut justement le comprendre via cette notion d’impact.
Mais je ne m’attarde pas là-dessus pour le moment, la notion de Career path n’est pas le sujet de ce chapitre.
Et après ?
Maintenant que nous avons pris le temps de parler d’impact, voyons comment à l’échelle individuelle, on peut le travailler. Notamment je vous propose de parler dans les prochains chapitres :
- de l’importance de la mesure
- des compétences de priorisation
- d’accepter l’ennui
- de créer son réseau
- de marketing tech
Questions pour vous
Quel a été votre impact dans les 6 derniers mois ?
Pourriez vous le mesurer ? L’exprimer en valeur business ?
Quels sont les archétypes qui vous caractérisent le plus ?
Ressources
- Staffeng.com : les différents archetypes de staff
- Quel archétype êtes-vous ?
- Pragmatic Engineer: Product Engineer
- Staff Engineer role at small companies
TIP
Ce billet de blog fait partie du livre Impactful Software Engineering.
N'hésitez pas à lire les autres chapitres.
