Auteur/autrice : Éric

Extraits de The Mana­ger’s Path

In-groups tend to be resis­tant to ideas that do not come from those within the group. […] Because they believe they’re in the best group but they still find them­selves bored, they don’t appre­ciate the growth they could find just by swit­ching to a new team.

On parle souvent des archi­tectes dans leur tour d’ivoire mais pour moi l’ef­fet prin­ci­pal n’est pas la décon­nexion : C’est la croyance d’être supé­rieur aux autres au point de ne pas avoir à inté­grer ce qui vient de l’ex­té­rieur, de ne pas avoir de choses à apprendre des autres, de ne pas vouloir se mêler aux autres.

C’est un compor­te­ment toxique pour l’équipe en ques­tion mais aussi pour celles autour. Le voyant rouge appa­rait dès qu’il y a senti­ment de supé­rio­rité. Il est l’in­di­ca­teur qu’on se voit en « nous vs les autres » plutôt qu’une large équipe pleine de collègues diffé­rents à laquelle on parti­cipe tous.

Ce n’est pas toujours facile mais la seule solu­tion que je connais c’est de faire explo­ser l’équipe qui se sent supé­rieure pour la répar­tir dans toutes les autres. Il y aura des départs mais je n’ai pas vu d’al­ter­na­tives fonc­tion­ner quand on en est arrivé là.

When they go too far, this iden­tity is used to make the team feel super­ior to the rest of the company

As a mana­ger, be care­ful about focu­sing on your teams to the exclu­sion of the wider group

Tout ça est aussi vrai pour le dépar­te­ment tech par rapport au reste de l’en­tre­prise ou du produit. Ça empêche la colla­bo­ra­tion, de consi­dé­rer les autres personnes et leurs propres connais­sances, leur propre point de vue, comme des éléments de valeur permet­tant d’en­ri­chir l’en­semble de l’en­tre­prise.

In-group teams tend to be very fragile to the loss of their leader. When you hire a mana­ger who builds a clique, that clique is likely to dissolve and leave the company if the mana­ger leaves the company

Et votre rôle en tant que leader ou mana­ger, c’est d’un jour deve­nir inutile, que l’équipe fonc­tionne sans vous. Si l’équipe prend la direc­tion contraire, il y a une action immé­diate à prendre.

Extrait de The Mana­ger’s Path

Frequency of Releases

Je trouve toujours ça très dur de mesu­rer la santé des équipes de déve­lop­pe­ment avec des indi­ca­teurs chif­frés. Il y a bien plus de moyen de mal inter­pré­ter et mal utili­ser ces indi­ca­teurs que de manière de bien le faire.

Je ne suis pas en train de promou­voir l’ab­sence de chiffre, mais mon indi­ca­teur premier reste le juge­ment subjec­tif du mana­ger qui travaille avec l’équipe. L’in­di­ca­teur n’est là qu’é­ven­tuel­le­ment pour l’aler­ter si jamais il n’a pas vu quelque chose.

La fréquence de déploie­ment me semble un bon indi­ca­teur à mesu­rer, car proche de l’uti­li­sa­teur final. Il reste que parfois ça peut augmen­ter et être mauvais signe (plein de correc­tifs) ou dimi­nuer et être bon signe.

Dans tous les cas, je propose de ne jamais lier ces indi­ca­teurs à un système de récom­pense ou d’éva­lua­tion. C’est le meilleur moyen de se retrou­ver à faire un effet cobra. De manière géné­rale, la fixa­tion d’objec­tifs par les indi­ca­teurs me parait assez nocive, parti­cu­liè­re­ment dans les métiers de réflexion.

Une façon de faire ça, c’est déjà de ne faire que des mesures collec­tives, pas de mesures indi­vi­duelles.

Frequency of Code Check-ins

J’ai plus de mal à voir cette mesure là. Si l’idée est d’être en déploie­ment continu, sur des chan­ge­ments les plus petits possibles, un déploie­ment et un check-in c’est quasi­ment la même chose.

Frequency of Inci­dents

Mesu­rer les inci­dents parait une évidence mais j’ai un nombre absolu bien trop faible pour en tirer quoi que ce soit. Si j’ai trois inci­dents cette semaine, est-ce un coup de pas de chance ? que j’ai plus d’in­gé­nieurs sur le pont ? qu’on a livré des choses majeures derniè­re­ment ? qu’ils s’at­tachent aux sujets de fond plutôt qu’à des travaux simples en surface ?

Ça se mesure, mais ça se décompte sur plusieurs mois donc ça n’est pas super utile pour réagir si la perfor­mance s’ef­fondre.

Extrait de The Mana­ger’s Path

Assu­ming that the job at this level becomes essen­tially nontech­ni­cal is a mistake.

Je ne sais toujours pas où me situer.

Quelque part, ce que je fais demande de la connais­sance et compé­tence tech­nique. Il y a une part de légi­ti­mité auprès des équipes mais aussi de savoir ce que les choses veulent dire, comprendre les problèmes, y avoir été confronté, pouvoir aider à les résoudre, soupe­ser les enjeux…

Je ne comprends pas ces étudiants de grandes écoles qu’on place trop tôt en situa­tion de direc­tion décon­nec­tés d’une réalité qu’ils n’ont jamais connu.

J’ai besoin de solides compé­tences tech­niques, de pouvoir prendre le poste des diffé­rents membres de l’équipe, mais mon job est lui assez peu tech­nique. Mon job c’est de l’hu­main, du pilo­tage, de la progres­sion person­nelle, de la stra­té­gie, de l’ad­mi­nis­tra­tif, et plein de trucs mais le code et la tech­nique n’en sont pas des éléments impor­tants.

Extraits de The Mana­ger’s Path

But to create this envi­ron­ment, she some­times must say no. She must say no to the team. She must say no to her peers. She must even say no to her boss.

Ce chapitre me rappelle les livres d’aide aux parents. Il faut savoir dire non, mais le faire d’une façon qu’il soit compris et partagé, voire avec un « oui à condi­tion que […] ». En remplaçant « équipe » par « famille », on pour­rait vrai­ment échan­ger les livres.

Ce ressenti mis à part, dire non est effec­ti­ve­ment toujours diffi­cile. C’est une limite qu’on pose et une auto­rité qu’on impose. Plus je dis non, plus je tue l’ini­tia­tive et prends le risque qu’on me propose moins.

Parfois c’est pénible, surtout pour les mana­gers débu­tants.

« Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the road­map. »

J’aime bien cette façon de faire, le « oui à condi­tion que […] ». L’au­teure le voit comme un arti­fice.

Moi je le vois comme une façon de ne pas discu­ter les faits (on ne peut pas tout faire) et de redi­ri­ger la conver­sa­tion vers les choix stra­té­giques plutôt que vers un clas­sique « comment peut-on faire pour faire travailler plus ».

C’est là que les conver­sa­tions inté­res­santes commencent. Parfois on se rend compte qu’il faut déga­ger la table et lever des contraintes ou des évidences qui n’en sont pas.

D’autres fois ça permet d’ali­gner les membres de l’équipe parce que le non dit c’est le choix stra­té­gique en amont. Quand il y a une frus­tra­tion de ne pas pouvoir réécrire telle ou telle partie de code, en réalité c’est d’abord qu’il n’y a pas d’ali­gne­ment sur quels sont les besoins aujourd’­hui de l’en­tre­prise, et quelles sont ses prio­ri­tés stra­té­giques. Une fois qu’on partage la même vision, on fait très souvent les mêmes choix.

“Help me say yes” means you ask ques­tions and dig in on the elements that seem so ques­tio­nable to you. Often, this line of ques­tio­ning helps people come to the reali­za­tion them­selves that their plan isn’t a good idea, but some­times they’ll surprise you with their line of thin­king.

C’est fina­le­ment une déri­vée de la précé­dente mais c’est celle que j’em­ploie plus avec mes mana­gers. L’objec­tif c’est leur donner les enjeux et m’as­su­rer qu’ils feront eux mêmes les bons choix par la suite.

Je suis aussi alignée avec l’au­teure : C’est aussi permettre à quelqu’un de montrer que c’est lui qui a raison au final, que lui a inté­gré un enjeu de plus que nous, ou une idée qui n’avait pas été pensée jusqu’a­lors.

You won’t have the luxury to care­fully inves­ti­gate and analyze every deci­sion, so prac­tice getting comfor­table with the quick no (and the quick yes!) for low-risk, low-impact deci­sions.

C’est la fin de section qui me gêne.

Si c’est sans risque, sans impact, ne serait-il pas mieux de ne simple­ment pas faire de vali­da­tion et lais­ser les équipes faire leurs propres choix ?

C’est déjà vrai plus globa­le­ment. Les deux tech­niques plus haut sont une façon de refaire le chemin ensemble pour arri­ver aux mêmes conclu­sions. Dans une certaine mesure je suis là pour coacher et faire en sorte que les personnes prennent les bonnes déci­sions, pas pour les prendre moi.

Si c’est un petit impact et un petit risque, plus qu’être confor­table à dire oui ou non rapi­de­ment, j’ai plus inté­rêt à ne pas choi­sir moi et lais­ser faire les concer­nés.

Extrait de The Mana­ger’s Path

A friend of mine recently became a direc­tor of engi­nee­ring, and she had to start having an assis­tant order her lunch because she disco­ve­red that she would forget to eat — and had no energy to decide what to eat when she reali­zed she needed food.

Sans en arri­ver à cet extrême, qui n’est évidem­ment sain ni pour la direc­trice ni pour l’or­ga­ni­sa­tion, je me pose toujours la ques­tion de l’as­sis­tant — ou du bras droit, suivant comment on l’ap­pelle.

Il était fréquent dans les anciennes orga­ni­sa­tions d’avoir des assis­tants et des secré­taires. C’est une vision qu’on consi­dère souvent dépas­sée dans les nouvelles orga­ni­sa­tions qui se veulent très à plat. Je m’in­ter­roge encore du pourquoi.

Sans bras droit, je me retrouve à faire des tâches à peu de valeur ajou­tée. Je peux délé­guer mais ce sont des tâches qui n’entrent pas forcé­ment dans le péri­mètre de mes mana­gers qui ont leurs propres missions, ou qui ne sont pas valo­ri­santes pour eux non plus.

As tasks come at you, ask your­self: do I need to be the person who completes this work?

Mon problème, encore non résolu est plutôt le « à qui délé­guer cette tâche ». Si c’est une tâche complexe et longue, je n’ai personne avec assez de liberté pour le sortir de ses autres missions. Si ce sont des tâches à vrai­ment très faible valeur ajou­tée, c’est diffi­cile de les reba­lan­cer à mes leads d’équipe, surtout si la trans­mettre prend déjà du temps.

Ça fait daté mais cette dispa­ri­tion des secré­taires et des assis­tants me semble globa­le­ment une erreur.

This is also why I stron­gly advise you main­tain your prac­tice of regu­lar, reliable 1–1 meetings with everyone who reports directly to you.

Je fais un peu de coaching et je discute avec d’autres direc­teurs tech­niques ou mana­gers. Je suis toujours étonné de voir à quel point on consi­dère les 1–1 comme une contrainte qu’on veut dimi­nuer le plus possible.

Faites vos 1–1 toutes les semaines, même si ça ne dure que 5 ou 10 minutes. L’es­pace est là, il servira le jour où il y en aura besoin. Il vous permet­tra aussi de détec­ter des choses qui ne se verraient pas sinon.

Il nous arrive d’en annu­ler un de temps en temps, excep­tion­nel­le­ment deux de suite, mais je prends géné­ra­le­ment au moins 40 minutes par semaine à mon CEO pour discu­ter de ce que je fais et de ce que je ne fais pas.