Au fil des années chez Malt j'ai appris une leçon importante sur le temps et la nécessité d'accepter “l'ennui”.

Avec l'expansion de l'entreprise, j'ai eu de nombreuses fois à redéfinir mon activité. J'ai usé et usé de l'expression “savoir se virer moi-même” pour régulièrement embaucher des personnes meilleures que moi sur telle ou telle activité.
Lorsqu'on se “vire” d'un poste, on se crée automatiquement du temps libre, avant de retrouver un équilibre. Mais j'ai appris au fil des années à apprécier ce temps libre forcé, et à développer la conviction qu'il est même nécessaire pour continuer à créer de l'impact.

Un métier créatif

L'ingénierie logicielle est un métier créatif. La créativité ne se décrète pas, mais surtout elle ne risque pas d'arriver au moment où l'esprit est très occupé à faire autre chose.
Vous l'avez peut être noté, cette créativité arrive au moment où on pose les crayons, parfois dans la douche, devant une tasse de thé ou que sais-je encore.

J'aime beaucoup la citation suivante :

Being busy is a form of laziness
Tim Ferris

Remplir son emploi du temps nous évite d'avoir à réfléchir. Or, c'est l'un de nos rôles les plus importants. Sans réflexion et recul, on finit par limiter son impact.

Un impact non linéaire dans le temps

On pourrait penser que notre impact croît linéairement avec le temps. Au début on apprend le métier, le contexte de l'entreprise et notre autonomie est faible. Et puis avec le temps, on gagne en connaissance, on devient de plus en plus rapide pendant le développement. On ne sollicite plus autant d'aide, et c'est même l'inverse qui se produit. On a contribué efficacement à plusieurs améliorations du produit et tout cela s'empile pour continuer à créer de l'impact.

Mais dans la pratique, à un moment, la courbe peut aussi ressembler à ça :

Eh oui, maintenant les améliorations sont en production, il y a du support à réaliser. On se retrouve à être beaucoup sollicité pour comprendre comment ça marche, former les nouveaux arrivants etc… On manque de temps.

Cette phase est difficile. Certains s'en accommodent et trouvent un certain confort à être devenu “l'expert(e)” de leur produit. L'emploi du temps se remplit tout seul, le cerveau est constamment sollicité.

Mais dans les faits, l'impact diminue. C'est le fameux moment dans une entreprise où on a l'impression de ne plus apprendre ou de ne plus autant apporter. On a la sensation de rester bloqué sur des impacts passés. Pire, la charge de travail nécessaire pour être “l'expert(e)” du produit devient de plus en plus forte. Vous avez remarqué ? Les meetings s'accumulent, mais ne diminuent jamais en nombre ? Et cette débauche d'énergie peut mener au Burnout.

Pour quelques-uns, la conclusion sera d'aller voir ce qui se passe ailleurs pour tenter de reproduire l'impact des débuts, tout en revenant sur un rythme soutenable.

Déprimant ?

Il existe une alternative quand on finit par accepter de poser les crayons. Notre contribution et notre impact peuvent fonctionner en dents de scie. Créer de l'impact nécessite des temps morts.

Réactivité versus proactivité

C'est très bien d'être réactif, c'est une grande qualité d'être capable de résoudre un problème lorsqu'il arrive. Un environnement réactif, c'est celui que je décris plus haut. Notre agenda personnel se remplit tout seul, sans contrôle de notre part. C'est une zone de confort, mais si on veut apporter davantage, il faut reprendre le contrôle, poser les crayons, élaguer son agenda et sortir de cette zone.

À partir de Senior, on attend de vous de travailler sur les bons problèmes à résoudre. On attend de l'anticipation. On attend proactivité et clarté. La clarté étant d'avoir su isoler les bons sujets à tacler parmi la multitude d'activités d'une équipe produit.

Pour cela je vous propose de reprendre la démarche que nous avons vu ensemble dans le chapitre “Tout mesurer” : LIME (pour Listen, Ideas, Measure, Evolve)

La première étape, c'est “Listen”, et pour ça il faut du temps.

De l'importance de créer du temps

Pour les Seniors IC, pour maximiser votre impact, il faut trouver des solutions pour créer du temps libre.

Par temps libre, j'entends des phases ouvertes, dédiées à l'exploration de technologie, aux échanges avec ces pairs, y compris en dehors de l'entreprise, aux échanges inter-fonctions au sein de l'entreprise, aux phases de collecte et d'analyse sur votre produit, à la rédaction de documents.

Ce travail d'écoute est nécessaire pour déterminer les problèmes sur lesquels il faut travailler, au niveau produit comme au niveau technologique. Ne pas le faire c'est ne pas anticiper, c'est s'exposer à des baisses importantes de productivité liées à une dette technique et/ou fonctionnelle qui explose. C'est aussi parfois le fait de rater des opportunités business via l'usage d'une technologie.

Chaque organisation produit performante a su créer ces espaces, popularisé notamment par Google avec la fameuse règle des 20% d'innovation (même s'ils ne l'appliquent peut-être plus exactement comme cela).

Chez Malt cela a donné des innovations comme :

• les systèmes de push notifs sur mobile
• une implémentation open source pour gérer le Critical CSS
• les groupes de freelance
• Malt+, le système de recommandation de missions pour les freelances
• le punchout pour connecter Malt aux ERP

Je vous propose d'en découvrir un exemple en détail.

Créer du temps dans une équipe Scrum

Scrum étant très utilisé dans l'industrie, il me semble intéressant d'ouvrir une parenthèse ici. Il y a un mot dans le vocabulaire Scrum qui me gêne assez souvent, c'est le “sprint”. Il donne l'impression qu'on peut constamment enchaîner des itérations de développement sans pause. Scrum a de toute façon de nombreux écueils, comme le rôle du product owner, l'importance des stakeholders en tant que proxy des utilisateurs et sur la manière d'organiser la discovery. Le sprint est un peu le reflet de ces défauts. Le sprint, dans la majorité des cas, ne permet pas de prendre le temps de l'observation.
Je vous propose plusieurs options pour créer cet espace.

Si vous faites du Scrum, essayez de convaincre de l'intérêt des périodes de “cool-down” tous les 2 ou 3 sprints. C'est une période d'observation qui permet de préparer le travail des prochains sprints, prendre du temps pour analyser les données ou le support, passer du vernis sur les endroits délaissés pendant les sprints, faire de la discovery technique et j'en passe. Vous retrouvez cette période dans la méthode “Shape Up” de Basecamp.

À défaut, si ce changement rencontre trop de résistance, faites en sorte d'augmenter le buffer de “Discovery” au sein des sprints. Autrement dit, réduisez volontairement l'engagement sur les sprints. C'est contre intuitif, mais je vous renvoie aux bénéfices attendus listés plus haut.

Alterner immersion et récupération

En tant que Senior IC vous pouvez aussi être dans des équipes transverses, parfois appelées équipes Plateformes. Ces équipes ont souvent comme mission d'améliorer l'expérience de développement (DX pour Developer experience). L'une des difficultés de ces équipes c'est d'être trop éloigné du travail effectué dans les squads métiers.

Ici je suggère d'alterner les phases d'immersion et de récupération.
Immersion dans les équipes produit pour s'imprégner des difficultés du quotidien, récupération dans l'équipe plateforme pour prendre du recul et décider des actions à mener.

C'est de cette façon que nous avons décidé de mener un chantier de transformation de notre stack Front chez Malt.
En 2022, les immersions dans les équipes nous ont permis de mieux saisir la difficulté au quotidien liée à nos choix technologiques sur les 10 années précédentes. Et c'est sur une phase de récupération que nous avons décidé de lancer ce grand chantier de simplification.

Accepter l'ennui

Dans le passé j'ai commis une erreur que je souhaite partager ici. La construction d'un produit est un processus itératif, constitué de deux étapes que l'on appelle souvent : Discovery et Delivery. Ces noms peuvent varier selon les entreprises mais grosso modo cela correspond à la découverte des problèmes à résoudre et l'identification des solutions, puis à la réalisation/industrialisation de ces solutions.

Il y a une certaine tension sur la gestion du temps entre ces deux phases, car on peut avoir l'impression que l'un des premiers objectifs du product trio est de ne jamais avoir un backlog vide, et “d'alimenter l'équipe de développement”.

C'est une erreur en réalité. Il n'y a pas de souci à ce que l'équipe de développement n'ait pas de feature à produire. Et le premier et seul objectif du Product Trio est de créer un produit de qualité, pour ces utilisateurs et qui génèrent du revenu pour son entreprise, pas d'occuper des équipes.

L'équipe de développement devrait de toute façon participer à la Discovery, ce qui résoudrait une partie du problème. Quand bien même tout le monde n'y participerait pas, c'est le moment de prendre du temps pour faire de l'exploration technique, résoudre de la dette, améliorer les outils de développement et de nombreuses autres activités utiles.

Le pire choix à faire, serait de créer du travail “factice” pour occuper l'équipe. Par factice j'entends des fonctionnalités pas vraiment attendues. Ce sont des fonctionnalités qu'on ressort du fond du backlog, pas totalement inutiles, mais dont le gain reste incertain. C'est un perte de focus de la part des PM/UX et Tech Lead qui vont devoir définir ces tâches. C'est davantage de complexité dans le produit qui produira à terme sa propre dette technique et fonctionnelle. On perd du temps et on se met dans la bonne position pour en perdre dans le futur.

Il faut lutter contre ce sentiment de culpabilité de ne pas occuper l'équipe.
Ou de soi-même ne pas être occupé à 100%.

Questions

• Votre équipe est-elle plutôt réactive ou proactive selon vous ?
• A quel point êtes-vous occupé ? Combien de temps pourriez-vous libérer dans votre agenda ?
• Est-ce qu'il n'y pas des meetings dans votre agenda auquel cela n'aurait aucun impact de ne pas y aller ?
• Combien d'entre eux pourraient être remplacés par de communication asynchrone ?
• Dans les 6 derniers mois, combien de fois avez-vous eu des moments de calme qui vous ont permis ensuite de débloquer des situations critiques ?

Ressources

• Méthode ShapeUp
• Implémentation Daily Motion inspiré par ShapeUp
• Projet de transformation de la Stack Frontend chez Malt
• Projet BIMI chez Malt
• Lettre des fondateurs de Google de 2004