Blog · Management d’ingénierie
Comment j’organise l’équipe d’ingénierie Solutions.
Dix ingénieurs, un portefeuille de plateformes qui n’ont pas le droit de tomber, et un manager bien décidé à ne pas devenir le goulot d’étranglement. Voici le modèle de fonctionnement vers lequel nous avons convergé, et le raisonnement derrière chacune de ses pièces.
- Un portefeuilleChaque plateforme appartient à un domaine.
- Responsable et suppléantLa responsabilité et la connaissance ont deux noms.
- Une vue des prioritésLes arbitrages se font au grand jour.
- Du contexte directLes ingénieurs parlent à ceux pour qui ils construisent.
- Une croissance déléguéeLa responsabilité grandit avec le soutien.
Partir du portefeuille, pas de l’organigramme#
L’équipe Solutions ne fait pas tourner un produit. Elle fait tourner un portefeuille : des plateformes établies avec des années d’histoire, des services plus récents qui cherchent encore leur forme, et tout ce qu’il y a entre les deux. La façon naïve de s’organiser, c’est de répartir les gens par projet et de croiser les doigts. Le problème, c’est que les projets se terminent ; les plateformes, non. Il faut que quelqu’un se soucie de chaque système le jour où rien n’est prévu pour lui.
L’unité d’organisation n’est donc pas le projet, c’est le domaine produit. Chaque plateforme du portefeuille appartient à un domaine, et chaque ingénieur sait quelles parties de la carte sont les siennes.
Un responsable nommé, un suppléant nommé#
La responsabilité ne fonctionne que lorsqu’elle est explicite. « L’équipe en est responsable » sonne généreux et signifie que personne ne l’est. Pour chaque domaine produit, il y a un ingénieur dont le nom est dessus, et un second capable de prendre le relais demain matin.
Le responsable est l’interlocuteur des parties prenantes, celui qui sait pourquoi le système est ce qu’il est, et le premier appelé quand il se comporte mal. Le suppléant n’est pas une roue de secours : le rôle force la connaissance à circuler. Les revues passent par défaut entre responsable et suppléant, et le suppléant prend la main assez souvent pour que l’arrangement soit réel plutôt que cérémoniel. Les vacances cessent d’être des événements à risque. Les départs cessent d’être des crises.
Une seule liste de priorités, arbitrée au grand jour#
Les fonctionnalités de la roadmap, la modernisation, la dette technique, les exigences de sécurité et le support de production se disputent les mêmes dix personnes. La dysfonction que je veux éviter, ce sont cinq listes parallèles, chacune pilotée par celui qui a crié le plus récemment.
Il existe une seule vue de ce qui compte, et quand deux demandes se percutent, l’arbitrage se fait en public. Parfois la dette gagne contre une fonctionnalité ; parfois c’est l’inverse. L’essentiel est que l’équipe voie le raisonnement : des ingénieurs qui regardent les priorités s’arbitrer honnêtement acceptent des décisions qu’ils auraient vécues comme des décrets.
L’autonomie carbure au contexte#
Les responsables parlent directement avec les parties prenantes produit, métier et opérationnelles. Je ne m’assois pas au milieu de ces conversations : un manager qui relaie tout devient une file d’attente, et une file d’attente ajoute de la latence sans ajouter de jugement.
Ce que je dois à l’équipe, c’est du contexte : pourquoi ce client compte ce trimestre, quelle contrainte pèse réellement sur le métier, quel risque empêche le comité d’architecture de dormir. Mes interventions sont des exceptions avec une forme précise : une décision que personne ne veut porter, une escalade, un désaccord entre domaines, ou le moment où je demande simplement « qu’est-ce que cela suppose, et est-ce vrai ? »
La délégation est le plan de développement#
On grandit en portant un peu plus que le trimestre précédent, avec quelqu’un qui surveille la charge. La progression est concrète : suppléant d’un domaine, puis responsable d’un petit, puis d’un domaine exposé aux clients, puis voix technique dans les décisions qui traversent les domaines. Le feedback est régulier et précis, et la marche suivante toujours visible.
C’est aussi la réponse honnête à « comment retenez-vous les ingénieurs » : en faisant de rester l’option la plus intéressante de la pièce.
Ce que je refuse de faire#
- Pas de héros : un système qui ne survit que grâce à un ingénieur héroïque est un système défaillant avec de bons attachés de presse
- Pas de coffres-forts de connaissances : ce qui vit dans une seule tête ou une commande non documentée est un passif, pas un actif
- Pas de manager-proxy : je refuse d’être l’étape obligatoire entre les ingénieurs et les gens pour qui ils construisent
- Pas d’arbitrage invisible : une priorité qu’on ne peut pas expliquer est une priorité qu’on ne peut pas défendre
Le test du modèle est simple : pourrais-je disparaître trois semaines sans que rien d’important ne m’attende ? Chaque trimestre, la réponse doit se rapprocher du oui.
La version condensée de ce modèle vit dans l’étude de cas de l’équipe Solutions. Cet article, c’est le raisonnement qui la sous-tend.