Ma méthode pour tenir un « notebook WTF » (2021)
(simplermachines.com)- Juste après avoir rejoint une nouvelle équipe, si l’on ne signale pas immédiatement ce qui paraît étrange et qu’on le consigne plutôt dans un notebook WTF, on peut accumuler le contexte nécessaire pour être perçu non comme quelqu’un qui se plaint, mais comme quelqu’un qui aide l’équipe
- Ce qu’il faut noter, ce sont les signaux qui accrochent dans le fonctionnement de l’équipe et le flux technique : des rétrospectives qui se terminent sans action, l’impossibilité d’exécuter les tests en local, un tableau de build constamment dans le rouge, ou une dépendance à une seule personne pour certaines tâches
- Avec le temps, la liste se filtre d’elle-même : raisons valables, corrections déjà en cours, faible priorité pour l’équipe, ou éléments faciles à corriger
- Les problèmes qui subsistent après quelques semaines se traitent en discutant avec les membres de l’équipe, le lead et le manager pour en comprendre les causes et l’historique, puis en résolvant ensemble d’abord les irritants anciens mais relativement simples
- Autrement dit, si l’on accumule d’abord le contexte et les priorités au lieu de déclencher immédiatement le problème, même une nouvelle recrue peut se forger une réputation de résolveur de problèmes sans perdre la confiance des autres
Ma manière d’utiliser un notebook WTF
- La réputation que je veux avoir dans une équipe, c’est : « la personne qui m’aide à résoudre mes problèmes » et « la personne qui fait aboutir ce qui compte pour moi »
- Chaque fois que je rejoins une nouvelle équipe, j’écris
WTF - [Team Name]sur une nouvelle page de mon bullet journal, puis j’y note tout ce qui me semble étrange - Si quelque chose me donne envie d’être changé, je le note aussi comme tâche distincte
- Pendant les deux premières semaines, je me concentre uniquement sur la prise de notes
- Je ne dis pas immédiatement tout ce que je pense que l’équipe fait mal
- Je ne déverse pas en rétrospective une liste de tout ce qu’il faudrait changer
- J’observe, j’écoute, et j’écris ce qui me paraît profondément bizarre
- Cette méthode permet de faire évoluer l’équipe tout en se gérant soi-même, et d’éviter d’apparaître comme quelqu’un qui ne fait que se plaindre
Les signaux étranges que je repère dans une nouvelle équipe
- Dans une nouvelle équipe, il y a toujours des choses qui font penser : « wtf »
- Exemples typiques :
- l’équipe passe une heure à parler d’un problème sérieux en rétrospective, puis termine sans action item
- les tests ne tournent pas en local et personne n’a l’air de s’en soucier
- une grande partie du tableau de build est en permanence rouge
- une seule personne est capable de traiter un travail important et urgent
- l’équipe consacre beaucoup de temps à une fonctionnalité sans que personne sache vraiment pourquoi elle est importante ni en quoi elle aide les clients
Les éléments qui disparaissent de la liste
- Quand la liste devient suffisamment longue, je commence à barrer les éléments un par un
- En général, ils disparaissent pour quatre raisons :
- il y a en réalité une bonne raison
- l’équipe est déjà en train de corriger le problème
- l’équipe ne considère pas ce problème comme important
- c’est vraiment facile à corriger
- Même l’impossibilité d’exécuter les tests en local peut ne pas être un gros problème, selon le contexte
- cela peut être un problème déjà connu et en cours de résolution
- l’équipe peut faire tout son travail dans des machines virtuelles, qu’il est facile de provisionner via une commande de chat
- si le système d’intégration continue est solide et que l’équipe déploie souvent de petits changements, l’absence de tests locaux peut ne pas empêcher plusieurs déploiements par jour
- Pour certains éléments, une solution simple apparaît
- il suffit parfois de savoir où écrire la documentation
- cela peut être un changement facile une fois le bon script trouvé
- quand une solution simple saute aux yeux, je corrige immédiatement
Traiter avec l’équipe les problèmes restants
- Si, après quelques semaines, certains problèmes paraissent toujours étranges et non résolus, j’engage la conversation avec les membres de l’équipe, le lead et le manager
- Les questions portent surtout sur pourquoi ces éléments sont dans cet état et comment on en est arrivé là
- L’objectif est de gagner la confiance comme quelqu’un de sincèrement curieux et empathique, patient, et respectueux de l’expertise de ses collègues
- Si ces problèmes sont encore là, c’est généralement pour quelques raisons récurrentes :
- l’équipe ne les a pas remarqués
- l’équipe s’y est habituée
- le problème est relativement nouveau, et ce qu’il y avait avant était bien pire
- l’équipe ne sait pas comment le corriger
- elle a déjà essayé de le corriger et a échoué
- Les premiers cas peuvent souvent être résolus rien qu’en posant des questions
- la personne en face le corrige immédiatement ou cherche avec vous une solution
- si c’est un problème technique, on peut rédiger ensemble une story ou un ticket puis travailler dessus
- si c’est un problème de processus ou de dynamique sociale, on en parle avec toute l’équipe en rétrospective
- À ce stade, il est utile d’identifier un ou deux problèmes qui agaçaient depuis un moment au moins un autre collègue et qui ont une solution relativement simple
- quand on les met sur le tableau de rétrospective, il faut choisir des problèmes qui ne gênent pas que soi-même
- pendant la discussion d’équipe, on en fait un action item qu’on peut tester tout de suite, à partir d’une proposition faite par ce collègue
- l’équipe commence alors à sentir que la nouvelle personne les aide à résoudre leurs problèmes
Les problèmes plus difficiles et la discussion avec le manager
- Avec le temps, on arrive à des problèmes collants que l’équipe connaît mais qu’elle a peur d’aborder
- Ce sont parfois des problèmes qu’on considère comme « pas si graves », mais dont personne ne veut parler
- il peut y avoir un manque de compétences techniques nécessaires
- le cœur du problème peut être humain et complexe
- À ce stade, je vais voir le manager avec la liste que j’ai constituée
- ce que j’ai observé pendant plusieurs semaines
- le fait que certains points avancent, tandis que d’autres semblent demander plus de temps
- si j’ai raté quelque chose
- les domaines sur lesquels il ou elle veut que je me concentre
- Le manager peut lui aussi s’être inquiété des mêmes problèmes, sans avoir pu insister fortement parce que l’équipe n’avait pas l’air d’en souffrir tant que ça
- Ensuite, on peut organiser ensemble les préoccupations du manager et les problèmes, et parler de ce qui a bien marché — ou non — dans le passé
- Le manager commence alors à vous voir comme quelqu’un qui a du jugement et qui peut aider à résoudre des problèmes plus difficiles
Pourquoi ne pas le signaler immédiatement
- La réputation que je veux, c’est : « Nat m’aide à résoudre mes problèmes » et « Nat fait aboutir les choses qui comptent pour moi »
- Cette réputation peut aider à obtenir le résultat souhaité lors de l’évaluation annuelle suivante, puis mener à des recommandations quelques années plus tard
- Avant, je signalais les problèmes dès que je les repérais
- résultat : j’ai acquis la réputation de « toujours se plaindre » et de « penser qu’on ne fait jamais rien correctement »
- les gens ont commencé à ne plus écouter, j’étais frustrée sur le plan personnel, et c’était aussi inefficace professionnellement
- Quand une nouvelle recrue fait beaucoup de bruit autour de quelque chose qui n’est pas réellement un problème, que l’équipe ne voit pas comme un problème, qu’elle est déjà en train de résoudre, ou pour lequel il existe une solution simple qu’elle n’avait pas encore vue, la confiance s’effondre très vite
- Dans une équipe, il y a toujours beaucoup de problèmes à améliorer, mais seule une partie peut réellement être résolue
- L’ordre dans lequel on repère les problèmes est rarement l’ordre le plus efficace pour les résoudre
- Le notebook WTF permet de mettre de côté, temporairement, l’envie de tout corriger tout de suite, jusqu’à ce qu’on ait assez de contexte pour décider par quoi commencer
1 commentaires
Avis de Hacker News
Il me semble que cet article n’insiste pas assez sur un point : le regard d’une personne nouvelle n’existe qu’une seule fois
Si l’on juge mal l’utilisabilité d’un produit, c’est parce qu’on sait déjà s’en servir et qu’on est devenu insensible aux erreurs et aux défauts
Un nouveau membre de l’équipe n’en est pas encore là ; observer ce qu’il demande, où il bloque et où il a réellement besoin d’aide peut donc apporter beaucoup d’enseignements à l’équipe
On s’assoit avec un carnet, on prend des notes et on discute avec l’utilisateur pendant qu’il utilise le produit
Même en accumulant des téraoctets de données de télémétrie, on ne comprend pas aussi bien la façon dont le produit est utilisé qu’en parlant à de vrais utilisateurs
Le secteur de la tech devrait un peu surmonter sa peur des autres humains
C’est un peu comme un professeur expérimenté qui oublie que ce qu’il faut expliquer à un étudiant débutant est difficile
Cela dit, tout le monde n’est pas également mauvais dans cet exercice : cela dépend beaucoup de la capacité d’empathie et de l’intérêt que l’on a à se mettre à la place d’un débutant
Deux personnes ayant utilisé le shell Bash d’innombrables fois peuvent avoir une compréhension totalement différente de ce qui paraît étrange et peu intuitif à un novice
Porter un regard neuf est aussi une compétence, et on peut l’améliorer par l’entraînement, comme on apprend à dessiner en observant la lumière et les objets réels
Si l’on note les choses au lieu de les exprimer immédiatement, on gagne du temps pour comprendre pourquoi elles sont ainsi et pour appréhender la cartographie de l’organisation
Une fois que les comptes, les permissions, les validations et autres sujets de ce genre sont réglés, on peut agir à partir de cette liste
L’équipe aura alors plus de chances de vous voir comme quelqu’un qui veut aider, plutôt que comme « la personne qui surgit sans arrêt en criant WTF »
À l’échelle de 12 à 15 personnes, cela fonctionnait très bien, mais je ne sais pas si cela passerait bien à une échelle plus grande
Noter et attendre est immédiat, peu coûteux, et procure même la petite récompense de voir que « la liste s’est allongée » ; avec une pratique systématique, cela peut donc se réapprendre facilement
J’aime le fait de continuer à séparer la phase où l’on remarque et consigne les choses, de celle où, plus tard, on établit une carte, on observe, on apprend et on rassemble des personnes partageant les mêmes préoccupations pour les guider
Tenir un journal de travail est toujours une bonne idée, mais quelque chose me gêne dans le ton de cet article
Je n’ai pas envie de travailler avec quelqu’un qui se comporte comme les Borgs ou qui suit un scénario semblant tiré de 『How to Win Friends and Influence People』
Si quelqu’un donne l’impression d’essayer de me manipuler, il m’est difficile de lui faire confiance, au moins à partir du moment où je m’en rends compte
Cela dit, mieux vaut ne pas se laisser guider uniquement par ce rejet immédiat
Moi aussi, je me fixe des objectifs sur la façon dont je veux que les parties prenantes me perçoivent, et cela s’est révélé assez utile comme critère de comportement
Même en faisant du bon travail technique, ignorer la dimension relationnelle a fini par poser problème ; les rumeurs qui circulent, la manière dont je suis perçu et la façon dont mon travail est présenté comptent réellement
Dire « il suffit de bien faire son travail » ne fait pas disparaître le fait que mon travail, et l’impression que je donne aux autres, ont de l’importance
Je n’ai jamais lu 『How to Win Friends and Influence People』, mais j’ai trouvé l’article lui-même plutôt bien écrit
Qu’on soit contributeur individuel expérimenté, nouveau manager ou officier, les 30 à 90 premiers jours se ressemblent : il ne faut rien changer, mais chercher à comprendre comment les choses fonctionnent et, plus important encore, pourquoi elles fonctionnent ainsi
Les bénéfices pour l’organisation sont nombreux et, pour le dire brièvement, c’est réellement ainsi que cela se fait
Les ingénieurs ont travaillé sous de mauvais managers et, même s’ils ne savent pas toujours expliquer précisément pourquoi ils étaient mauvais, ils le sentent souvent
Cette impression de « mauvais manager » vient souvent d’une incapacité à exercer un bon leadership tactique ; et comme l’ingénierie, le leadership est une compétence qui s’apprend
Le problème, c’est qu’il existe peu d’endroits où on l’enseigne délibérément, comme dans l’armée ou dans certaines formations pour cadres dirigeants
Si l’on veut travailler sous un bon manager, on veut en réalité travailler sous un bon leader, et le leadership est une compétence tactique, au même titre qu’écrire du code C++ efficace
Il s’agit de coordonner et de guider des personnes pour atteindre un objectif supérieur à la somme de ce que chacun pourrait produire séparément ; sous certains angles, cela peut ressembler à de la manipulation
Pourtant, la personne qui protège l’équipe des absurdités extérieures, obtient les ressources nécessaires, félicite en public et critique en privé, donne une direction sans micro-manager à l’excès, reconnaît et récompense les résultats, et ne laisse pas passer les performances insuffisantes, est généralement le type de leader que les ingénieurs apprécient
À l’inverse, quand un MBA charismatique et politique, sans bagage technique, utilise ces techniques pour de mauvaises raisons, il devient quelqu’un avec qui on n’a pas envie de travailler
Les personnes issues de postes techniques qui accèdent au management mais refusent d’admettre que manager est différent de la compétence technique sont elles aussi souvent détestées
Au final, pour que le secteur compte davantage de leaders compétents, il faut traiter le leadership, comme le fait ce type d’article, non pas comme une intuition innée et vague, mais comme un ensemble de tactiques que l’on peut expliquer et pratiquer
Se forger une réputation de « Nat résout mes problèmes » est bon pour les recommandations, mais peut être dangereux pour une carrière
Je l’ai fait pendant 20 ans dans plusieurs services, et à chaque fois on a cherché à me garder comme personne qui résout les problèmes, pas à me mettre dans la liste des candidats à une promotion
Un collègue parti à la retraite après 40 ans de travail était lui aussi quelqu’un capable de résoudre n’importe quel problème, et bien plus compétent que les managers, mais il n’a jamais été promu
Il était l’atout secret de tout le monde, mais presque jamais reconnu ; résoudre les problèmes était considéré comme « normal », sans récompense
On appliquait des critères bien plus bas aux autres personnes du même niveau, et lors de son dernier entretien d’évaluation, le manager a dit : « je n’évalue pas par rapport aux collègues, mais par rapport aux objectifs »
Un autre manager m’a dit la même chose, donc ce n’était pas un hasard
Surtout, mon manager était toujours de mon côté quand il fallait bloquer des demandes qui ne venaient pas de lui
Si quelqu’un que je ne connaissais pas me demandait quelque chose de non trivial et que je n’avais ni le temps ni l’envie, je pouvais dire : « Je n’ai pas le temps de regarder ça pour l’instant. Si vous avez besoin d’une priorité, parlez-en à mon manager », et 99 fois sur 100 ça n’allait pas jusqu’au manager
Le principal avantage à devenir la personne vers qui l’on se tourne dans un service ou dans toute l’entreprise, c’est d’accumuler des connaissances et un réseau
Quand on a besoin d’informations hors de son équipe, ou de traverser la bureaucratie pour quelque chose d’important, ça agit comme un petit superpouvoir
On se constitue aussi un réseau à contacter quand on cherche de nouvelles opportunités, et tous les emplois que j’ai obtenus en 15 ans dans le privé sont venus par ce biais
On peut toutefois dire que l’une des deux approches passe bien le processus de promotion, et l’autre non
Ce n’est pas facile, mais poser des limites est une compétence importante
La partie disant que « quand Nat le sortait dès qu’il voyait un problème, il a fini par avoir la réputation de toujours se plaindre et de penser que tout ce que nous faisions était faux » devrait se trouver presque tout en haut de l’article
Ce niveau de conscience de soi est une vraie compétence qui mérite d’être apprise
L’ancien astronaute Chris Hadfield dit aussi dans son livre qu’il adoptait une approche similaire lorsqu’il rejoignait une nouvelle mission et une nouvelle équipe
Il commençait par se mettre en mode observation pour apprendre si les moments WTF étaient réellement justifiés, sans agacer les nouveaux coéquipiers
Ça vaut la peine d’être lu
Après être resté longtemps au même poste, je trouve que créer un endroit où mettre le bruit permet au moins de ne pas le garder tel quel dans sa tête
Il ne s’agit pas seulement de juger si un problème est valable, mais aussi, pour certaines choses, d’apprendre à lâcher prise
Ce serait bien de savoir lequel
Quand j’arrive dans une situation déjà existante, j’ai généralement procédé de cette façon
La première semaine, je passe tout en revue en notant mes questions et mes observations
Je ne note pas seulement les moments « WTF », mais aussi ce qui fonctionne bien et ce qui me semble être de très bonnes idées
Ce n’est qu’ensuite que je relis, priorise, puis entre dans la discussion
Cela ressemble à un principe qui s’accorde bien avec la barrière de Chesterton
C’est l’histoire de quelqu’un qui veut enlever une clôture, à qui l’on dit : « si vous ne connaissez pas son usage, je ne peux pas vous laisser l’enlever. Allez réfléchir, et quand vous pourrez dire que vous avez compris son usage, alors vous pourrez la supprimer »
Plus clairement, cela signifie que même si quelque chose paraît maladroit, il vaut mieux partir du principe que les personnes arrivées avant étaient intelligentes et qu’il y avait une raison
Cette raison est peut-être devenue obsolète, mais si on ne la prend pas en compte, on répétera la même erreur
Maintenir une liste des choses que l’on veut corriger est une bonne idée aussi parce qu’en les laissant reposer, on peut comprendre pourquoi certaines choses sont comme elles sont
Souvent, elles ont été faites dans l’urgence ou comportent des erreurs, mais parfois il existe réellement une complexité cachée qu’il est difficile de saisir immédiatement en ne regardant qu’une ligne de code
Les premiers sont des échecs manifestes, les seconds se résolvent généralement quand on s’immerge suffisamment dans l’environnement
Mais il reste utile de noter les deux
Justement cette semaine, je disais à deux collègues que j’avais sur mon ordinateur un fichier « How the F »
Ce n’est pas exactement la même chose que ce que décrit l’auteur, mais c’est très proche : quand j’arrive dans une nouvelle équipe, j’y note toutes les choses qui me font me demander « comment est-ce qu’on fait déjà ça ? » chaque fois qu’un problème survient
Contrairement au texte original, je ne l’apporte pas à mon manager, mais cela me donne une perspective pour comprendre quels sont les points de friction de l’équipe et de l’entreprise, puis les résoudre au fil du temps
Je vis en notant dans une liste toutes les idées qui me viennent
Sans ordre particulier, je les ajoute continuellement sur du papier ou dans un fichier texte
Les idées ne surgissent pas vraiment quand on en a besoin ; elles arrivent toute la journée pendant qu’on fait autre chose, et si je ne les note pas, en tout cas moi, je ne m’en souviens pas
Quand il faut vraiment faire quelque chose, il suffit de les rayer une par une, donc pas besoin de se demander quoi faire ensuite ; comme les idées ne s’épuisent pas, cela permet une assez grosse explosion de productivité
Ça ressemble à une discussion sur l’organisation d’une liste de tâches personnelle, alors que le texte original parle de la manière de s’adapter et de communiquer au sein d’une équipe
La vie est trop courte pour organiser ses notes ; je préfère tout noter, puis m’appuyer sur le tri antichronologique et la recherche
Ironiquement, je sais que j’ai un trésor d’idées incroyables, mais à mon âge je ne me soucie plus autant de les exécuter qu’à vingt ans