Catégorie : Management

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.

Extraits de The Mana­ger’s Path

You can tell some­thing is wrong, but you’re not enti­rely sure what it is.

Mon dieu ! Quelqu’un m’es­pionne !

A common example [of a team not ship­ping because their tools and processes] is that your team only tries to release changes to produc­tion once a week or less.

J’aime cette phrase parce qu’on la lit puis… hein ? quoi ?

Livrer toutes les semaines n’est pas un objec­tif de réus­site, c’est une marque de dysfonc­tion faute de livrer assez fréquem­ment.

J’ai tendance à accep­ter la semaine et me battre contre les cycles qui font un mois. J’ai quand même vécu une vraie révo­lu­tion quand une équipe est passée d’un cycle de 2 à 4 semaines à une 20aine de livrai­sons par jour.

Ça ne change pas que la fréquence, ça change la façon de travailler, de tester, de penser. Pour reprendre la première cita­tion, j’ai du mal à trou­ver du concret pour expliquer la diffé­rence, mais elle était visible à l’œil nu en terme d’ef­fi­ca­cité et de cadence.

---

You know, that person you think can’t be repla­ced because he’s just so produc­tive and so smart, but who isn’t a team player and makes everyone around him unhappy.

La mode est au terme de toxi­cité. Il est peut-être un peu fort mais le fond est bien celui là. Aucun membre d’équipe ne sera assez bon pour compen­ser la néga­ti­vité qu’il propage autour de lui.

Je dis géné­ra­le­ment que pour progres­ser il est plus facile de faire progres­ser de 5% les 6 personnes autour de soi que d’amé­lio­rer sa propre produc­ti­vité de 30%.

A less criti­cal version of this situa­tion is the person who just stirs up drama, who dwells on nega­tive expe­riences, or who spends a bit too much time on gossip and playing games of us-against-them.

C’est malheu­reu­se­ment vrai aussi dans l’autre sens. Il est très facile de dégra­der de 5% les personnes autour de soi. Dès qu’il y a néga­ti­vité, défiance, mauvaise commu­ni­ca­tion, confron­ta­tion, c’est un signal d’ur­gence.

Pas besoin de mauvaise inten­tion. Une personne intrin­sèque­ment néga­tive est immé­dia­te­ment un problème, même malgré elle. Ça doit mener à un stop ou un plan d’amé­lio­ra­tion. Si c’est aussi le senior ou la personne clef, tant pis. Un départ sera le moindre mal.

but be aware that your mana­ger may actually have an even harder time dealing with the brilliant jerk than you do. She isn’t seeing the imme­diate impact on team dyna­mics; she’s just seeing someone who gets things done. »

Make it clear to him that the beha­vior has to change, bring clear examples, and provide correc­tive feed­back quickly after things happen.

Et honnê­te­ment ce n’est pas facile de jouer le parter­na­liste en expli­ci­tant que telle critique est malve­nue, que là il aurait fallu sourire plutôt que souf­fler. Ce sont des signaux faibles et cher­cher à les corri­ger peut passer pour une volonté de mettre sous silence les critiques, ou de deman­der à être faux dans les inter­ac­tions.

La seule recom­man­da­tion que j’ai est toujours la même, et donnée par l’au­teure : Être expli­cite, commen­cer par dire que ça ne va pas et que ça doit chan­ger.

Some­times the nega­tive person is just unhappy and the best thing to do is to help him leave the team on good terms; you must be prepa­red for this outcome. »

Pour l’anec­dote, j’ai déjà rencon­tré quelqu’un de super, de très compé­tent, de sympa, qui est main­te­nant un lead tech­nique reconnu dans une boite qui elle aussi est recon­nue pour le bon fonc­tion­ne­ment de ses équipes tech­niques.

Quand je l’ai recruté ça n’a simple­ment pas fonc­tionné, proba­ble­ment en partie parce que je lui ai mis trop d’étoiles dans les yeux sur ce que serait l’am­biance star­tup lors du recru­te­ment. Il était mal, ça ne nous allait pas. On s’est séparé en bons termes. L’équipe a nette­ment amélioré sa produc­ti­vité après son départ, malgré la personne en moins dans les effec­tifs.

Depuis je ne sous-estime plus l’in­fluence que peut avoir de la néga­ti­vité.

Be care­ful that vocally nega­tive people don’t stay in that mind­set on your team for long. The kind of toxic drama that is crea­ted by these energy vampires is hard for even the best mana­ger to combat. The best defense is a good offense in this case, and quick action is essen­tial. »

Dans mon cas ça c’est arrêté immé­dia­te­ment après le départ. Dans d’autres ça va rester long­temps parce que la néga­ti­vité est conta­gieuse, parce que ça a pu casser la confiance, ou la moti­va­tion, ou l’es­prit d’équi­pe… autant de choses diffi­ciles à recons­truire ensuite. Ça peut aussi mener à d’autres départs, de personnes qui en consé­quence n’ont pas de raison de rester.

---

Crunch periods will happen, but there is no reason they should happen frequently.

But they’ll remem­ber whether their mana­ger was with them during the stress­ful period, or off somew­here else, doing her own thing.

Extrait de The Mana­ger’s Path

You may only have the autho­rity to guide deci­sions rather than dictate them

Je suis de ceux qui consi­dère qu’on ne donne pas un rôle, on ne fait que acter que la personne agit au rôle en ques­tion.

L’étape la plus diffi­cile pour les déve­lop­peurs seniors, qu’ils veulent aller dans la branche mana­ge­ment ou dans rester en contri­bu­tion indi­vi­duelle, c’est le fait d’être respon­sable sans déci­der eux-mêmes.

Il y a une vision fantas­mée de la hiérar­chie mais en réalité c’est un peu pareil à tous les niveaux. Dans ce que je veux faire, parfois ça finit par fonc­tion­ner en indiquant la bonne direc­tion, en répé­tant, en donnant des objec­tifs. Parfois ça ne fonc­tionne pas et j’aban­donne.

En réalité je ne décide pas vrai­ment. Même quand je le fais, ça ne suit pas toujours. Le travail c’est juste­ment faire avan­cer tout le monde dans le même sens, pas décré­ter des choses dans son coin.

you’ll still be judged by how well those deci­sions turn out

Et pour­tant on reste comp­table du résul­tat. Quoi qu’il se passe, que je le décide ou non, que l’équipe suive ma vision ou persiste dans une autre, c’est moi qui suis respon­sable vis à vis de l’ex­té­rieur.

C’est à moi de faire en sorte que l’équipe aille dans le bon sens, d’ex­pliquer comment et pourquoi, de convaincre, de guider et de former. Je peux éven­tuel­le­ment repro­cher les déci­sions à ceux qui les ont prises, mais pas m’en reti­rer la respon­sa­bi­lité.

Vouloir prendre un poste de mana­ge­ment c’est aussi ça : Savoir se sentir respon­sable, impliqué, tout en sachant qu’en fait on peut toujours déci­der ce qu’on veut sans que ça n’ar­rive dans les faits (sauf à avoir une hiérar­chie mili­taire, mais ça ne me semble pas adapté à des équipes tech­niques dans le logi­ciel).

Create a Data-Driven Team Culture

Je balbu­tie encore, parce que j’ai du mal moi-même à trou­ver les bonnes métriques à mettre en œuvre. Je l’ex­plique un peu quand je parle d’objec­tifs ici. J’ai trop vu ces systèmes perver­tis ou mal utili­sés pour les aimer.

the regu­lar process retros­pec­tive has a lot of value for detec­ting patterns and forcing a recko­ning with the outcome of deci­sions

On parle agilité et ça sort peut être du cadre mais il y a quatre rituels que je ne saute­rai pas, dans cet ordre d’im­por­tance :

1. La rétros­pec­tive
2. Le 1–1 avec le mana­ger
3. Le daily meeting avec l’équipe
4. Les kick-off pour donner du sens et lancer les projets

Si je place la rétros­pec­tive avant tout le reste c’est que c’est l’ou­til d’amé­lio­ra­tion. Peu importe où on est, le prin­ci­pal est de s’amé­lioré.

La diffi­culté prin­ci­pale que j’ai rencon­tré avec le temps ce sont les rétros­pec­tives qui s’épuisent, avec pas grand chose qui sort et peu ou pas d’ac­tions prises. Une solu­tion possible c’est l’ani­ma­tion, le chan­ge­ment de déroulé sur la réunion, ou le leader­ship tour­nant sur la réunion voire l’in­ter­ven­tion d’un tiers à l’équipe.

Extrait de The Mana­ger’s Path

Many pieces of mana­ge­ment advice tell new mana­gers that part of their job, if they are effec­tive, is to be a shield

Je n’avais jamais entendu parler de bouclier. Je n’y crois guère, et visi­ble­ment l’au­teure non plus. On ne peut isoler tota­le­ment l’équipe au point que ce qui se passe ne les attein­dra pas. Même si on pouvait, je doute que ce soit une bonne idée d’avoir l’équipe dans sa tour d’ivoire qui ne partage que du pur effi­cace avec l’ex­té­rieur.

Mon membre d’équipe idéal n’est pas un robot, ou pas pour les types de métiers que je gère. La compé­tence humaine (compré­hen­sion, commu­ni­ca­tion, intui­tion, initia­tive, juge­ment) est essen­tielle.

Some­times it’s appro­priate to let some of the stress through to the team. The goal is not to stress them out, but to help them get context into what they’re dealing with.

Je ne parle pas de bouclier mais j’ai souvent fait tampon. J’ai parfois décrit mon poste ainsi. J’ai fait tampon vis à vis de direc­tions toxiques, de prési­dents qui vivaient en mettant la pres­sion ou le blâme.

Il ne s’agit pas alors d’iso­ler l’équipe mais d’amor­tir ce qu’il se passe.

Pour autant c’est une mauvaise chose. Je l’ai fait parce que l’en­vi­ron­ne­ment était struc­tu­rel­le­ment problé­ma­tique. Avec le recul peut-être que j’au­rais simple­ment dû partir, ou essayer de mettre un coup de pied dans la four­mi­lière un peu plus fort.

Faire tampon est usant et l’ana­lo­gie finie par être vraie aussi au niveau de l’is­sue. Au bout d’un moment vous serez usés et ne pour­rez plus servir de tampon, voire plus servir du tout.

humans usually need some sort of context into why these goals have been set, and thereby into what problems they’re working to solve

L’au­teure arrive par là en consi­dé­rant que la pres­sion ou ce qu’il se passe autour est un contexte qu’il est impor­tant de connaitre. Je prends la cita­tion encore plus large.

Plus on respon­sa­bi­lise les équipes et plus il faut amener le contexte et le pourquoi. Le quoi c’est le boulot de l’équipe. Le contexte c’est ce qui leur permet de prendre les bonnes déci­sions, d’adap­ter au fur et à mesure du déroulé, et de se sentir impliqués.

Extrait de The Mana­ger’s Path

Don’t unde­res­ti­mate the value of your tech­ni­cal skills as you work to become a success­ful engi­nee­ring mana­ger.

Je me suis toujours posé cette ques­tion et je n’ai toujours pas de réponse franche. Oui, je pense qu’il faut avoir des compé­tences tech­niques mais j’ai aussi vu des équipes enca­drées par des personnes plus orien­tées scrum master et ça fonc­tion­nait aussi.

Il faut comprendre le système, avoir des notions d’ar­chi­tec­ture. Au-delà… j’ai vu des succès comme des échecs avec des personnes forte­ment tech­niques et des succès comme des échecs avec des personnes assez faibles tech­nique­ment.

Toutes celles qui ont réussi avaient par contre un sens busi­ness et un sens humain déve­loppé, ainsi que la compré­hen­sion que les enjeux sont sur la commu­ni­ca­tion et la culture.

a criti­cal part of complex project mana­ge­ment is unders­tan­ding the pieces of the system well enough to deter­mine the best path to imple­men­ta­tion. The more you unders­tand the code in the system, the easier deter­mi­ning this path will be

S’il faut de la tech­nique, l’ar­chi­tec­ture des systèmes est à mon sens plus impor­tante que la syntaxe d’un langage ou que l’ex­per­tise sur le code lui-même.

Why bother writing any code if all you’re doing is small stuff? The answer is that you need to stay enough in the code to see where the bottle­necks and process problems are.

Régu­liè­re­ment il faut descendre dans la mine et se mettre dans l’équipe. L’objec­tif n’est pas forcé­ment de réel­le­ment produire mais de comprendre, et de s’as­su­rer qu’on n’est pas hors sol.

En tant que personne un peu exté­rieure, on est peut-être aussi plus sensible à tout ce qui traine au milieu du chemin et auquel le reste de l’équipe s’est habi­tué ou rési­gné.

L’été est parfait pour cela, si on peut mettre tempo­rai­re­ment les enjeux projet en veilleuse.

Extrait de The Mana­ger’s Path

mana­ging a team is more than just doing the job of mana­ging the indi­vi­duals.

J’ai commencé par prendre cette cita­tion pour écrire que je ne voyais pas grande diffé­rence puis, le temps que j’écrive, je me range du côté de l’au­teure.

Avan­cer en équipe c’est prendre la même direc­tion, même si indi­vi­duel­le­ment on aurait pu prendre des direc­tions diffé­rentes.

Avan­cer en équipe c’est non seule­ment savoir avan­cer mais ne pas ralen­tir les autres, voire savoir les épau­ler.

Faire avan­cer l’équipe au mieux c’est parfois redi­ri­ger une personne qui avance mais pas à la bonne vitesse pour le reste du groupe.

J’ou­blie plein de cas mais il y a toute une dimen­sion « groupe » et pilo­tage qu’on ne voit pas avant d’avoir au moins trois personnes.

The engi­nee­ring lead will spend less time writing code, but they still engage in small tech­ni­cal deli­ve­rables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold respon­si­bi­lity for iden­ti­fying bottle­necks in the process and road­blocks to success for their team and clea­ring these road­blocks.

Je trouve cette cita­tion inté­res­sante au-delà de l’en­fonçage de porte ouverte qui est de dire qu’on va coder moins.

L’au­teur appuie sur un point qu’on voit moins et qui pose problème à ceux qui s’ima­ginent que leur exper­tise va servir leur leader­ship : Le lead d’équipe non seule­ment code moins mais se retrouve à le faire sur des petites tâches hors du chemin critique. Le cœur du projet et de l’ar­chi­tec­ture est pour les autres, de même que les ques­tions les plus poin­tues.

Son vrai rôle est de s’as­su­rer que l’équipe avance, et débloquer les autres ou travailler en amont à paver le chemin est plus impor­tant que pous­ser le projet lui-même.

Corri­ger des petites erreurs qui trainent, amélio­rer les outils internes, enri­chir le dispo­si­tif d’in­té­gra­tion conti­nue, sont toutes des tâches faciles à prendre pour le lead. Elles sont à la fois petites, hors du chemin critique, et de nature de faci­li­ter la vie de l’équipe pour qu’elle se concentre sur le projet.

Extrait de The Mana­ger’s Path

One of the hardest things that any mana­ger must do is to fire someone for under­per­for­mance.

Je ne le souhaite évidem­ment à personne, ni du point de vue du mana­ger ni du point de vue du sala­rié qui doit partir, mais entrer dans un proces­sus qui peut mener à un licen­cie­ment ou une fin de période d’es­sai est un peu ce qui me permet de dire que quelqu’un a passé la première étape de mana­ge­ment.

Avec le temps il est peu probable que ça n’ar­rive jamais, sauf à avoir une équipe excep­tion­nelle avec zéro crois­sance. Ça peut être sinon le symp­tôme d’un évite­ment.

Upon hearing that someone is under­per­for­ming, many compa­nies will have you write the person a docu­ment called a perfor­mance impro­ve­ment plan.

On reste dans le mantra « tout doit être expli­cite ». S’il y a problème, on le dit. Si la persis­tance du problème peut mener à un départ, on le dit. S’il y a des choses à chan­ger, on dit quoi.

Le plan d’amé­lio­ra­tion des perfor­mances ce n’est fina­le­ment que ça, dire ce qui ne va pas, ce qui doit être amélioré, et à quel moment l’ab­sence d’amé­lio­ra­tion va mener à des choix doulou­reux de la part du mana­ge­ment.

Parfois ça fonc­tionne, parfois non, mais au moins on aura mis toutes les chances de notre côté pour que ce soit le cas.

Le côté formel du plan d’amé­lio­ra­tion, avec lettre dont on accuse récep­tion et impli­ca­tion du dépar­te­ment RH, permet aussi de rendre les choses formelles. Ça sert pour rendre la procé­dure impor­tante aux yeux du salai­rés et qu’on ne reste pas sur une demie-mesure. Ça sert aussi en cas de non-amélio­ra­tion, à ce que l’is­sue ne soit une surprise pour personne, donc non contes­tée. Ça sert enfin, dans le cas d’une contes­ta­tion, à docu­men­ter ce qui pose problème, et à montrer que les tenta­tives ont eu lieu, que l’ar­rêt du contrat était bien le dernier recours.

Les feed­backs écrits régu­liers servent aussi d’élé­ments dans le même sens : Ils contri­buent à ce que ça fonc­tionne, et servent à montrer ce qui a été mis en œuvre en cas de litige futur.

but often the plan is writ­ten in such a way that the person can’t possi­bly hope to achieve the goals in the allot­ted time, and it’s just a gene­rous way of giving someone time to look for another job before being fired.

Je ne l’ai honnê­te­ment jamais vécu, ni d’un côté ni de l’autre, et je trou­ve­rais ça assez malsain. Mieux vaut dire les choses expli­ci­te­ment. En France la rupture conven­tion­nelle permet de sortir la tête par le haut et d’un commun accord, et ça me parait plus franc et honnête que commen­cer par un plan d’amé­lio­ra­tion dont on connait déjà l’is­sue, ou dont on ne voudrait pas qu’il réus­sisse.

Mon expé­rience me fait plutôt croire qu’on a inté­rêt à se dire au-revoir sur une période courte, à ne pas faire exécu­ter les longs préavis français. Ici l’au­teure est dans une culture anglo-saxone et les durées ne sont pas les mêmes, mais je ne vois l’in­té­rêt pour personne à faire durer la chose en créant un temps d’amé­lio­ra­tion alors que l’is­sue est déjà connue. Ça risque­rait de plus d’être jugé comme une infrac­tion aux droits du sala­rié (on ne peut plus prendre prétexte de la mauvaise perfor­mance vis à vis des objec­tifs puisque la déci­sion était connue avant la période censée véri­fier si on atteint les objec­tifs).

Au-delà, fixer des objec­tifs inat­tei­gnables c’est avoir déjà pris sa déci­sion. Une déci­sion déjà prise avec l’im­pos­si­bi­lité pour le sala­rié de corri­ger son travail, c’est proba­ble­ment souvent d’abord une faute du mana­ge­ment qui aurait du iden­ti­fier le problème plus tôt, quand il était encore temps d’y remé­dier.

One of the basic rules of mana­ge­ment is the rule of no surprises, parti­cu­larly nega­tive ones. You need to unders­tand what a person is suppo­sed to be giving you, and if that isn’t happe­ning, make it clear to her early and often that she is not meeting expec­ta­tions.

Toujours, quel que soit le sujet et le chapitre : Être expli­cite, dire les choses au plus tôt et sans détour.

Dans l’hy­po­thèse plus construc­tive que la précé­dente, le dire tôt permet au sala­rié de travailler à corri­ger son travail ou son atti­tude, et résoudre le problème.

A final warning: don’t put anyone on a plan whom you wouldn’t be happy to lose. Most smart employees will take this formal warning as a sign that the orga­ni­za­tion is not a good fit for them, and leave as quickly as possible.

J’ai vécu la poli­tique d’en­tre­prise qui fixe un quota de 30% de personnes à mettre en plan d’amé­lio­ra­tion chaque période. C’est contre-produc­tif, puni­tif, mais ça coupe aussi toute légi­ti­mité à la procé­dure quand elle aurait aurait été perti­nente.

Devoir se sépa­rer de sala­riés est sensible. Si vous cassez l’ou­til qui peut vous y amener, vous cassez aussi forcé­ment l’ac­cep­ta­bi­lité de la mesure, que ce soit pour celui qui part ou pour ceux qui restent.

---

Je dévie du pur commen­taire mais :

• Faites-vous accom­pa­gner par votre dépar­te­ment RH, même s’il est jeune et sans plus d’ex­pé­rience que vous.
• Soyez expli­cite, franc, honnête, et dites les choses au plus tôt sans faire trai­ner, par écrit dans des docu­ments parta­gés.
• Garder un sala­rié qui ne convient pas aux besoins ne sert personne. Ça peut même faci­le­ment être toxique pour ceux qui restent. Je garde en tête le départ de quelqu’un appré­cié par tous, compé­tent, mais qui a entrainé une hausse de produc­ti­vité une fois qu’il était parti.