Engineering manager : donner des objectifs et de la vision

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 Mesure¹ : 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.

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.