Catégorie : Vie professionnelle

Extrait de The Mana­ger’s Path

How do you get to know this person quickly so you can manage him best?

Le conseil que je donne aux mana­gers débu­tants : Commence par faire des discus­sions libre. Le reste arri­vera tout seul.

Vouloir faire du formel et du produc­tif c’est passez à côté du lien social et de la confiance qui sont fina­le­ment les deux choses les plus impor­tantes.

For more ideas, see Lara Hogan’s excellent blog post on the topic.

J’ai un peu de mal à commen­cer mes premiers 1–1 par des ques­tions autres que « raconte moi ton parcours », « dis moi ce qui est impor­tant pour toi », « qu’est-ce qui t’agace au jour le jour ? » ou « tu fais quoi en ce moment ? ».

Son approche est un peu plus utili­taire mais j’aime bien aussi.

Another approach that many expe­rien­ced mana­gers use is to help their new reports create a 30/60/90-day plan.

Là dessus je diffère un peu. Quand j’ar­rive c’est moi qui ai besoin d’un plan à 30, 60 et 90 jours. C’est à moi de prou­ver où je vais.

Commen­cer par avoir une opinion sur le plan court terme de la personne qui voit un nouveau mana­ger arri­ver mais qui est déjà dans son travail depuis des mois ou des années, ça me parait un peu présomp­tueux.

Avec le temps, oui, mais pas tout de suite. Je lui demande son plan, en espé­rant qu’il en a un. Dans ce cas je fais confiance à lui ainsi qu’à son mana­ge­ment précé­dent et je commence avec ce plan sans le remettre en cause.

S’il n’y a pas de plan, je lui demande d’en faire un. Ça prend un peu de temps, ça permet de discu­ter d’autre chose en atten­dant. Si le plan arrive vite alors on le prend en tempo­raire tel quel et on le travaillera ensemble plus tard après quelques rendez-vous. Si le plan n’ar­rive pas vite c’est une bonne occa­sion pour fixer les atten­dus et montrer qu’on ne créé pas des tâches en l’air, qu’il y a un suivi derrière.

For early- to mid-career hires, one aspect of onboar­ding will likely include contri­bu­ting to the team’s onboar­ding docu­men­ta­tion.

La vraie tâche que je donne à tout le monde par défaut c’est celle là. Elle est parfaite pour les débu­tants pour comprendre comment ça fonc­tionne et devoir inter­agir avec les sachants.

Elle est parfaite aussi pour les sachants afin de forma­li­ser ce qu’ils ont en tête et diffu­ser la connais­sances. Ça permet aussi de voir les éven­tuelles diver­gences et travailler à une vraie prise de déci­sion collec­tive.

Et enfin, elle est indis­pen­sable pour les nouveaux arri­vants, parce que c’est une façon de commen­cer où on ne peut pas se plan­ter mais qui demande des inter­ac­tions et qui a une vraie valeur à la fin.

C’est aussi les nouveaux arri­vants qui voient les trous de docu­men­ta­tion ou de forma­li­sa­tion là où les membres de l’équipe déjà présents se sont rési­gnés ou travaillent sur l’im­pli­cite avec une forte charge mentale sans s’en rendre compte.

Your new hire needs to unders­tand your expec­ta­tions

On en a parlé plusieurs fois au fur et à mesure des chapitres, et même un peu en haut de cette note. Ce n’est pas vrai que pour les nouveaux embau­chés. Donner la direc­tion c’est d’abord expli­ci­ter les atten­dus, si possible par écrit, souvent plusieurs fois.

One final piece of advice: get as much feed­back as you can about the new hire’s pers­pec­tive on the team in that first 90 days.

Dans la check­list d’ac­cueil des nouveaux arri­vants, il y a un « rapport d’éton­ne­ment » à créer dès la première semaine. N’at­ten­dez pas les 90 jours : Plus on avance, plus ce qui est éton­nant, diffé­rent des attentes, manquant, sera passé sous silence. Parfois à quelques jours près on peut marquer quelque chose comme éton­nant ou simple­ment ne plus y penser, même avec des efforts. C’est d’au­tant plus fort que le but des nouveaux arri­vants est de s’in­té­grer, donc de suivre la trace déjà présente.

J’ex­pli­cite ça avec eux dès les premiers jours : Je ne veux pas qu’ils se fondent dans le paysage. Je veux qu’ils notent tout ce qu’il y a à chan­ger, tout ce qui est diffé­rent de leurs attentes, que ce soit en mieux ou en moins bien.

Je ne veux surtout pas qu’ils consi­dèrent normal ce qui ne l’est pas. Ça arri­vera bien assez tôt… et bien avant les 90 jours.

---

Et inver­se­ment, quand vous arri­vez à un poste de mana­ge­ment, prenez du feed­back (si possible anonyme, parce que votre posi­tion rendre plus diffi­cile l’ex­pres­sion de certains), au bout d’un mois, de trois mois et de six mois.

Extrait de The Mana­ger’s Path

New engi­nee­ring mana­gers think of the job as a promo­tion, giving them senio­rity on engi­nee­ring tasks and ques­tions. »

Une des premières leçons du mana­ger sur une équipe : Lâcher prise. Lais­ser l’équipe faire ses choix et défendre moins forte­ment les siens, quitte à lais­ser l’équipe se plan­ter.

L’idée c’est de ne pas être le direc­teur, juste le mana­ger. C’est à l’équipe de déci­der, pour favo­ri­ser son impli­ca­tion, son initia­tive, sa respon­sa­bi­li­sa­tion, sauf à vouloir une équipe d’exé­cu­tant.

La diffi­culté c’est de trou­ver le bon équi­libre entre le lais­ser-faire et la direc­tion auto­ri­taire. Le mana­ger est quand même aussi souvent (même si pas toujours) un des plus expé­ri­men­tés. C’est aussi lui qui a le plus en tête les enjeux de l’en­tre­prise et des autres personnes autour. Parfois ça a du sens d’im­po­ser, surtout quand c’est une déci­sion non tech­nique.

It’s hard to accept that “new mana­ger” is an entry-level job with no senio­rity on any front »

Amen.

Et ça veut dire être coaché, avoir soi-même un mana­ger (pas juste un direc­teur ou supé­rieur hiérar­chique), suivre des forma­tion et lire des livres, parti­ci­per à des commu­nau­tés de mana­gers.

On commence un nouveau rôle mais on attend de nous qu’on sache, comme si le rôle précé­dent rendait ça natu­rel. Accep­tez de ne pas savoir. Exploi­tez votre mana­ger pour lui deman­der comment faire. Ayez l’hu­mi­lité de ne pas essayer ou croire savoir. Lisez. Parta­ger ce que vous avez lu pour permettre aux autres d’in­te­ra­gir et de vous enri­chir aussi.

Oui, c’est ce que je suis en train de faire ;-)

In the next chap­ter, we’ll talk more about the chal­lenges of dealing with the team as a whole, as well as how the tech­ni­cal side of your role might be chan­ging, but it’s impor­tant to start by consi­de­ring the indi­vi­duals.

Il faudrait que je fasse tour­ner ça un peu. Je me rends compte que je fais parfois le contraire. Je regarde d’abord l’équipe, avec le prétexte qu’à mon niveau j’au­rai trop de mal à regar­der chaque personne indi­vi­duel­le­ment. Le résul­tat c’est une limite vers 8 à 12 mois où après avoir réglé les problèmes prin­ci­paux au niveau des équipes, j’ai plus de mal à rattra­per le retard et entrer dans l’opé­ra­tion­nel et l’in­di­vi­duel, faute d’avoir un contact sur le terrain en dehors des leads.

Extrait de The Mana­ger’s Path

Your produc­ti­vity is now less impor­tant than the produc­ti­vity of the whole team.

Passé 5 à 10 ans d’ex­pé­rience, si vous n’avez toujours pas compris ça et que ce n’est pas inté­gré dans vos actions, vous plafon­ne­rez assez vite dans votre impact (et donc dans votre carrière).

If one univer­sal talent sepa­rates success­ful leaders from the pack, it’s commu­ni­ca­tion skills.

It doesn’t matter whether you choose to dive deep into tech­no­logy, or become a mana­ger — if you can’t commu­ni­cate and listen to what other people are saying, your career growth from this point on will suffer.

Le livre parle de mana­ge­ment mais cette section s’adresse aux leads. Pour moi ça va plus loin. On s’adresse à tous ceux qui veulent progres­ser au delà du stade de déve­lop­peur senior à 5 – 10 ans d’ex­pé­rience.

Vous devez déve­lop­per la commu­ni­ca­tion et en faire un levier. Ce n’est pas obli­ga­toire dans l’ab­solu, vous pouvez juste déve­lop­per votre exper­tise et votre travail mais vous ne progres­se­rez proba­ble­ment plus, ou pas faci­le­ment / rapi­de­ment. C’est vrai à cause de la première cita­tion de ce billet : L’im­por­tant c’est l’équipe et plus vous seul.

L’op­posé est vrai aussi. Il n’y a pas besoin d’être le meilleur tech­ni­cien pour avan­cer vite dans la carrière, même si on préfère la branche tech­nique à la branche mana­ge­ment. Une fois acquis les compé­tences de base, celui qui déve­loppe la commu­ni­ca­tion va très vite surpas­ser celui qui ne regarde que l’ex­per­tise tech­nique.

It’s almost impos­sible to lead projects well when you don’t unders­tand the archi­tec­ture you’re chan­ging.

Plus que parler de compé­tence de base et d’ex­per­tise tech­nique, l’au­teure trouve la bonne formu­la­tion. Il faut comprendre la vue d’en­semble, savoir comment tout s’agence. Le détail de chaque ligne importe beau­coup moins si on veut dépas­ser l’ex­per­tise tech­nique.

If you’re doing all of the inter­es­ting work your­self, stop. Look at the tricky, boring, or annoying areas of tech­ni­cal need and see if you can unstick those areas.

Si vous allez dans la branche mana­ge­ment ou lead, trou­vez des tâches qui ne sont pas sur le chemin critique. Ce sont celles qui vont rendre la vie facile ou faire avan­cer la barque mais qui ne sont pas indis­pen­sable.

Si vous avez d’autres prio­ri­tés, personne ne vous atten­dra. Si vous réus­sis­sez vous appor­te­rez quelque chose que l’équipe n’au­rait pas eu le temps ou l’op­por­tu­nité de faire.

If you’re only doing the most boring work, stop that, too.

L’al­ter­na­tive c’est faire des tâches d’exé­cu­tion. Pas les pires, parce qu’il ne faut pas qu’on compte sur vous pour ça. Juste celles qu’on ne voit pas, qu’on ne compte pas. Le travail invi­sible.

Il faut donc alter­ner entre les tâches visibles qui rendent la vie facile (et là dessus travailler sur tout ce qui est « expé­rience de déve­lop­peur » à auto­ma­ti­ser les proces­sus ou régler les erreurs anciennes sont des cibles faciles) et les tâches d’exé­cu­tion invi­sibles.

Extraits de The Mana­ger’s Path

Process czars may be obses­sed with agile, Kanban, scrum, lean, or even water­fall methods. They may have a very precise idea of how on-call should work, how code reviews must be done, or how the release process has to operate.

On m’a appris assez tôt que les livres et les méthodes servaient de cadre de réfé­rence mais que si on fait exac­te­ment comme dans le livre c’est qu’on a loupé quelque chose.

If you are honest and make it clear that it’s safe to fail and to be imper­fect, that’s often enough to get your process czar to relax a little bit and let some ambi­guity in.

Je ne l’en­vi­sa­geais pas ainsi avant ma lecture mais c’est assez vrai.

Je préfère l’ini­tia­tive au mode singe savant. L’ini­tia­tive implique l’échec. Si je veux de l’ini­tia­tive l’échec est forcé­ment accep­table.

Un process qui rend l’échec inac­cep­table c’est souvent un process qui coupe l’ini­tia­tive ou l’adap­ta­tion locale.

Indi­vi­duals and inter­ac­tions over processes and tools

Working soft­ware over compre­hen­sive docu­men­ta­tion

Custo­mer colla­bo­ra­tion over contract nego­tia­tion

Respon­ding to change over follo­wing a plan

Extrait de The Mana­ger’s Path

The deci­sion of whether to be a mana­ger or stay on the tech­ni­cal track is […] incre­di­bly context-speci­fic »

Je me balance encore entre le CTO très tech­nique et le VP Engi­nee­ring qui parlent essen­tiel­le­ment d’or­ga­ni­sa­tion et d’hu­main. J’ai tenu les deux rôles et je risque de conti­nuer à l’ave­nir.

Ne croyez pas ceux qui vous disent qu’un mana­ger est forcé­ment un mauvais expert, ou qu’un expert est forcé­ment une bille dans le savoir-être. Ce sont des cari­ca­tures qui entrainent les personnes vers le bas voire incitent les tiers à accep­ter des compor­te­ments inadé­quats.

On parle de voies mais ce ne sont pas des direc­tions défi­ni­tives. On peut mixer les deux, on peut passer de l’un à l’autre, puis reve­nir.

---

La suite du chapitre montre l’ima­gi­naire de ce qu’est un contri­bu­teur indi­vi­duel et la réalité, l’ima­gi­naire de ce qu’est un mana­ger et la réalité.

Je n’ai rien à citer mais j’aime bien ces deux visions parce que dans les deux j’ai eu des personnes se plaindre d’être dans le scéna­rio « réel ». Oui les tiers ne vous suivront pas. Oui la marge d’ac­tion sera mangée par plein de contraintes. Si vous voulez faire sauter quelques écueils, c’est à vous de le faire, ça sera une part de votre rôle.

Extraits de The Mana­ger’s Path

Work through the unknowns until you really feel that there is no more value to be gained in spen­ding time on them.

La phrase est juste et le diable est dans le « jusqu’où » ainsi que le « quand ».

Je vois plus souvent de l’ex­cès que l’in­verse, et je le ressens aussi dans ce livre même si je n’ai aucune phrase que sur laquelle je saurais poin­ter un désac­cord si on me le deman­dait.

On explore les grands sché­mas, voir si quelque chose est simple ou complexe, mais ensuite « there is no more value to be gained in spen­ding time on them ». Le doigt mouillé est large­ment suffi­sant.

Lais­sez l’in­connu, vous le lève­rez au cours du projet. L’enjeu c’est de prio­ri­ser ce qu’il faut dérisquer en premier. Le plan bougera mais il bougera tôt. Je préfère 1000 fois un plan qui bouge qu’un plan soit disant parfait qui nous aura coûté 20% du projet… et qui ne se révè­lera pas parfait pour autant.

As things slip (and they always do), keep everyone appri­sed of the status. »

Pour faire ça il faut cepen­dant fixer des objec­tifs, courts, fréquents. Impos­sible de savoir où on en est si on ne s’est pas d’abord fixé un jalon à atteindre.

Extraits de The Mana­ger’s Path

Ce sous-chapitre m’a laissé mal à l’aise au début.

C’est une expé­rience person­nelle, un vécu raconté à la première personne. Il n’y a donc aucune argu­men­ta­tion possible. Il reste que j’y lis une façon de voir le projet à base de décou­page et d’es­ti­ma­tions qui n’est plus la mienne aujourd’­hui.

You’ll need to esti­mate project length for your mana­ge­ment team, and give some detail on why you believe things will take that long.

I had to take this incre­di­bly compli­ca­ted set of tasks and try to figure out which ones depen­ded on other ones. I had to think of all kinds of depen­den­cies. How would we make it work in the complex testing frame­work we depen­ded on? How would we deploy it? When did we need to order hard­ware to test it? How long would inte­gra­tion testing take?

I’m afraid that I will be held accoun­table and that I could miss some­thing impor­tant in the process that will make the project fail.

L’au­teure parle de peur, de crainte, de juge­ment du mana­ger, de moments pas fun, pour en tirer que c’est quand même néces­saire mais sans pour autant éclai­rer sur pourquoi.

Je mets ça sur ma liste à relire. Peut-être que je passe à côté du sujet prin­ci­pal.

Je retiens toute­fois ce qui suit, avec lequel je suis par contre en plein accord :

Ulti­ma­tely, the value of plan­ning isn’t that you execute the plan perfectly, that you catch every detail befo­re­hand, or that you predict the future; it’s that you enforce the self-disci­pline to think about the project in some depth before diving in and seeing what happens. […] The plan itself, howe­ver accu­rate it turns out, is less impor­tant than spen­ding time on the act of plan­ning. »

Extraits de The Mana­ger’s Path

This role requires you to have a good sense of the overall archi­tec­ture of your systems and a solid unders­tan­ding of how to design complex soft­ware. It proba­bly also requires you to be able to unders­tand busi­ness requi­re­ments and trans­late them into soft­ware. »

J’ai beau­coup parlé commu­ni­ca­tion et un peu prise de respon­sa­bi­lité, proba­ble­ment en me lais­sant guider par les cita­tions. Ici sort le troi­sième aspect qui me semble indis­pen­sable pour celui qui veut passer au-delà du rôle de déve­lop­peur senior : La prise en compte des besoins de l’en­tre­prise.

Oui il va falloir parler sens commer­cial, stra­té­gie de déve­lop­pe­ment, parte­na­riat, vélo­cité, coûts, et plein d’autres choses que notre qualité tech­nique ou que la fameuse dette tech­nique. Ces deux derniers items ne sont que des outils et pas des fina­li­tés.

Le senior s’ar­rê­tera à « il faut faire comme ça » alors que j’at­tends des rôles de lead et de staff la reflexion de « oui mais ce dont nous avons besoin aujourd’­hui c’est … ».

In a heal­thy orga­ni­za­tion, there is no shame or harm in raising issues early.

Cette petite phrase aurait à mon avis plus de place dans les premiers chapitres mais ça ne fait pas de mal de la rappe­ler.

Commu­niquer au plus tôt de la façon la plus trans­pa­rente possible. Non seule­ment ça permet­tra de répondre au problème plus tôt, mais ça dimi­nuera le stress de tout le monde.

La règle : On ne blâmera jamais quelqu’un pour lever de façon construc­tive une alerte, y compris très tôt. On pourra par contre repro­cher de ne pas l’avoir fait.

As projects move forward, unex­pec­ted obstacles arise. Some­times tech leads are temp­ted to go to heroics and push through these obstacles them­selves, working exces­sive over­time to get it all done.

J’ai envie de dire « ne le faites pas » mais la raison me pousse à être plus modéré. Ne le faites pas souvent. Faites le unique­ment de façon concer­tée après avoir levé le sujet à l’en­semble de l’équipe. Ne restez pas dans un rôle où vous seriez indis­pen­sable.

Passé la douzaine je ne veux plus de héros mais des membres d’une équipe qui colla­bore. L’im­pact indi­vi­duel devient moins impor­tant que l’im­pact collec­tif.

Extraits de The Mana­ger’s Path

Having the tech­ni­cal chops and matu­rity is nothing, howe­ver, if you can’t figure out the biggest trick of being a good tech lead: the willin­gness to step away from the code and figure out how to balance your tech­ni­cal commit­ments with the work the whole team needs. You have to stop relying enti­rely on your old skills and start to learn some new skills. You’re going to learn the art of balance. »

Je pensais trou­ver un passage sur la commu­ni­ca­tion, la moti­va­tion des équipes, le fait de donner du sens.

Je finis surpris mais assez en accord. La première diffi­culté du lead est de savoir arbi­trer son temps, et c’est bien la compé­tence fonda­men­tale pour réus­sir à chan­ger de rôle.

Sauter la partie tech­nique c’est ne plus être dedans et ne plus savoir correc­te­ment pilo­ter le projet. Trop s’ar­rê­ter sur la tech­nique est tentant puisque c’est ce qu’on sait faire, mais ça veut dire oublier son propre rôle.

L’ar­bi­trage n’est pas simple et, parce qu’il varie en fonc­tion des besoins, je doute qu’on arrive un jour à un équi­libre parfait. Si cet équi­libre existe je ne l’ai pas trouvé.

What’s worse, you’ll often need to balance doing things you know how to do and enjoy doing, such as writing code, with things you don’t know how to do

Je ne me souviens pas avoir vu de déve­lop­peur senior me disant vouloir être lead. En géné­ral c’est une aspi­ra­tion de junior qui voir le rôle comme une étape de plus sur sa progres­sion. Ces envies dispa­raissent quand on montre une voie de progres­sion en contri­bu­tion indi­vi­duelle.

La plupart des leads que j’ai vu passer sont des personnes qui y sont allés par besoin. Ce peut être de façon passive, parce qu’on a eu besoin d’un lead et qu’elles étaient le meilleur choix. Ce peut aussi être plus actif, en voulant résoudre les problèmes, et consi­dé­rer que si personne ne le fait ça n’évo­luera pas. Ce peut être enfin juste parce que c’est là qu’elles ont eu l’im­pres­sion d’être le plus effi­cace. Dans les trois cas c’est diffé­rent de « je veux faire ça parce que ça me plait ».

Il faut que ça plaise mais ce n’est, de mon expé­rience, par le moteur premier et je trouve ça parti­cu­liè­re­ment inté­res­sant. Ça fait sortir une carac­té­ris­tique commune : Le senti­ment de devoir agir et prendre la respon­sa­bi­lité qu’il faut pour ça. Les anglo­phones ont un mot pour ça : owner­ship.

Part of your leader­ship is helping the other stake­hol­ders, such as your boss and the product mana­ger, respect the team’s focus and set up meeting calen­dars that are not overw­hel­ming for indi­vi­dual contri­bu­tors. »