Étiquette : The manager's path

Extrait de The Mana­ger’s Path

faster” is not about “the same number of hours but fewer total days.” “Faster” is about “the same value to the company in less total time.” If the team works 60 hours in a week to deli­ver some­thing that other­wise would’ve taken a week and a half, they haven’t worked faster, they’ve just given the company more of their free time.

J’ai vu des mana­gers cacher ça derrière la notion d’in­ten­sité de travail, pour ne pas dire qu’ils en voulaient plus, mais ce n’était qu’un paravent bien pratique.

Je ne connais qu’une seule façon d’ap­por­ter plus de valeur et c’est d’en faire moins, de ne pas faire tout ce qu’on nous demande. En restrei­gnant les tâches, on se concentre sur celles qui ont le plus de valeurs. Ça veut aussi dire accep­ter que mes inter­lo­cu­teurs ne fassent pas tout ce que j’ima­gine, leur donner le pouvoir de faire des arbi­trages, leur donner les objec­tifs et leur expliquer la stra­té­gie pour qu’ils fassent ses arbi­trages de façon auto­no­me… et leur faire confiance sans leur repro­cher ce qu’ils n’ont pas fait.

Dès qu’on en demande « plus », on a perdu parce qu’on se refuse à ce que chaque employé choi­sisse ce sur quoi il se concentre et aban­donne le reste.

L’autre point d’en faire moins c’est en faire litté­ra­le­ment moins. Sur les métiers de produc­tion infor­ma­tique j’ai vu une diffé­rence de produc­tion assez faible entre un déve­lop­peur à 80% et un à 100%. J’ai vu une grosse diffé­rence entre quelqu’un de reposé et quelqu’un qui ne l’est pas.

Travailler moins pour travailler mieux n’est pas qu’une illu­sion.

This is where going home comes in. Go home!

Et puis bon, allon­ger les heures c’est sortir de la valeur en grigno­tant sur le capi­tal humain. Seul problème : C’est ce que vous avez de plus cher, avant même votre temps dispo­nible.

Burnout is a real problem

Un jour j’en parle­rai. J’ai mis des années à récu­pé­rer et j’en garde­rai certai­ne­ment des séquelles physiques comme psycho­lo­giques à vie.

Rien ne peut le justi­fier.

Si je pouvais lancer la semaine de 30 heures en 5x 6 heures, je le ferais.

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.

Extrait de The Mana­ger’s Path

You proba­bly have tech leads repor­ting to you now, though, and juggling the work of directly mana­ging more than three or four people with the process of unders­tan­ding details about what’s happe­ning across a couple of teams proba­bly means one impor­tant thing: you’re not writing (much, any, produc­tion) code.

Je suis toujours impres­sionné par les CTO qui disent être encore hands on de façon signi­fi­ca­tive. Parfois je me demande si nous faisons le même métier.

J’ai alterné entre les postes de lead tech et de mana­ger, parfois dans la même boite avec le même titre. En pratique je ne sais pas à la fois me concen­trer sur un projet précis en contri­bu­tion signi­fi­ca­tive, et à la fois avoir le recul pour gérer les inter­ac­tions entre plusieurs équipes plus la vision opéra­tion­nelle du futur.

I took pains to make sure that we called out the fact that engi­nee­ring direc­tors would not neces­sa­rily be writing code every day, because I believe that it is very diffi­cult for a person respon­sible for hands-on mana­ge­ment of multiple teams to write code.

Sur une seule équipe qui travaille sur le même projet, oui. Sur plusieurs équipes qui ont leur propre feuille de route, je ne sais pas faire. Je ne suis même pas certain de le conseiller.

Je mets la limite proba­ble­ment au même niveau que l’au­teure : quand on commence à mana­ger des mana­gers, et ne plus être impliqué person­nel­le­ment dans la réali­sa­tion des diffé­rents projets et des diffé­rentes déci­sions.

The risk of going hands-off is greatly ampli­fied if you don’t spend enough time coding before moving into this role to get your­self deeply, fluently comfor­table with at least one program­ming language.

I advo­cate stron­gly that you spend the time to gain mastery of program­ming before moving into mana­ge­ment.

Ça peut fonc­tion­ner, mais je l’ai plus souvent vu échouer que réus­sir. Ceux qui s’orientent trop rapi­de­ment sont souvent ceux qui ont monté leur propre entre­prise. Il est diffi­cile de reve­nir en arrière ensuite pour reprendre la partie tech­nique dont l’ex­pé­rience manque.

Là aussi, tant qu’on est au niveau d’une équipe ça fonc­tionne. C’est le palier de direc­tion (mana­ger de mana­ger) qui trace la fron­tière.

Finally, even if you don’t intend to write much code, I stron­gly advise you to keep at least a solid half-day once a week comple­tely free from meetings or other obli­ga­tions, and try to use this time at least partially on some crea­tive pursuit.

Et c’est là dessus que je rédige ce billet. Pour moi c’est très diffé­rent de ce qui précède. Il faut rester tech­nique, parler archi­tec­ture, revue de code, faire soi-même parfois des fix ou des outils, lire et rédi­ger, que ce soit pro ou perso (et c’est de mon expé­rience plus facile de le faire côté perso) mais on ne peut plus aussi faci­le­ment s’im­pliquer dans l’opé­ra­tion­nel des projets.

J’irai même jusqu’à dire que plus on avance en mana­ge­ment et en direc­tion, plus on doit éviter d’in­ter­ve­nir dans ce qui est néces­saire et plus on doit agir sur l’au­tour (hors des road­map, hors de la produc­tion). Les scripts d’in­té­gra­tion conti­nue, les explo­ra­tions de perfor­mance, les preuves de concept, l’ex­plo­ra­tion d’API ou de langages, sont proba­ble­ment des meilleurs candi­dats.

Extrait de The Mana­ger’s Path

if you fill the sche­dule to 100% with feature deve­lop­ment, expect that the feature deve­lop­ment will quickly slow down as a result of this over­sche­du­ling »

Juste avant, l’au­teure parle de ne comp­ter que 10 semaines et non 13 par trimestre, pour prendre en compte les congés, l’on­boar­ding des nouveaux employés, les indis­po­ni­bi­li­tés de produc­tion, etc. C’est proba­ble­ment plus en France vu le nombre de congés.

Entre les deux elle parle de 20 % de temps pour les travaux de soutien tech­nique comme les tests, le nettoyage des codes histo­riques et les migra­tions.

Ce n’est pas précisé ici mais je me rappelle aussi ce que montre Shape-Up avec 2 semaines de cool-down pour 6 semaines de produc­tion.

De mon côté j’at­tends un focus sur la road­map de l’ordre de 70 à 80 % et c’est déjà beau­coup. Je me rappelle mes années à Yahoo! où la plani­fi­ca­tion se faisaient avec une réfé­rence de 4 heures de pleine effi­ca­cité par jour. C’était aussi ma première boite où il était accep­table de dire « je n’ai pas réussi à avan­cer hier, j’en suis au même point » sans que ça ne soit honteux.

Ce n’est pas tant que le reste n’est pas travaillé, c’est qu’il compte pour les la construc­tion des outils, les inves­tis­se­ments tech­niques, les échanges, les forma­tions, les périodes où on est moins voire peu produc­tif. C’est souvent de ces temps là que viennent tous les travaux annexes qui peuvent chan­ger le fonc­tion­ne­ment de l’équipe ou de l’en­tre­prise, et qui réduisent les frus­tra­tions au jour le jour.

Ce n’est pas tant qu’il faille doubler les esti­ma­tions des déve­lop­peurs (qui est plus loin une pratique consi­dé­rée comme posi­tive par l’au­teure), c’est qu’il faut arrê­ter de jouer au tétris avec les road­map et les esti­ma­tions. Prévoir une road­map qui occupe 50 % du temps de travail est plutôt une bonne cible.

You will almost certainly have occa­sio­nal dead­lines, either goal dates that you’ve set or goal dates that came down from on high. The only way to achieve these goals is to cut scope at the end of the project.

J’ai un malaise en lisant et je classe ça dans les compor­te­ment toxiques. Je crois que c’est la première fois dans ma lecture.

Je suis déjà gêné par le mélange entre la dead­line et le goad date. Il y a parfois des dates limites. J’ai travaillé sur un site d’ac­tua­li­tés spor­tives et on n’y a pas le loisir de déca­ler l’évé­ne­ment des Jeux Olym­piques. La date limite peut-être n’im­porte quoi d’ex­té­rieur et d’im­pos­sible ou très coûteux à déca­ler mais pas un objec­tif venu d’en haut. Si l’es­poir d’en haut n’est pas tenable alors c’est en haut qu’il faut chan­ger quelque chose.

La pratique qui consiste à passer en mode urgence quand la date approche c’est le pire possible pour la qualité, autant tech­nique que vis à vis de l’uti­li­sa­teur

Si on coupe le péri­mètre projet, c’est pour livrer rapi­de­ment, itéra­ti­ve­ment, simple­ment, et on devrait le faire tout le temps, pas pour tenir une date arti­fi­cielle qui n’est qu’un objec­tif de plan.

Si on prend des raccour­cis tech­niques c’est pour livrer plus rapi­de­ment, itéra­ti­ve­ment, et on devrait le faire souvent, pas pour tenir une date arti­fi­cielle qui n’est qu’un objec­tif de plan.

Pour les deux cas, ça veut dire aller enri­chir avec d’autres itéra­tions ou nettoyages derrière.

Je tiens beau­coup au mani­feste agile et à son « Respon­ding to change over follo­wing a plan ».

---

J’ai trop souvent de malaises quand je lis les chapitres de gestion de projet ailleurs que dans des livres qui parlent d’agi­lité. Je sens vrai­ment deux mondes diffé­rents qui s’af­frontent.

Extraits de The Mana­ger’s Path

The real goal here is psycho­lo­gi­cal safety

On met beau­coup de choses derrière ce terme mais c’est un des ensei­gne­ments majeurs de ceux qui ont mené de vraies études pour trou­ver des corré­la­tions dans les équipes qui fonc­tionnent bien.

La corré­la­tion ne se situe pas sur le niveau d’étude, l’ex­pé­rience, le salaire ou même la compé­tence. La corré­la­tion première c’est le senti­ment de sécu­rité.

On débloque l’ini­tia­tive mais aussi la commu­ni­ca­tion, la capa­cité à s’im­pliquer, à propo­ser, à faire au mieux sans perdre de temps inutile et sans se rete­nir.

Mon mot d’ordre chéri reste la commu­ni­ca­tion et l’ex­pli­cite mais c’est pour moi très lié : On ne peut pas être en sécu­rité psycho­lo­gique s’il existe des non-dits, des inter­pré­ta­tions ou des zones de flou. Inver­se­ment, tout ce qui est dit clai­re­ment sécu­rise.

Teams that are friendly are happier, gel faster, and tend to produce better results. I mean, do you really want to go to work every day with a bunch of people you hate?

Il ne s’agit pas d’être amis, même si ça faci­lite évidem­ment, mais d’être dans un envi­ron­ne­ment amical.

La légende qu’on peut faire juste son boulot sans s’im­pliquer émotion­nel­le­ment, sans frivo­lité ni discus­sions de machine à café, qu’on ne demande pas aux sala­riés de se faire des amis mais d’ef­fec­tuer correc­te­ment leur travail, ne s’est jamais confir­mée devant moi.

Le moindre grain de sable qui vient réduire le côté sympa ou l’en­vie de se retrou­ver ensemble pour travailler ensemble se voit immé­dia­te­ment sur le travail, autant la qualité que la produc­ti­vité, mais aussi sur l’en­vie de rester, sur l’ini­tia­tive, sur l’ef­fort qu’on doit mettre dans tout chan­ge­ment.

Certains parlent d’ADN et de valeurs pour s’as­su­rer que les sala­riés s’en­ten­dront. Je ne sais pas si ça se réduit à ça, mais il suffit d’un membre d’équipe qui refuse d’en­trer dans le fonc­tion­ne­ment collec­tif amical pour tuer toute une équipe.

Il y a certai­ne­ment des emplois qu’on peut faire froi­de­ment mais proba­ble­ment pas la parti­ci­pa­tion à une équipe R&D.

Si ça ne colle pas, mieux vaut chan­ger la personne d’équipe, voire l’iso­ler en élec­tron libre hors des équipes, ou en dernier recours envi­sa­ger ensemble une sépa­ra­tion.

One variant of the toxic employee is the brilliant jerk, who, as we discus­sed earlier, produces indi­vi­dually outsi­zed results, but is so ego-driven that she creates a mixture of fear and dislike in almost everyone around her.

J’ai vu ce profil dans la plupart des équipes que j’ai croisé et j’ai tendance à croire qu’il est fréquent dans le milieu tech­nique. Il y a une légende qu’on n’est pas là pour perdre son temps et que l’ef­fi­ca­cité ou la compé­tence est la pièce maitresse qui va rendre tout le monde perti­nent.

On parlait de sécu­rité psycho­lo­gique et d’équipe amicale, on est en plein dans le contre-exemple.

Je n’ai pas de solu­tion géné­rique au problème si ce n’est la même que les deux plus haut :

• Inter­ve­nir en public à tout dérap­page qui pour­rait faire peur aux autres
• Sortir ces personnes des équipes pour les canton­ner ailleurs

Ça ne résout pas le problème en soi mais ça permet au moins de l’iso­ler pour le trai­ter sans qu’il ne se propage entre temps.

When a person is beha­ving badly in a way that is having a visible impact on the team, and a way you don’t want your culture to mimic, you need to say some­thing in the moment to make the stan­dard clear.

« in the moment » est à prendre à mon avis au sens litté­ral et ça veut dire en public, en présence. Si ce n’est pas vous ça doit être un autre mana­ger, ou en réalité peu importe qui qui assume la chose et qui sait avoir le soutien du mana­ge­ment pour dire « stop » (et en théo­rie tout le monde devrait sentir avoir le soutien du mana­ge­ment pour ça).

Il faut montrer que les mauvaises atti­tudes n’ont pas de soutien, qu’il y a une volonté de proté­ger ceux qui en ont besoin et d’ins­tau­rer une autre culture.

Pas de faux semblant : L’équi­libre n’est pas toujours simple à trou­ver parce qu’in­ter­ve­nir pour dire « stop » va frois­ser, d’au­tant plus si on refuse d’en­trer dans l’ar­gu­men­ta­tion sur qui a raison et si l’in­ter­ven­tion est perti­nente (ça ça doit se faire après, à froid, en face à face). L’in­ter­ven­tion en protec­tion sera parfois vue comme une agres­sion en sens inverse par celui qui est visé. Ça peut encou­ra­ger un compor­te­ment de combat, ou un renfer­me­ment.

Je suis preneur de savoir comment vous trai­tez ça.

Your first goal is to protect your team as a whole, the second is to protect each indi­vi­dual on the team, and your last prio­rity is protec­ting your­self.

Je suis de plus en plus mitigé là dessus, au point de peut-être être même en désac­cord.

J’ai un profil sacri­fi­ciel. C’est comme ça que je vis au jour le jour, comme ça que je suis, person­nel­le­ment et profes­sion­nel­le­ment. Je le demande aux mana­gers dans une certaine mesure. Leur rôle est de prendre sur eux pour que l’équipe fonc­tionne. Mon rôle est de prendre sur moi pour que les équipes fonc­tionnent.

Pour autant, me proté­ger moi-même ou un mana­ger est dans une certaine mesure plus prio­ri­taire que proté­ger un autre. Si je ne défend pas ce qui me minore, je peux montrer le mauvais exemple et surtout je peux mino­rer ma propre posi­tion. Sur la durée mino­rer mon rôle et ma posi­tion c’est m’em­pê­cher d’in­ter­ve­nir pour chan­ger les choses et proté­ger les autres.

La cita­tion me va bien dans l’idéal, surtout si les équipes fonc­tionnent déjà bien. Elle m’ap­pa­rait plus problé­ma­tique dans un contexte où il faut faire chan­ger les fonc­tion­ne­ments. Là, le mana­ge­ment et la direc­tion doivent être proté­gés avec une bonne prio­rité.

Whate­ver the cause, this person disrupts team cohe­sion because he isn’t being colla­bo­ra­tive with the rest of his team­mates; he doesn’t feel safe sharing his work in progress, and his fear often sets an example for the rest of the team.

C’est aussi pour ça que je parle d’iso­ler ceux qui ne s’in­tègrent pas, faute d’ar­ri­ver à provoquer le chan­ge­ment (essayons d’abord ça). La peur, la défiance, l’agres­si­vité, se diffusent plus faci­le­ment que leurs oppo­sés et ça fait son chemin incons­ciem­ment même chez ceux qui pensent avoir le recul suffi­sant.

the person who hides infor­ma­tion from you, from his team­mates, from his product mana­ger. […] The person who doesn’t want to go through code review and who doesn’t ask for design review on big projects. […] Whate­ver the cause, this person disrupts team cohe­sion because he isn’t being colla­bo­ra­tive with the rest of his team­mates; he doesn’t feel safe sharing his work in progress, and his fear often sets an example for the rest of the team. 

La conclu­sion de tout ça pour moi c’est de ne pas lais­ser pourir la situa­tion quand une personne n’est plus impliquée de la même façon, que ça appa­raisse en agres­si­vité, en manque de colla­bo­ra­tion, en defiance, en manque de trans­pa­rence, en manque d’ini­tia­tives, ou simple­ment en se mettant en retrait du groupe.

Si ça peut sembler mineur pour peu que le travail soit fait correc­te­ment, ça ne l’est pas : Il y a une influence, qui peut mettre long­temps à être renver­sée.

Je reprends mes notes de lectures de The Mana­ger’s Path.

It’s hard to know what’s going to happen next on Jason’s team because instead of guiding the team, he’s having the team guide itself.

Ce chapitre fait un peu mal. Je sais que je me suis pris beau­coup de murs dans mes premières années de mana­ge­ment à cause de ça, et que j’ai toujours une tendance à partir un peu là dedans quand je ne me surveille pas.

L’équi­libre entre le lais­ser faire et le trop direc­tif n’est pas une évidence, et on peut arri­ver à être à la fois dans le lais­ser faire et dans le trop direc­tif pour peu qu’on se foca­lise sur les mauvais sujets.

Le problème fonc­tionne aussi pour les non mana­gers. Si vous voulez avoir l’au­to­no­mie, ça néces­site de prendre en compte les enjeux trans­ver­saux et de s’im­pliquer même là où vous n’êtes pas à l’aise.

It’s no surprise to anyone that they vote to drop Char­les’s pet project — no surprise, that is, to anyone except Charles, who has never heard anything about this from Jason and who figu­red he was doing the right thing

La leçon apprise de l’époque :

• Dire ce qui ne va pas, quand bien même c’est diffi­cile à dire ou diffi­cile à entendre, surtout si c’est diffi­cile à dire ou diffi­cile à entendre.
• Deman­der même quand ça ne plait pas, quitte à impo­ser quand c’est néces­saire.

En ména­geant les suscep­ti­bi­li­tés on crée de la dette humaine qui s’ac­cu­mule. Assez vite, les petits problèmes qu’on a cher­ché à éviter deviennent un problème d’or­ga­ni­sa­tion et de culture qui lui est incon­tour­nable, bien plus complexe que la somme des petites suscep­ti­bi­li­tés.

Don’t rely exclu­si­vely on consen­sus or voting. Consen­sus can appear morally autho­ri­ta­tive, but that assumes that everyone invol­ved in the voting process is impar­tial, has an equal stake in the various outcomes, and has equal know­ledge of the context.

Aujourd’­hui je me base sur le « faire confiance » pour ce point.

Je l’ai fréquem­ment entre les déve­lop­peurs et les respon­sables produit, avec les premiers qui aime­raient être impliqués sur toutes les déci­sions mais sans pour autant faire le travail amont d’in­ter­view utili­sa­teur, de compa­rai­son avec la concur­rence, de réflexion stra­té­gique, de coor­di­na­tion marke­ting, etc.

Je l’ai aussi entre les déve­lop­peurs et le mana­ge­ment, sur les ques­tions d’évo­lu­tion, d’éva­lua­tion, sur les règles de travail de tous les jours.

Le fond c’est d’im­pliquer, collec­ter les retours, comprendre et prendre en compte les argu­ments ou infor­ma­tions qui manquaient au déci­deur, mais lais­ser pour autant la déci­sion au déci­deur. C’est lui qui a tout le contexte, qui passe du temps à soupe­ser et équi­li­brer les enjeux. La personne externe qui a un avis sans avoir fait ce travail n’a qu’un avis partiel et mal informé, et n’a pas de raison de peser dans la déci­sion elle-même.

Faites juste confiance à vos collègues pour vous avoir écouté et prendre une bonne déci­sion, même si ce n’est pas la votre.