Debugger une équipe comme un système

J'ai commencé à manager une équipe il y a quelques mois, et le premier problème de processus qui m'est tombé dessus, je l'ai traité comme la plupart des gens le font. Personne par personne. Tu peux relire ça plus vite. Quelqu'un peut s'occuper du truc qui attend depuis un moment. Chaque conversation a marché une fois. Aucune n'a tenu. Une semaine plus tard, le même problème était de retour avec une chemise légèrement différente.

Ça m'a pris un temps gênant pour repérer le motif dans mon propre comportement. Je colmatais la même fuite avec le même scotch tous les deux ou trois jours en me félicitant d'être réactif. La fuite, elle, s'en fichait. Je traitais des symptômes dans un système qui avait un défaut structurel, et les défauts structurels ne répondent pas aux encouragements.

Alors j'ai essayé de regarder ça comme je regarderais un service qui n'arrête pas de tomber. Pas qui échoue, mais où. Ce qui entre. Où ça reste posé. Qui décide de la suite. Où le signal qu'un truc cloche arrive trop tard pour qu'on puisse agir. Une équipe qui fait passer du travail dans un processus, c'est un système, et ce qui est bien avec les systèmes, c'est qu'on peut les debugger. Ce recadrage est la seule chose qui me garde sain en ce moment, parce que presque tout le reste de ce boulot est nouveau et je m'accroche au seul jeu de réflexes en qui j'ai vraiment confiance.

Où le travail fait la queue

Commence par la queue, parce que presque tous les problèmes d'équipe se manifestent là en premier.

Le travail arrive. Une demande de relecture, un design qui attend une décision, un incident, une question qui bloque quelqu'un. Ça entre quelque part et ça doit ressortir dans un état résolu. Entre les deux, ça attend. La question intéressante n'est jamais « est-ce qu'il y a une queue ». Il y a toujours une queue. La question, c'est où elle se forme et pourquoi elle arrête d'avancer.

Imagine des demandes de relecture qui s'empilent dans un espace partagé, chacune posée là pendant des jours. Pas parce que quelqu'un est fainéant, mais parce que chaque personne qui voit une demande suppose qu'elle appartient à quelqu'un d'autre. C'est la dilution de la responsabilité, et ça se comporte exactement comme un load balancer sans health checks. Tu arroses un pool de nœuds de requêtes en espérant que l'un d'eux soit à la fois disponible et le bon. La plupart du temps, tu n'as ni l'un ni l'autre.

La solution pour cette classe de problème est ennuyeuse et c'est du routing. Donne au travail un propriétaire clair. Pas un comité, pas un canal, un propriétaire. La seule amélioration la plus fiable que j'ai faite jusqu'ici, c'est de supprimer l'ambiguïté sur à qui revient un truc. Les gens évitent le travail bien moins souvent qu'ils n'évitent de devoir déterminer si le travail est le leur. Une fois qu'une demande a un nom dessus dès l'instant où elle arrive, la queue commence à se vider toute seule, et j'arrête d'être le load balancer que je n'ai jamais voulu être.

Quand la queue n'a pas de consommateur

Certaines queues n'avancent pas seulement lentement. Elles n'ont rien à l'autre bout qui tire le travail.

Un coéquipier bloqué en est l'exemple le plus net. Imagine quelqu'un coincé pendant deux jours à attendre une décision qui n'existe que dans ta tête, ou un accès que personne n'a pensé à accorder. C'est une queue sans consommateur. Le travail entre et rien n'en sort, et la personne qui y est attachée cale en silence pendant que tout ce qui est en aval d'elle cale aussi. Le coût, ce n'est pas une personne inactive pendant deux jours. C'est la backpressure, le truc à moitié fini qu'elle ne peut pas passer à quelqu'un, le relecteur qui l'attend, le plan qui supposait qu'elle aurait terminé.

J'ai appris à traiter un élément bloqué comme le signal le plus prioritaire de l'équipe, au-dessus de presque tout ce que je préférerais faire. Une queue engorgée ne se répare pas toute seule, et elle devient plus chère plus elle reste, parce qu'au bout d'un moment la personne arrête de demander. Elle trouve autre chose à gratter, le blocage devient invisible, et le coût continue de s'accumuler là où je ne le vois pas. Mon rôle là-dedans est bête et sans gloire : trouver le truc qui est coincé, et soit le consommer moi-même, soit le passer à quelqu'un qui peut. Vite. La vitesse compte plus que l'élégance.

Où la boucle est lente

La troisième chose que je cherche, c'est la latence du feedback. Combien de temps entre le moment où un truc dérape et le moment où quelqu'un qui a le pouvoir de le corriger l'apprend.

Une demande qui reste posée deux jours sans que personne ne remarque, c'est un timeout sans circuit breaker. L'auteur finit par relancer, gêné, et là tu as ajouté de la friction sociale par-dessus le délai. Le travail n'était pas dur. Le signal était juste lent. Le temps que quelqu'un réagisse, le contexte avait refroidi et la personne était trois tâches plus loin.

On ne corrige pas un feedback lent en demandant aux gens d'être plus attentifs. L'attention est la chose la plus chère et la moins fiable de l'équipe, la mienne comprise. On le corrige en rendant la boucle courte par construction. Le truc qui est coincé devrait faire du bruit tout seul. Le propriétaire devrait entendre parler de sa queue sans avoir à penser à la vérifier. Si tu te retrouves à compter sur quelqu'un qui scrute consciencieusement une liste, tu as déjà perdu, parce que le jour où il est occupé est exactement le jour où la queue s'engorge.

C'est aussi pour ça que je garde le statut de l'équipe peu coûteux à lire. Un système que tu ne peux pas observer est un système sur lequel tu fais des hypothèses, et j'ai fait beaucoup d'hypothèses mon premier mois. Pas une réunion de statut où tout le monde joue la comédie du progrès pendant quarante minutes. Quelque chose de léger et d'ambiant, où l'état du travail est visible sans que personne ait à l'assembler. Le but de l'observabilité n'est pas de surveiller les gens. C'est pour que la boucle lente se montre comme une boucle lente avant de devenir un incendie, et pour que je ne sois pas le goulot par lequel chaque information doit passer.

Mesure le résultat, pas l'agitation

Voilà celui que j'ai le plus mal compris, et c'est le plus facile à rater parce que la version cassée donne une impression de productivité.

C'est très tentant de mesurer l'activité. Tickets fermés, relectures faites, heures visiblement dépensées. L'activité est facile à compter, ce qui est exactement pourquoi c'est un piège. Une équipe peut être énormément occupée et ne rien livrer qui compte. Je me suis surpris à me sentir bien après une semaine où le board avait beaucoup bougé et, quand j'ai vraiment regardé, rien de ce mouvement ne se rattachait à ce qu'on avait dit vouloir faire.

Ce qui vaut la peine d'être mesuré, c'est le résultat. Est-ce que l'objectif a avancé. Est-ce que le truc qu'on a dit important s'est vraiment amélioré pour les gens en aval de nous. L'output, c'est le mouvement ; le résultat, c'est de savoir si le mouvement a mené quelque part. Quand je m'ancre sur le résultat, beaucoup de travail à l'air occupé se révèle être du bruit, et un peu de travail discret qui n'a produit aucune activité visible se révèle être la seule chose qui comptait. La difficulté, c'est que les résultats sont plus lents et plus brouillons à lire que l'activité, alors le truc fainéant et le truc occupé sont le même truc, et je dois continuer à choisir le contraire.

Mécanique contre jugement

Voilà la distinction qui a réorganisé ma façon de penser tout ça.

Une partie du travail dans un processus est mécanique. C'est une checklist. Une machine pourrait l'exécuter, en principe, parce que la réponse ne demande ni goût ni contexte. Avant qu'un truc parte : est-ce que chaque nouveau chemin a un test, est-ce qu'il y a un moyen de faire un rollback, est-ce qu'un truc évident a été laissé à moitié fait. Ces questions ont des bonnes réponses qui ne dépendent pas de qui demande. Une barrière comme ça n'est qu'une checklist, et une checklist, c'est la fiabilité la moins chère que tu puisses acheter, tant qu'autre chose que la mémoire humaine la fait respecter.

Le reste demande du jugement. Est-ce la bonne abstraction. Est-ce que la prochaine personne comprendra ça dans six mois. Est-ce que ce changement vaut la complexité qu'il ajoute. Aucune checklist ne te donne ça. Il faut un humain qui a le contexte et qui accepte d'avoir tort.

L'erreur que j'ai faite pendant un moment, c'était de traiter les deux types pareil. J'écrivais des checklists pour les parties mécaniques et je demandais aux gens de les dérouler dans leur tête tout en faisant aussi les parties de jugement. Ça ne marche pas, et la raison est juste de l'arithmétique. L'attention humaine est finie. Une checklist de quinze points et « est-ce que ce design tient la route » puisent dans le même compte. Demande à quelqu'un de tenir les deux et il fera bien la partie intéressante et sautera discrètement la moitié de la partie ennuyeuse. Pas par malveillance. La partie ennuyeuse est exactement le genre de truc qu'une personne fatiguée laisse tomber, et tout le monde est parfois fatigué.

Une fois que tu vois le travail découpé comme ça, le mouvement à faire est évident. Pousse le travail mécanique vers quelque chose de mécanique. Une vérification qui a une bonne réponse devrait être exécutée par une machine, à chaque fois, sans dépendre de si un humain s'en est souvenu. Ce n'est pas une idée sophistiquée. C'est le même réflexe que d'écrire un test plutôt que de demander aux gens de vérifier la même chose à la main à chaque changement.

Le but n'est pas l'automatisation pour elle-même. C'est que l'attention est la ressource rare, et tu veux dépenser chaque unité sur les décisions qui ont vraiment besoin d'une personne. Quand la machine s'occupe de « est-ce qu'un truc a été laissé à moitié fait », le relecteur peut consacrer tout son cerveau à savoir si le changement est bon. C'est l'échange. Tu ne retires pas l'humain. Tu le vises.

La croissance fait partie du système

Pendant un moment, j'ai traité la croissance des gens comme un truc qui se passait à côté du travail, dans les entretiens individuels et la saison des évaluations, séparé de la machinerie qui livre. C'était à l'envers.

La façon dont quelqu'un rejoint l'équipe fait partie du système. Une nouvelle personne coincée une semaine parce que personne ne lui a routé le contexte dont elle avait besoin, c'est la même queue bloquée qu'avant, juste avec des enjeux plus hauts, parce que sa première impression du fonctionnement de l'équipe se forme pendant qu'elle attend. Pareil pour la façon dont les gens progressent. Si le seul moment où quelqu'un se demande si une personne est prête pour plus est la semaine où la question est formellement posée, tu as construit un processus avec une latence de feedback catastrophique, et la réponse arrive trop tard pour qu'on puisse agir pour la personne qui en avait besoin.

Alors j'essaie de traiter l'onboarding et la croissance comme n'importe quel autre flux qui vaut la peine d'être observé. De quoi une personne a-t-elle besoin pour se débloquer et le rester. Où est le signal qu'elle est prête pour plus, et arrive-t-il à temps pour qu'on puisse en faire quelque chose. C'est le même réflexe que tout ce qui précède, pointé sur la queue la plus lente et la plus importante de l'équipe, qui est une personne en train de devenir meilleure dans son boulot.

Ce que je continue de rater

Je fais encore trop confiance à la structure. Je vais concevoir une règle de routing propre et supposer que le problème est résolu, puis regarder le travail trouver un nouvel endroit où s'empiler que je n'avais pas anticipé. Les systèmes contournent tes intentions. Une queue que tu élimines à un endroit a tendance à réapparaître un cran en amont ou en aval, et tu ne la trouves qu'en regardant où le travail ralentit vraiment, pas où ton diagramme dit qu'il devrait s'écouler.

Je m'accroche aussi à une vérification mécanique quand le vrai problème demande du jugement, parce qu'une vérification donne une impression de progrès et qu'une conversation difficile, non. Si les relectures sont superficielles parce que personne ne se sent responsable de la qualité, aucune quantité de linting automatique ne corrige ça. J'ai quand même livré l'automatisation, plus d'une fois, et je me suis senti productif pendant que le vrai problème restait intact. Quelques mois après, les conversations difficiles restent ce dans quoi je suis le plus mauvais, et c'est ce que la lentille des systèmes ne peut pas faire à ma place.

Les modes de défaillance que je continue de voir sont la même petite poignée. Du travail sans propriétaire. Un élément bloqué sans rien qui le tire de la queue. Du feedback qui arrive trop tard pour servir. De l'activité mesurée à la place des résultats. De l'attention humaine dépensée sur des choses qu'une machine devrait posséder, et pas assez de réserve pour les choses que seule une personne peut faire. Aucun de ces problèmes n'est un problème de personnes même s'ils ressemblent toujours d'abord à des problèmes de personnes. C'est le piège, et c'est celui dans lequel je tombe le plus, parce que trouver qui échoue donne l'impression de faire quelque chose. La question plus utile, c'est où est le système, et un système ne s'améliore pas parce que tu le lui as demandé gentiment.