[Lecture] Mana­ging Multiple Teams

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.