- Dans un environnement réunissant des experts de nombreux domaines, le rôle du leader n’est pas de maîtriser tous les détails techniques, mais de relier les problèmes et de donner une direction à leur résolution
- En leadership, plus que la simple connaissance technique, ce sont surtout les capacités de traduction et les compétences relationnelles qui comptent, ainsi que l’aptitude à arbitrer les conflits et à mettre en avant un objectif commun
- L’essentiel n’est pas la profondeur de l’expertise de chacun, mais la capacité à clarifier le véritable problème et l’orientation de sa résolution, afin que les échanges débouchent sur les besoins des utilisateurs et des résultats concrets
- Un leader efficace ne prétend pas tout savoir : il a le courage de dire « je ne sais pas » et crée un cadre dans lequel les experts peuvent contribuer de manière proactive
- La véritable valeur d’un leader réside dans la traduction des points de vue, l’apport de contexte sur le problème et la création d’un espace de collaboration, des éléments clés pour obtenir les meilleurs résultats
Une prise de conscience récente
- Je me suis retrouvé dans une salle avec des développeurs experts de différents domaines et l’équipe produit
- Je n’ai pas la plus grande expertise sur une technologie en particulier, mais j’occupe un rôle de lead developer
- Au milieu des experts, mon rôle de leader n’est pas de connaître toutes les réponses, mais d’être capable de les faire émerger et de les relier entre elles
Technical Leadership
- Plus que par la profondeur de ses connaissances techniques, le leader agit comme un traducteur efficace qui facilite la communication entre les équipes
- Qu’il s’agisse d’expliquer le planning de l’équipe backend ou les besoins de l’équipe produit, il interprète chaque point de vue pour faire avancer la collaboration
Leading is a Social Skill
- La crédibilité technique seule ne suffit pas : ce sont les compétences relationnelles qui créent la véritable productivité
- Il faut savoir lire les discussions entre développeurs et décider quand arbitrer un débat ou au contraire le laisser avancer
- Une communication efficace ne passe pas uniquement par la documentation, mais aussi par des échanges actifs
Leading is Remembering the Goal
- Plus une personne est experte, plus elle a tendance à se concentrer sur les détails techniques ; le leader, lui, doit garder l’objectif global en ligne de mire
- Son rôle est important non pas dans la discussion technique elle-même, mais dans la capacité à définir clairement le problème fondamental de l’expérience utilisateur et l’objectif métier
- Si l’on ne définit pas clairement la nature du problème, les membres de l’équipe risquent, chacun selon sa propre grille d’analyse, de passer à côté du véritable enjeu
- Le leader a la responsabilité de traduire le problème pour que l’équipe le comprenne correctement et regarde dans la même direction
Leading is Saying "I Don't Know"
- Plutôt que de faire semblant de tout savoir, adopter une posture du type « je ne sais pas, cherchons ensemble » crée de la confiance et une culture d’ouverture
- Cette attitude autorise les questions et la discussion chez les experts, tout en donnant à chacun l’occasion d’exprimer pleinement ses compétences
- Le leader donne du pouvoir de décision et de parole aux experts du domaine, tout en indiquant une direction productive à la discussion
- Quand deux experts divergent sur une manière d’implémenter quelque chose, le rôle du leader n’est pas de choisir la « bonne réponse », mais de fournir un cadre à partir des trade-offs et de l’impact utilisateur
The Translation Challenge
- Le leader doit pouvoir traduire selon le contexte le langage des développeurs, celui du produit et celui de la direction
- Développeurs : "Sans circuit breaker adapté sur le service d’authentification, une défaillance en cascade peut survenir en situation de charge"
- Équipe produit : "Si le système de connexion rencontre un problème, toute l’application peut être affectée ; il faut donc ajouter une protection, ce qui rallonge le planning d’une semaine"
- Direction : "Sur ce sprint, nous faisons passer la stabilité du système en priorité afin de réduire le risque business"
- Il n’est pas nécessaire de demander aux experts d’apprendre aussi le langage des autres départements : c’est au leader de jouer le rôle de pont entre eux
Beyond "Because, that's why!"
- Une manière de décider fondée sur le principe « On fait comme ça parce que je suis le lead » nuit à la confiance, à la culture de collaboration et à la productivité de l’équipe
- Il est important de traiter l’équipe en adultes et d’expliquer clairement les raisons et le contexte des décisions
- "Nous choisissons une approche conservatrice parce que le coût d’une erreur serait élevé, et nous pourrons ensuite l’améliorer de façon itérative"
- "Cela peut ressembler à du travail supplémentaire, mais c’est aligné avec nos objectifs d’architecture et cela facilitera le développement des prochaines fonctionnalités"
- "Ce n’est peut-être pas la solution la plus élégante, mais c’est celle que nous pouvons déployer avec confiance dans le délai imparti"
- Plus on lâche l’ego lié à l’expertise, plus il devient possible d’exercer un véritable leadership
La valeur qu’un leader doit apporter à son équipe
- Fournir une définition claire du problème
- Donner une explication suffisante du contexte des décisions
- Traduire les différences de point de vue entre équipes
- Protéger l’équipe d’une complexité inutile
- Créer les conditions pour obtenir les meilleurs résultats
Conclusion
- Dans une organisation d’experts, le leadership technique va au-delà du commandement et du contrôle : il consiste surtout à relier les personnes et à apporter du contexte
- Le leader n’est pas le musicien qui joue lui-même de chaque instrument, mais plutôt le chef d’orchestre qui aide l’ensemble à interpréter une même œuvre
- C’est un défi bien plus intéressant que de simplement être la personne la plus brillante dans la salle
4 commentaires
À l’inverse, je me dis que dans un environnement sans experts, on n’a d’autre choix que de devenir soi-même l’expert.
Bien sûr, je me dis aussi que j’aimerais exercer un autre type de leadership que le leadership technique, mais dans la réalité, quand on se retrouve avec des coéquipiers qui ne partagent pas facilement, même cela devient difficile, donc j’ai l’impression que cela dépend de la situation.
C’est une belle perspective.
C’est comme ça qu’il faut travailler.
Avis Hacker News
En tant que leader d’équipe, j’essaie d’éviter autant que possible les décisions du type « je suis le lead, donc on a décidé de faire comme ça », mais j’insiste sur le fait qu’il faut savoir y recourir sans hésiter quand c’est nécessaire. Je prends le temps d’écouter tout le monde et de décider avec soin, mais j’ai réalisé qu’en tant que leader, je dois remettre de l’ordre quand l’équipe s’enlise dans des débats sans fin sur des détails non essentiels. Cela me fait repenser à cette phrase attribuée à Steve Jobs : « si vous voulez rendre tout le monde heureux, ne soyez pas leader, vendez des glaces ». Une fois ce genre de situation passé, il est essentiel de reconstruire la confiance et d’expliquer à l’équipe pourquoi il a fallu agir ainsi
J’ai moi aussi appris cette leçon dans la douleur. Quand je suis devenu manager pour la première fois, je pensais naïvement qu’on pourrait toujours obtenir un consensus et que l’équipe finirait naturellement par s’aligner. Ça a marché au début dans une excellente équipe, mais ensuite je me suis retrouvé avec des ingénieurs qui s’accrochaient uniquement à des méthodes vieilles de 25 ans venant d’autres équipes, et j’ai perdu beaucoup trop de temps à attendre un terrain d’entente. J’ai fini par comprendre qu’une fois que chacun a suffisamment exposé sa position, il arrive un moment où le leader doit fixer la direction et trancher
D’après mon expérience, j’ai vécu une situation similaire après avoir travaillé plusieurs années dans une entreprise du Fortune 50. Dans un domaine avec trois personnes clés, nous étions les seuls à savoir que l’option A, séduisante en apparence, posait en réalité beaucoup de problèmes. Même en l’expliquant, nous n’avons pas réussi à convaincre l’équipe, et nous avons finalement ignoré le vote pour en parler à notre supérieur, ce qui a permis de prendre la bonne décision. J’en ai retenu très fortement que suivre l’avis majoritaire, l’option A, plutôt que la direction souhaitée par ceux qui gèrent directement les conséquences, l’option C, entraîne des problèmes et des retards persistants sur le projet. Le point important, c’est que les personnes qui assument directement la responsabilité et les conséquences doivent disposer d’un « droit de veto » plutôt que d’être soumises à un vote de popularité, sinon le projet perd tout son élan. Sur les grands projets, plusieurs leads doivent prendre les décisions dans leur domaine, et le supérieur ne devrait trancher clairement qu’en cas de blocage. Quand un leader évite de décider, tout le monde finit par se plaindre, et j’ai vu à quel point cela détruit sérieusement le moral de l’équipe
Cela me rappelle aussi l’anecdote selon laquelle Steve Jobs enfermait son équipe dans une salle jusqu’à ce qu’un projet de vision commune émerge. Amener tout le monde dans la même direction est difficile, mais en cas d’échec, la capacité d’exécution chute fortement. En même temps, si on ignore l’avis des membres de l’équipe, ils auront le sentiment d’être ignorés ; même si le résultat compte, ce n’est pas une manière durable de fonctionner
J’ai trouvé très marquante la différence entre « écouter la voix de chacun » et « donner un droit de veto à tout le monde ». En tant que leader, mettre fin à une impasse fait partie du rôle essentiel. Bien sûr, si le leader doit décider sur tous les sujets, c’est probablement le signe d’un problème de management, de motivation, ou du fait que l’équipe ne comprend pas la stratégie
La méthode que je préfère consiste à dire : « Si c’était toi qui en étais responsable, quelle décision prendrais-tu ? Fais-le-moi savoir. » Le rôle du leader n’est pas toujours de prendre lui-même la décision, mais de faire en sorte qu’une décision soit bel et bien prise
Je pense avoir un peu d’expertise sur ce sujet. J’ai autrefois été nommé à la tête d’un projet qui avait déjà échoué trois fois, avec six des meilleurs ingénieurs issus de chaque équipe. Tout le monde avait des opinions très arrêtées et des raisons solides, mais, en reprenant l’idée de « ne gênez jamais un ennemi qui est en train de faire une erreur », j’essayais d’adopter une posture du genre : « n’interrompez pas un collègue quand il est en train de faire quelque chose d’excellent ». L’attitude était : « si ce n’est pas ta partie, construis autre chose dans laquelle tu peux exceller ». Nous avons réparti les rôles assez naturellement, nous nous sommes influencés mutuellement avec souplesse, et nous avons accepté que les parties moins importantes ne soient pas parfaites. Au final, cela a bien fonctionné, et je suis très fier d’avoir contribué à une structure dans laquelle plusieurs personnes talentueuses apprennent les unes des autres et ne concentrent leur énergie que sur les points qui exigent de vrais débats
J’ai l’impression que votre expérience ressemble à ce qu’on appelle le Servant Leadership (lien Wikipédia associé). C’est aussi un style de leadership que j’apprécie
Je pense qu’il faut une vraie confiance, de la retenue et de l’assurance en tant que leader pour laisser d’excellents ingénieurs développer leurs idées de manière autonome, sans intervention excessive
Chaque fois que l’équipe produit demande une fonctionnalité « simple », je pense immédiatement au fait qu’il faudra au moins trois équipes et des mises à jour de leurs microservices respectifs. Sous cet angle, les systèmes web modernes me dépriment parfois vraiment
À mon avis, le problème n’est pas tant le web moderne lui-même que l’architecture dans laquelle une fonctionnalité « simple » dépend de trois microservices distincts avec des dépendances éclatées. Au fond, c’est surtout un échec de conception du système
Dans ce cas, je me demande quelles seraient les autres alternatives
D’après mon expérience, il vaut mieux éviter de dire « je suis le lead », parce que cela peut donner une impression de manque de confiance en soi. Il faut plutôt être capable, une fois toutes les informations réunies et la décision prise, de dire avec assurance : « bon, maintenant on va faire comme ça » ou « j’aimerais qu’on fasse comme ceci »
Le cœur du problème n’est pas l’incompréhension, mais le manque de confiance mutuelle. Si une équipe dit qu’une tâche prendra deux semaines, une autre va penser qu’elle pourrait la faire en une journée et ne lui fera pas confiance. S’il y avait suffisamment de confiance, on accepterait que l’autre équipe soit plus experte sur le sujet. Mais dans la réalité, on finit par soupçonner que l’estimation ne reflète pas le travail réel à fournir, mais une marge ajoutée pour se couvrir. Dans ces cas-là, partager suffisamment d’explications et d’éléments concrets aide à renforcer la confiance
Cela fait environ un an que j’ai été promu lead developer. J’étais un peu perdu sur mon rôle exact et mes responsabilités, mais je me sens rassuré de constater que j’ai travaillé avec des idées proches de celles exprimées dans le billet original. Il y a quelques jours, j’ai aussi lu un article intitulé « comment lire un tutoriel du point de vue d’un non-développeur », auquel je me suis beaucoup identifié, et j’ai l’impression d’aller dans la bonne direction
J’ai moi aussi connu trois cas où, dans des équipes de développement produit proches du logiciel, le lead dirigeait de manière autoritaire, et à chaque fois les résultats ont été mauvais. Après avoir moi-même dirigé quelques équipes, j’ai compris que mon rôle ne devait pas être celui d’un « commandant », mais plutôt d’un « hub et médiateur ». Quand il y a des frictions entre membres de l’équipe, j’aide à résoudre les conflits ; quand il y a des questions, j’aide à apaiser les inquiétudes ; quand une idée émerge, j’en évalue la faisabilité et la valeur ; et quand il faut des ressources, j’aide à trouver la bonne personne. En cas de problème, j’en assume la responsabilité et j’encourage l’équipe à le résoudre. Il m’a fallu plus de dix ans pour apprendre tout cela. Je ne suis pas le meilleur, et mon nom n’est connu que de peu de monde, mais en travaillant comme un « membre » de l’équipe, les résultats ont été meilleurs et le départ des talents a diminué. Et en tant que leader, je trouve vraiment important de pouvoir dire : « je ne sais pas très bien non plus, mais cherchons la réponse ensemble ». Cela permet aux experts d’avoir le droit d’être dans l’incertitude, de ne pas devenir défensifs et de sentir qu’ils ne sont pas seuls. À ceux qui se sont déjà sentis mis à l’écart ou traités comme des pièces interchangeables par leurs anciens responsables, j’aimerais dire qu’ils méritent du réconfort ; et si un leader veut accompagner durablement son équipe, il ne doit pas penser comme une machine, mais vraiment adopter une posture de soin mutuel
J’admire le fait que l’auteur ait lui-même enregistré l’audio principal de l’article
Il dit aimer l’expression « It's because that's why » et explique que, si le sujet vous intéresse, les livres de Vanessa Van Edwards lui ont beaucoup apporté pour apprendre à envoyer les bons signaux de chaleur humaine et de professionnalisme selon les situations. Une seule personne ne peut pas fournir toutes les réponses, mais il dit avoir accumulé plusieurs expériences positives
Concernant la prise de décision, je pense qu’il y a à la fois plus et moins que le simple fait de « faire en sorte qu’une décision soit prise ». D’abord, je recommande autant que possible de pousser d’autres personnes à prendre elles-mêmes la décision. À l’époque d’Apple, Jean-Louis Gassée avait l’habitude, quand des managers lui apportaient un conflit, de rendre une décision qui déplaisait aux deux parties ; ils revenaient alors avec une alternative sur laquelle ils avaient réussi à se mettre d’accord. Ensuite, il faut faire en sorte que tous les membres adhèrent réellement à la décision, en commençant par soi-même. C’est extrêmement difficile pour les managers qui changent d’avis au gré du vent. On peut prendre l’analogie avec les étudiants en droit, qui pensent de manière prudente et analytique, alors qu’un avocat doit défendre fermement une position ; il faut adopter une posture capable de convaincre tout le monde. Comme un consensus idéal n’est pas toujours possible, il peut aussi être utile de fixer un point concret, comme le client ou l’objectif de résultat, pour faire avancer la décision et entraîner son exécution