Manager plusieurs équipes

Bienvenue dans le monde du management de plusieurs équipes. À ce stade, vous avez probablement des tech leads qui vous rapportent, et vous jonglez entre l'encadrement direct de plus de trois ou quatre personnes et le suivi de ce qui se passe sur deux ou trois équipes à la fois. Cela implique une chose importante, que Fournier énonce sans détour : vous n'écrivez plus de code de production (ou très peu). Dans l'échelle de carrière qu'elle a conçue chez Rent the Runway, c'est typiquement le rôle de directeur de l'ingénierie (engineering director) qui marque ce basculement — un poste où l'on encadre des ingénieurs sur plusieurs domaines produit ou plusieurs fonctions techniques, avec à la fois des tech leads et des contributeurs individuels qui vous rapportent.

Votre agenda a quitté le mode « créateur (maker) » pour s'installer dans le mode « manager ». Entre vos réunions en tête-à-tête (one-on-one), vos sessions avec les autres responsables d'ingénierie, la planification d'équipe et les échanges avec vos pairs du produit, vous êtes saturé. La ressource la plus rare n'est plus votre capacité à coder : c'est votre temps et votre attention. Tout ce chapitre tourne autour de cette bascule. Apprendre à gérer ce temps, à prioriser, à déléguer pour de bon et à garder une prise technique « de loin » devient le cœur du métier.

Rester technique sans écrire de code

Fournier insiste : croire que ce poste devient « non technique » est une erreur. Vous restez responsable de la compétence technique globale de votre organisation, de la qualité des décisions d'architecture et de la santé des systèmes. Simplement, vous exercez cette responsabilité autrement qu'en écrivant du code de production. Il existe plusieurs façons de garder les mains dans le cambouis (stay hands-on) sans y consacrer des journées entières.

Manière de rester technique	Pourquoi c'est utile
Revue de code en relecteur secondaire	Garde la pratique, surtout sur les systèmes que vous avez construits et dont vous connaissez les détails mieux que personne
Débogage et support de production	Précieux si vous étiez un bon débogueur ; sinon, sauter dans les incidents sera plus gênant qu'utile
Pair programming, petits bugs, petites features	Vous garde « en phase » avec la sensation du développement et montre à vos équipes que vous savez et voulez aider
Une demi-journée créative par semaine	Article de blog technique, préparation de conférence, contribution open source : pour gratter cette « démangeaison créative »

Fournier minimise rarement ces petits efforts : ils vous gardent en phase avec le rythme de fabrication du logiciel, ce qui est indispensable pour l'une des parties critiques du job à ce niveau — déboguer les problèmes d'équipe et maintenir une production logicielle fluide et de qualité.

Gérer son temps : important vs urgent

Quand les obligations managériales s'accumulent, on a l'impression que sa journée est prise en otage par les caprices des autres : tête-à-tête, réunions de planification, points d'avancement, standups… Or vous avez toujours des livrables qui dépassent le fait d'être assis en réunion : fixer les objectifs de l'équipe, aider le produit à détailler la feuille de route, vérifier qu'une tâche assignée a réellement été terminée. Ce dernier point — le suivi d'achèvement — peut devenir l'un des plus gros gouffres à temps de votre journée si vous n'y prenez pas garde.

La gestion du temps est une affaire personnelle, et Fournier ne prescrit pas une méthode unique (elle recommande de lire Getting Things Done de David Allen pour s'en inspirer). Mais sa philosophie générale tient en une distinction : comprendre la différence entre importance et urgence. Presque toutes vos tâches se rangent dans l'un des quatre quadrants d'une matrice important/urgent (proche de la matrice d'Eisenhower).

	Pas urgent	Urgent
Important	Stratégique : dégagez du temps pour ça	Travail évident : vous le faites déjà
Pas important	À éviter, évidemment	Distractions tentantes

Ce qui est important ET urgent, vous le faites sans hésiter : une panne majeure, des évaluations de performance dues demain, une offre à faire à un excellent candidat dont l'offre concurrente expire dans deux jours. Vous n'êtes pas aveugle à ces tâches : laisser tomber l'une d'elles coûte quelque chose de tangible.

Le vrai piège émerge quand on perd le sens de l'importance. L'urgence se ressent plus nettement que l'importance, et l'on confond souvent « urgent », « évident » et « important ».

Vous passez probablement beaucoup de temps sur des choses urgentes mais à peine importantes, en sacrifiant des choses importantes mais pas urgentes. Or c'est précisément le quadrant stratégique qui exige votre vigilance. Quelques exemples de tâches importantes-mais-pas-urgentes que Fournier cite :

• Préparer les réunions pour pouvoir les piloter sainement (une culture de réunions courtes et productives suppose que chacun arrive préparé).
• Rédiger des descriptions de poste, élaborer un plan de recrutement.
• Relire l'état d'avancement d'un projet pour repérer un problème naissant.
• Parler à un manager d'une autre équipe avec qui couve un conflit ou un désaccord.
• Penser au futur : entretenir la liste des sujets importants que vous avez perdus de vue.

Le piège : abandonner trop de réunions

Une fois cette grille en tête, la tentation est de ne plus aller aux réunions « urgentes mais pas importantes » où vous n'êtes pas clairement nécessaire. Fournier met fortement en garde contre l'usage abusif de cette stratégie à ce niveau précis. La réussite et l'engagement de vos équipes reposent sur vos épaules. En cessant d'assister à leurs réunions internes, vous risquez de manquer les indices qui vous permettraient de repérer les problèmes tôt — à commencer par l'existence de trop nombreuses réunions ennuyeuses.

Votre présence sert aussi à lire la dynamique et le moral : regardez la salle. Si la moitié des gens somnolent, fixent le vide ou pianotent sur leur téléphone, la réunion gaspille leur temps. Une équipe heureuse paraît énergisée et engagée ; une équipe démotivée paraît vidée ou s'ennuie.

Décisions et délégation

Les premiers mois à manager plusieurs équipes peuvent ressembler à une marche forcée, même sans horaires excessifs. Votre attention, jadis concentrée, est désormais hachée entre les réunions qui parsèment la journée. Fournier raconte avoir perdu sa voix plusieurs fois tant elle parlait ; une amie devenue directrice a dû faire commander ses déjeuners car elle oubliait de manger. La seule issue, dit-elle, est de traverser cette période. Et un avertissement contre-intuitif : si vous ne vous sentez pas un peu débordé, vous loupez probablement quelque chose.

La meilleure image du management à partir d'ici est celle du jongleur d'assiettes (plate spinning) : plusieurs perches surmontées chacune d'une assiette en rotation, et il faut relancer chacune avant qu'elle ne ralentisse et ne tombe. Vos assiettes sont les personnes et les projets que vous supervisez ; votre travail est de doser combien d'attention chacune réclame, et quand. Abordez l'exercice avec un esprit d'apprenti : vous laisserez tomber quelques assiettes, et c'est en affinant votre instinct sur le « quand toucher quelle assiette » que vous progresserez.

La délégation est le principal moyen de vous extraire de cette sensation d'avoir trop d'assiettes en l'air. Devant chaque tâche, posez-vous : dois-je vraiment être la personne qui réalise ce travail ? La réponse dépend de deux axes — la complexité et la fréquence de la tâche.

	Fréquent	Peu fréquent
Simple	Déléguer	Faites-le vous-même
Complexe	Déléguer (avec soin)	Déléguer comme formation

Déléguer le simple et fréquent

Si la tâche est simple et fréquente, trouvez quelqu'un à qui la confier. Exemples : animer le standup quotidien, rédiger le résumé hebdomadaire de progression des équipes, ou conduire des revues de code mineures. Vos tech leads ou ingénieurs seniors peuvent en prendre la responsabilité, et n'auront probablement même pas besoin de formation pour cela.

Traiter soi-même le simple et rare

Si c'est plus rapide de le faire vous-même que de l'expliquer à quelqu'un, et que cela arrive rarement, retroussez vos manches et faites-le — même si vous jugez la tâche « indigne » de vous. Réserver un billet de conférence pour un membre de l'équipe, lancer le script qui génère les rapports trimestriels : autant le faire.

Utiliser le complexe et rare comme formation

Rédiger les évaluations de performance ou bâtir un plan de recrutement sont des tâches complexes et peu fréquentes qui vous reviennent à vous seul. Mais ce sont aussi des compétences à transmettre aux managers en devenir. Faites asseoir un tech lead à vos côtés pour rédiger l'évaluation d'un stagiaire ; demandez à un ingénieur senior son avis sur le nombre de recrutements nécessaires l'an prochain. Demandez de l'aide au-dessus de vous jusqu'à être à l'aise, puis tirez vers le haut les leaders émergents pour qu'ils apprennent.

Déléguer le complexe et fréquent pour faire grandir l'équipe

C'est ici que se joue la plus grande opportunité de faire grandir vos talents tout en faisant tourner l'équipe mieux. La planification de projet, la conception de systèmes, le rôle de pilote pendant une panne : les managers forts y consacrent beaucoup de temps pour développer leurs équipes. Votre but est de rendre vos équipes capables d'opérer à haut niveau sans grande intervention de votre part — donc d'avoir des personnes qui reprennent ces tâches complexes et les mènent sans vous.

La délégation commence lentement mais devient l'élément essentiel de votre propre croissance de carrière : si vos équipes ne tournent pas bien sans vous, il vous sera difficile d'être promu. Poussez les décisions vers vos talents, et vous libérerez du temps pour aller apprendre à faire tourner de nouvelles assiettes, plus intéressantes.

Repérer les signaux faibles

Avec l'expérience, votre instinct s'aiguise et vous reconnaissez tôt les projets qui dérapent, les personnes prêtes à partir et les équipes qui sous-performent. C'est aussi pour cela qu'il faut rester présent dans les réunions : elles vous apprennent à quoi ressemblent les dynamiques saines et malsaines. Fournier dresse une liste de signaux d'alerte (warning signs) qu'elle a appris à repérer.

Signal observé	Cause probable / action
Une personne habituellement bavarde et engagée part tôt, arrive tard, se tait en réunion, déserte le chat	Problème personnel ou départ imminent — surtout après une promotion ou une réorganisation où elle s'est sentie négligée. Ayez une conversation honnête avant la démission
Un tech lead affirme que « tout va bien » mais saute vos tête-à-tête et reste vague dans ses points	Il cache probablement quelque chose : avancement bien plus lent que prévu, ou périmètre qui dérive. Aidez-le à poser tôt un plan de projet clair et à en clarifier les objectifs
L'équipe n'a aucune énergie en réunion ; seuls le PM et le tech lead parlent	Manque d'engagement : l'équipe ne se sent pas partie prenante des décisions
La liste des projets change chaque semaine au gré des clients	L'équipe n'a pas pensé ses objectifs au-delà du fait de plaire aux clients : il lui manque une direction produit ou business
Une petite équipe fragmentée : chacun ignore les systèmes qu'il ne touche pas, sans curiosité de les apprendre	L'équipe s'identifie à son travail quotidien plus qu'au groupe ou à l'entreprise ; elle résistera aux changements dictés par les besoins plus larges

Savoir dire non

Un manager crée un environnement fertile où le travail peut advenir : il est facilitateur, coach et champion. Mais pour créer cet environnement, il doit parfois dire non — à son équipe, à ses pairs, et même à son patron. Chacun de ces « non » est difficile à sa manière, et Fournier propose plusieurs stratégies.

Stratégie	Quand l'utiliser	En pratique
« Oui, et… » (yes, and)	Surtout face à votre patron et vos pairs	« Oui, on peut faire ce projet, et il nous faudra repousser le démarrage de cet autre projet déjà au planning. » Un « non » positif qui transforme les désaccords en négociations de priorité
Créer une politique (policy)	Quand vous répétez le même « non » avec les mêmes raisons	Formalisez les exigences dures pour arriver à « oui » (ex. : standards de log, de tests, savoir mettre un langage en prod). L'équipe connaît d'avance le coût du « oui »
« Aidez-moi à dire oui » (help me say yes)	Pour les cas isolés sans politique claire	Posez des questions, creusez les points douteux. Souvent l'autre réalise lui-même que l'idée est faible — sinon, il vous surprend. Dire non en enseignant
Invoquer le budget / le temps	Avec l'équipe comme avec les pairs	Étalez la charge actuelle en termes clairs. Parfois couplé à un « pas maintenant (not right now) » — mais si « pas maintenant » sous-entend « plus tard », assurez-vous que « plus tard » puisse vraiment arriver
Faire équipe (work as a team)	Avec vos pairs interfonctionnels (produit, finance)	Prêtez votre autorité technique à leur « non », quitte à leur demander la pareille ensuite. Le « gentil flic / méchant flic » est un peu malhonnête : à utiliser avec parcimonie
Ne pas tergiverser (don't prevaricate)	Quand vous savez déjà que c'est non	Dites-le vite plutôt que de traîner. Vous vous tromperez parfois : excusez-vous alors. Entraînez-vous au « non rapide » (et au « oui rapide ») pour les décisions à faible enjeu

La santé technique de l'équipe, vue de loin

Votre attention technique se déplace : vous n'écrivez plus le code, mais vous observez et améliorez les systèmes de travail dans lesquels vos développeurs opèrent. Il vous faut développer un œil pour les signaux de santé technique de l'équipe. Fournier emprunte au livre First, Break All the Rules trois questions qui prédisent productivité et satisfaction : Sais-je ce qu'on attend de moi ? Ai-je le matériel et les outils nécessaires ? Ai-je l'occasion de faire ce que je fais le mieux chaque jour ?

Pour des ingénieurs, ces réponses se lisent dans la vitesse et la fréquence avec lesquelles ils livrent du code. Trois indicateurs concrets traduisent une équipe qui sait quoi faire, dispose des outils pour le faire et a le temps de le faire chaque jour.

Indicateur de santé	Ce qu'il révèle	Votre rôle de loin
Fréquence des releases	La mesure la plus directe : une équipe qui ne livre pas a presque toujours des « fissures » (process long, pas d'appropriation de la qualité, rollbacks lents)	Pousser pour découper le travail en petits morceaux ; mener l'effort (automatisation, feature toggles, compatibilité ascendante) sans tout faire vous-même
Fréquence des check-ins de code	Une équipe agile sait découper son travail ; ceux qui partent coder seuls des semaines sans pousser ralentissent tout le monde	Poser l'attente que le travail en cours est mis à jour régulièrement, même si cela bouscule des seniors
Fréquence des incidents	La stabilité s'améliore-t-elle, se dégrade-t-elle ? Le bon niveau de qualité dépend du produit	Équilibrer le risque pour que ni les incidents ni leur prévention ne dévorent des journées entières de développement

Énergie, focalisation et burnout

Fournier reprend la formule de Larry Wall sur les vertus de l'ingénieur — « paresse, impatience et orgueil (laziness, impatience, hubris) » — et montre comment les canaliser en leadership. En tête-à-tête avec les personnes, surtout pas d'impatience : ce serait blessant. Et ne paraissez jamais paresseux pendant que votre équipe s'épuise. Mais l'impatience couplée à la paresse, dirigée vers les processus et les décisions, est merveilleuse : c'est la clé de la focalisation.

Deux comportements à modéliser dès maintenant : trouver ce qui est important et rentrer chez soi. Devant tout ce qui semble inefficace, questionnez : Pourquoi cela me paraît-il inefficace ? Quelle est la valeur de ce que nous faisons ? Peut-on la livrer plus vite, dépouiller le projet pour aller plus simple ? Attention au piège : demander « peut-on aller plus vite ? » veut trop souvent dire « peut-on travailler plus d'heures pour finir en moins de jours ? ».

Se forcer à déconnecter est essentiel pour la santé mentale, et le burnout est un problème réel. Mais l'enjeu n'est pas seulement votre propre épuisement : c'est aussi celui de votre équipe. Quand vous restez plus tard que tout le monde et envoyez des e-mails à toute heure, même sans attendre de réponse, vos équipes vous voient faire et pensent que c'est important — et ce surmenage les rend moins efficaces, surtout sur le travail de connaissance fin qu'exige l'ingénierie.

À retenir

• À ce niveau, vous n'écrivez plus de code de production : la ressource rare devient votre temps et votre attention. Restez technique autrement — revues de code secondaires, support de production, pair programming, et une demi-journée créative par semaine.
• Priorisez avec la matrice important/urgent : le piège n'est pas l'important-et-urgent (vous le voyez), mais de sacrifier l'important-mais-pas-urgent (stratégie, préparation, recrutement, futur) au profit du faux-urgent comme l'e-mail. Votre patron attend que vous traitiez ces sujets avant qu'ils ne deviennent urgents.
• Déléguez selon complexité × fréquence : le simple-et-fréquent se délègue, le simple-et-rare se fait soi-même, et le complexe se délègue — avec soin ou comme formation — pour faire grandir l'équipe. Résistez à la tentation de reprendre le travail délégué ; si l'équipe ne tourne pas sans vous, vous ne serez pas promu.
• Ne sautez jamais vos tête-à-tête et restez assez présent en réunion pour lire la dynamique et capter les signaux faibles : désengagement, tech lead qui se tait, liste de projets qui change chaque semaine.
• Apprenez à dire non sans braquer : « oui, et… », créer une politique, « aidez-moi à dire oui », invoquer le budget, faire équipe avec vos pairs — et ne pas tergiverser sur les décisions à faible enjeu.
• Gardez une prise technique de loin via trois signaux de santé — fréquence des releases, des check-ins et des incidents — et gérez l'énergie : « plus vite » veut dire plus de valeur en moins de temps, pas plus d'heures. Rentrez chez vous, et montrez l'exemple pour éviter le burnout de l'équipe.