Cet article a été publié initialement sur mon blog.
C'est le troisième article de ma série sur ce que le rôle d'engineering
manager m'a appris. Comme pour les épisodes précédents, ce qui suit n'est
ni une méthode ni une vérité générale : c'est un retour d'expérience
personnel, structuré autour des citations et des principes que des
personnes qui ont compté dans mon parcours m'ont transmis, et de ce qu'ils
m'apportent au quotidien.
Le premier épisode portait sur le rôle et la posture d'engineering
manager, le deuxième sur le
1:1 et le suivi individuel.
Vous pouvez retrouver tous les articles de la série sur la page du tag
engineering-management.
Ce billet-ci se concentre sur les objectifs et la vision : comment se
donner des horizons de travail, comment les faire vivre dans le temps, et
comment les rendre compréhensibles par toute l'équipe.
Se donner des horizons
« Un auteur sans deadline, c'est juste un mec au chômage. » (Kyan
Khojandi, entendu dans une interview)
Il existe, pour moi, trois types de projets : ceux drivés par une date,
ceux drivés par un résultat attendu, et ceux drivés par les deux à la fois.
Ce troisième cas est de loin le plus inconfortable : si vous savez
exactement ce que vous voulez livrer, il devient très compliqué d'imposer
en plus une date fixe, sans risquer soit le retard, soit un scope amputé
pour tenir les délais.
La question à garder en tête en permanence, c'est : est-ce que l'important
c'est que ça sorte à telle date, quitte à ce que le scope bouge ? Ou est-ce
que l'important c'est ce qui doit sortir, quitte à ce que la date bouge ?
Un projet sans réponse claire à cette question navigue à vue.
Se donner des dates et des jalons, ce n'est pas de la rigidité gratuite :
c'est se forcer à se demander régulièrement « comment je peux rapidement
délivrer un truc qui marche, que je peux montrer ? ». On touche là au cœur
de l'agilité et de la création de valeur. Et l'inverse est tout aussi vrai
: si vous n'avez pas d'ambition de date de fin pour un projet, ne soyez pas
surpris s'il ne finit jamais. C'est la loi de Parkinson : un travail
s'étend jusqu'à occuper tout le temps disponible pour son achèvement.
Pour fixer ces horizons, je recommande de s'aligner sur le calendrier de
l'entreprise. Si elle revoit ses objectifs tous les six mois, construire
des projets qui tiennent sur six mois est une bonne idée ; pareil pour
trois mois, ou pour quatre semaines. Appelons ça, comme en musique, la
Mesure1 : l'unité de temps qui rythme le travail de l'équipe. La
question qui en découle, à se poser à chaque nouvelle Mesure : « qu'est-ce
qu'on peut faire de mieux pour répondre à ce problème en X semaines ? »
La macula : net de près, flou de loin
« Construire une roadmap sur six mois ou un an, ce n'est pas savoir
exactement ce qu'on fera dans six mois ou un an, c'est définir ce qu'on
fait demain et dans quelle direction on va. » (plusieurs coachs Agile
avec qui j'ai travaillé)
C'est l'image que je préfère pour parler de roadmap : celle de la macula,
cette petite zone au centre de la rétine qui capte le détail net, entourée
d'une vision périphérique bien plus floue. D'abord avoir une vision claire
du mois prochain, avant d'essayer de savoir précisément ce qu'on fera dans
six mois. Se laisser de la place sur le moyen et le long terme, plutôt
que de prétendre à une précision qu'on n'a pas.
Comme la vision humaine : net au centre, de plus en plus flou vers la périphérie. La roadmap fonctionne pareil.
Expliquer ce qu'on va faire est important, mais exprimer pourquoi on va le
faire, en quoi c'est nécessaire, est un besoin tout aussi fort — j'y
reviens dans la section sur la répétition, un peu plus loin.
Il y a un moment où cette netteté se rejoue : la bascule d'une Mesure à la
suivante. C'est souvent là qu'il faut consacrer plus de temps que
d'habitude, en deux temps. D'abord faire les comptes de la Mesure qui se
termine : est-ce que les objectifs sont atteints, est-ce qu'on a fini ce
qu'on voulait faire. Ensuite regarder ce qu'on veut faire dans la
suivante, et le valider avec l'équipe. On ne bascule pas une Mesure en
mode automatique ; on la clôt, puis on en ouvre une nouvelle.
Mesurer le lead time
« Ça fait quatre ans qu'on parle de ce projet, donc on va pas parler de
lead time. » (un ancien collègue, anonyme — la formule fait toujours
mouche)
Le lead time, c'est le temps écoulé entre le moment où un sujet est
identifié et le moment où il est réellement livré. C'est une mesure
implacable : elle ne s'intéresse pas à combien de temps vous avez
« vraiment » travaillé dessus, seulement à combien de temps il a fallu à
l'idée pour devenir réalité.
Je tiens, de mon côté, une petite liste personnelle où je note et je
mesure le lead time des projets de mon équipe. Ce n'est pas un outil de
flicage : c'est un instrument de calibrage. Mon objectif en tant
qu'engineering manager, c'est que la médiane des lead time de mon équipe
reste inférieure à la Mesure de temps de l'entreprise vue plus haut. Si
l'entreprise raisonne à six mois et que la médiane de mes projets dépasse
six mois, quelque chose ne va pas dans la façon dont je les découpe ou dont
je les priorise — et la citation ci-dessus finit tôt ou tard par devenir
vraie dans ma propre équipe.
Répéter et multiplier les formats
« Monsieur, qu'est-ce qu'il faut faire déjà ? » (mes étudiants, à
l'époque où je donnais des cours à la fac)
Donner des cours m'a appris quelque chose que j'ai réemployé sans arrêt en
tant que manager : pour qu'une information soit transmise et vraiment
comprise, il faut la répéter, et la répéter sous des formats
différents. Une seule annonce, un seul support, ne suffit jamais — même
quand on a l'impression d'avoir été parfaitement clair la première fois.
Concrètement, pour la vision et les objectifs, je fais vivre la même
information sous plusieurs formes :
- une réunion en fin de Mesure pour présenter et discuter la suivante ;
- en 1:1, une question que je pose régulièrement à chacun : « est-ce que tu vois où on va ? est-ce qu'il y a un projet, chez nous, qui te semble pas clair ? » ;
- la roadmap elle-même, partagée et mise à jour régulièrement, au format image — un visuel qu'on peut regarder d'un coup d'œil vaut mieux qu'un document qu'il faut rouvrir pour se souvenir où on en est.
Petite parenthèse : c'est en cherchant justement ce format visuel, simple
à tenir à jour, que j'ai fini par construire mon propre petit outil de
roadmap, disponible ici : roadmap.slashgear.dev.
Vous remarquerez que cet exemple applique lui-même le principe de la
macula vu plus haut : beaucoup de détail confirmé sur le mois en cours,
un peu moins sur le trimestre suivant, et un unique bandeau flou « scope
TBD » pour le second semestre.
SMART, et le piège du silo
« Un objectif malin, c'est SMART. »
(Caroline Le Lay)
Un petit rappel s'impose : un objectif SMART est Spécifique,
Mesurable, Atteignable, Réaliste (ou pertinent) et Temporel.
« Améliorer la qualité » n'est pas un objectif SMART ; « réduire de 30 % le
nombre de tickets de support ouverts par mois d'ici la fin de la Mesure »
en est un. La différence, c'est qu'on sait, sans ambiguïté possible, quand
il est atteint.
Un exemple vécu : quelqu'un dans l'équipe se plaint de porter trop de
tickets de bug tout seul, et aimerait que ça se répartisse mieux.
L'équipe se fixe alors comme objectif de « mieux répartir les tickets de
bug ». Pas très SMART : comment sait-on, concrètement, qu'on l'a atteint ?
Une première piste pour le rendre SMART : que chacun traite au moins un
ticket de bug par Mesure. Juste un ? Ça paraît dérisoire, dit comme ça.
Mais si la situation de départ, c'est zéro ticket de bug traité par la
moitié de l'équipe, passer de zéro à un pour tout le monde, franchement,
ça paraît déjà pas mal, non ? C'est un objectif atteignable, sur lequel
personne ne peut dire « ça ne me concerne pas » — et rien n'empêche de
relever la barre à la Mesure suivante une fois que ce premier palier
est acquis.
Mais définir un objectif SMART ne dit rien de qui le porte, et c'est là que
se cache le vrai piège. Je préfère, autant que possible, donner des
objectifs à l'équipe plutôt que des objectifs individuels. Un objectif
individuel a tendance à siloter le travail : chacun défend son bout de
périmètre, et l'entraide en pâtit, parfois sans même qu'on s'en rende
compte. Un objectif d'équipe pousse au contraire tout le monde à avancer
ensemble, à s'entraider pour l'atteindre, plutôt qu'à optimiser
chacun dans son coin.
Concrètement, sur un même sujet, ça peut donner deux objectifs tout aussi
SMART l'un que l'autre, mais avec des effets opposés :
- À éviter — objectif individuel : « Chaque développeur ferme au moins 15 tickets de support par Mesure. » Chacun va naturellement piocher les tickets faciles pour faire son quota ; le ticket compliqué qui traîne depuis trois semaines, personne n'y touche, puisqu'il ne rapporte rien à personne en particulier.
- À privilégier — objectif d'équipe : « L'équipe réduit de 30 % le nombre de tickets de support ouverts par mois d'ici la fin de la Mesure. » Peu importe qui ferme quoi : seul le chiffre global compte, donc s'entraider sur le ticket compliqué devient rationnel plutôt que perçu comme du temps perdu.
Même chose sur un projet plus large :
- À éviter — objectif individuel : « Le lead technique livre la migration vers la nouvelle API de paiement. » Un seul point de défaillance : si cette personne part en vacances, change d'équipe ou tombe malade, le projet s'arrête net, et personne d'autre n'a le contexte pour reprendre.
- À privilégier — objectif d'équipe : « L'équipe a basculé 100 % du trafic de paiement vers la nouvelle API d'ici la fin du trimestre. » N'importe qui peut reprendre la suite, parce que le contexte est partagé dès le départ plutôt que concentré dans une seule tête.
Pas de ticket pour dans six mois
« Écrire un ticket pour un sujet potentiel à faire dans six mois, c'est
globalement toujours une mauvaise idée. »
(Emmanuel Hervé)
Le coût de maintenance d'un ticket ouvert pour dans six mois est énorme,
même à l'ère de l'IA qui promet d'en absorber une partie. On finit avec un
backlog de 600 tickets, dont certains ont deux ou trois ans, et dont plus
personne ne connaît vraiment le détail. Un backlog de 2 000 tickets
n'est pas une roadmap : c'est un cimetière d'intentions.
Si un sujet est vraiment important, il reviendra. Pas besoin de lui
réserver une place dans le backlog pour ça. Ce que je fais à la place :
noter l'idée dans une page « boîte à idées », pas dans un vrai ticket. Ça
évite le coût de maintenance, tout en gardant une trace suffisante pour la
retrouver le jour où le sujet redevient d'actualité.
Construire une roadmap, ça demande justement de s'extraire des sujets du
quotidien pour aller enquêter sur les véritables enjeux de l'entreprise.
Et côté technique, c'est aussi accepter de trancher : décider sur quoi on
choisit d'investir, et donc, implicitement, sur quoi on choisit de ne pas
investir tout de suite.
Un squelette de boîte à idées que vous pouvez copier tel quel :
# Boîte à idées
| Idée | Notée le | Contexte | Statut |
| ---- | ---------- | -------- | ----------------------------------- |
| … | AAAA-MM-JJ | … | à explorer / abandonnée / en Mesure |
Et la suite ?
Il reste d'autres aspects des objectifs et de la vision que je n'ai pas
abordés ici. Si vous voulez que je précise un point ou que j'aborde un
thème en particulier, mes réseaux sont accessibles depuis ce blog :
écrivez-moi, je serai ravi de vous lire.
Le lead time n'est qu'une métrique parmi d'autres : le prochain épisode
portera sur les métriques que je surveille en tant qu'engineering
manager, pour aller plus loin. Comme toujours, vous pouvez retrouver
l'ensemble de la série via le tag
engineering-management.
Notes
- Mesure : terme que j'emploie ici comme en musique, pour désigner l'unité de temps qui se répète et rythme le travail de l'équipe (un mois, un trimestre, six mois — selon le calendrier de l'entreprise). Une Mesure n'est pas un sprint : c'est l'horizon sur lequel se fixent les objectifs, avant de faire les comptes et d'en ouvrir une nouvelle.
Top comments (0)