Je vois régulièrement des gens se voir proposer la casquette de lead, pour des bonnes ou des mauvaises raisons, dans des contextes bons ou moins bons, etc. Je vois aussi régulièrement des gens s'interroger sur le rôle, de s’ils sont prêts, de se dire qu'ils n'en sont pas capables, que ça leur fait peur, etc. Et c'est normal de se poser ce genre de questions, c'est même plutôt sain à mon avis, on est beaucoup à être passé par là ! Je vois aussi beaucoup de confusion sur le rôle du lead avec en plus des confusions entre lead dev et lead tech (les dénominations changeant entre les entreprises, ça n'aide pas…).

Lead = leader = chef ?

J'ai vu des leads qui agissaient comme des chefs dans les équipes de développement. Être lead ce n'est pas être chef pourtant…

Être lead dev c'est avant tout être développeur dans l'équipe, vous n'avez pas un rôle hiérarchique ou pilotage supérieur au reste de l'équipe. C'est important de comprendre ça. On peut vous demander de participer à des activités de pilotage, mais vous serez là pour représenter les développeurs de l'équipe pas décider pour eux à leur place.

J'aime à dire que "lead" ce n'est qu'une casquette que vous prenez pour être identifié à la fois par les développeurs de l'équipe comme "référant", par les autres équipes comme "point d'entrée" et par le management/métier/pilotage comme un représentant de l'équipe.

Pareil, j'ai aussi vu pas mal d'organisation où on considérait le rôle de lead comme une promotion, une étape obligatoire du parcours de dev pour évoluer dans sa carrière, voir au niveau salarial. C'est à mon sens une idiotie. Une équipe de dev comprend beaucoup plus de développeur que de lead, fonctionner comme ça fait qu'automatiquement les plus anciens vont tendre vers le fait de devenir lead (ou partir s'ils n'acceptent pas la casquette...), et donc subir le rôle, ne pas être forcément des bons leads, ce qui ne va pas aider l'équipe (même parfois la freiner), alors que la personne aurait pu être parfaitement à sa place avec une autre personne en tant que lead.

Lead = Référant des développeurs

Comme je le disais juste avant, le lead dev est avant tout un référant dans l'équipe. Quand je dis "référant" c'est au sens où c'est à vous d'être à l'écoute des autres développeurs pour les débloquer, les aiguiller, avoir une vision un peu plus large et long terme, accompagner tout le monde et faire en sorte que tout se passe bien.

Votre rôle n'est pas de porter le projet, de tout faire, de tout savoir, de distribuer le travail. Et vous ne voudriez pas avoir ces missions à mon avis, car ça voudrait dire que vous portez seul toute la responsabilité, que vous allez vous épuisez à la tâche, que vous aurez continuellement besoin savoir qui fait quoi et que les autres développeurs risquent de quitter vite l'équipe parce qu'ils se sentiront étouffés.

Vous n'avez pas besoin de tout savoir pour être un bon lead, vous avez besoin de méthode pour plutôt rapidement trouver l'information qu'il vous faut. Que ce soit en étant un expert en recherche Google, en connaissant l'organisation du Confluence interne sur le bout des doigts (l'organisation pas le contenu), que vous ayez des notes parfaitement organisées, peu importe le comment : vous avez assez de recul et d'instinct pour débloquer un peu tous les cas (avec plus ou moins de difficulté), et aider les autres à ne pas perdre trop de temps.

Vous serez aussi un canard. Parfois simplement le fait qu'on vous explique/montre le problème, fera que l'autre personne va trouver toute seule la solution, vous aurez à peine compris le cheminement, mais c'est pas grave à mon avis. Ce qui compte c'est que l'équipe avance.

J'aime à dire qu'être lead c'est avoir des responsabilités envers l'équipe : vous êtes là pour aider tout le monde à travailler de manière fluide.

lead = représentant de l'équipe

Côté pilotage le lead dev est souvent pris comme représentant des autres développeurs. C'est logique à mon sens. Sans être celui qui commande les développeurs, le lead a souvent les mains dans le code, il a tendance à entendre en direct tous les soucis des développeurs, il a tendance à avoir une vue sur tout le projet sans forcément avoir fait les choses lui-même, c'est donc logique qu'on demande son avis quand on veut aller vite.

Passer par un représentant comme ça permet d'avoir une seule voix auprès du métier / pilotage. Ça permet aussi aux autres développeurs de faire peu de réunion et de se concentrer plus sur la production. En général une seule personne comme pont permet d'être efficace, et suffit largement à faire passer tous les messages dans les deux sens.

Par contre je reste sur mon avis : ce n'est pas au lead de décider pour tout le monde. En cas de doute, le lead peut totalement demander son avis à un autre développeur de l'équipe voir toute l'équipe. Encore une fois le but d'avoir un lead comme représentant c'est de permettre de fluidifier le travail avec le métier / le pilotage, pas couper les développeurs du reste du monde et donc des infos.

Lead = point d'entrée

Du point de vue extérieur à l'équipe, le lead est souvent le bon point d'entrée pour avoir une information technique. Que ce soit comment démarrer le projet, comment y accéder, comment fonctionne telle partie, le lead est le bon interlocuteur pour avoir un coup de main pour comprendre les pratiques de l'équipe de développement.

Par contre comme ce n'est pas lui qui a tout fait ni à lui de tout faire, c'est aussi au lead de s'assurer de faire passer les besoins extérieurs dans les priorités de l'équipe pour que ça puisse être repris par quelqu'un d'autres de l'équipe si c'est légitime (potentiellement après échange avec les POs). En particulier en cas de service non fonctionnel, à priori ce n'est pas le lead qui doit forcément réparer, par contre c'est la bonne personne à contacter pour valider la source du problème.

Ce n'est pas une question d'expérience

Le rôle de lead n'a pas de raison a être attribué en fonction de l'age, de l'ancienneté en tant que développeur, dans l'entreprise ou sur le projet.

Si vous avez suivi ce que je vous explique depuis le début de l'article, le lead est quelqu'un qui a des compétences humaines en plus de technique pour savoir jongler entre les devoirs envers l'équipe (accompagnement, animation, support), le métier / pilotage (représentant) et l'extérieur (point d'entrée) pour permettre à l'équipe de vivre tout en étant un moteur général du système.

Je pense que quelqu'un sortant tout juste de formation est peut-être trop jeune d'un point de vue maturité sur comment fonctionne le milieu du développement (et encore, ça reste pour moi du cas par cas), mais je ne m'aviserais pas à donner un nombre d'année pour avoir le bon mindset et la bonne posture pour être lead. Pour moi ça dépend complètement de chaque personne, certains en seront capables très vite, certains n'auront jamais la bonne posture.

Encore une fois, ce n'est pas une promotion ou une étape obligatoire d'être lead. C'est un rôle différent dans la création d'un produit tech, dont on peut même se passer à partir d'une certaine maturité / autonomie d'équipe à mon avis. Je ne me verrai pas forcément la main à quelqu'un pour prendre une casquette de lead.

Lead dev vs Lead tech ?

Lead dev, lead tech, tech lead, etc. appelez ça comme vous le voulez, mais il existe pour moi deux rôles que je vais appeler : lead dev et lead tech.

Le lead dev c'est le profil dont je parle depuis le début de l'article : c'est un animateur d'équipe qui doit faire en sorte que tout le monde avance, que tout soit fluide, parfois en allant chercher des solutions ailleurs.

Le lead tech c'est un expert technique. Son rôle est souvent de maitriser la stack du projet et suivre son évolution, les sujets techniques complexes parfois en avance de phase, pour s'assurer que tout se passe bien côté technique. Le lead dev et le lead tech vont souvent être très proches car beaucoup besoin l'un de l'autre pour travailler. Au point où certaines entreprises vont fusionner les deux rôles ou confier aux lead tech le rôle de lead dev aussi mais implicitement.

Pour moi c'est bien des rôles différents qui se complètent et c'est souvent une charge qu'il est plus efficace de partager à deux pour pouvoir maintenir un certain niveau de production à côté. Quand on porte les deux casquettes, on se retrouve vite saturé de sujets dans tous les sens qui ne permettent pas d'affronter de front même un sujet correctement.

Quelques conseils de lead à lead

À force de porte la casquette de lead dev, j'ai compris des choses, et j'aurais aimé avoir intégré certains bien plus tôt pour relâcher la pression, donc je partage ça un peu en vrac ici.

Le lead n'est pas celui qui sait tout, vous avez tout autant droit que les autres dev de vous tromper / ne pas savoir. Vous êtes un humain au même titre que toutes les personnes de l'équipe et les humains se trompent, c'est normal.

Le lead n'est pas non plus celui qui connaît le projet sur le bout des doigts. Au contraire, c'est parfois une des personnes qui maîtrise le moins les détails techniques du projet. Je n'ai pas honte de dire, même dans mes équipes, qu'ils connaissent souvent mieux le projet que moi et que je leur fais confiance pour me dire quand je me trompe sur ma vision des choses !

Quand vous êtes lead, vous devez gérer l'interruption. Entre les autres développeurs qui ont besoin de vous, les questions des métiers / du pilotage, les réunions, etc. vous allez avoir moins de temps pour développer. C'est normal et pourtant un peu frustrant. On gère d'autres choses donc c'est logique qu'on produise moins qu'avant, et on doit vous dégager du temps en tant que lead pour faire ces choses efficacement. Par contre il faut aussi avoir un certain recul et une certaine organisation pour être productif quand même. Se bloquer du temps explicitement dans son agenda, faire du pomodoro, refuser complètement les appels / réunions sur des demis-journées, savoir dire "non, on en parle demain, là tout de suite je veux travailler sur XXX", etc. Beaucoup de choses qui peuvent paraître compliqués mais qui s'apprennent en essayant, en trouvant où on est efficace et où on aide les autres suffisamment aussi.

On a chacun une vision du rôle de lead. Comme on a tous un vécu, nos expériences (bonnes comme mauvaises), nos convictions, nos compétences, c'est logique. N'ayez jamais peur de demander à d'autres leads comment gérer un cas particulier, on passe tous par des phases où c'est compliqué, c'est normal. Par contre, même si un lead que vous pensez être très bien vous donne une vision qui ne vous plaît pas (ça rompt avec vos convictions, ça vous semble injuste, etc.) ne le faites pas, et n'ayez pas honte de demander d'autres avis.

Ne pas essayer de cacher tout ce qui ne va pas à l'équipe. Ne pas non plus tout dire. Il faut pour moi trouver un juste milieu entre être transparent et préserver l'équipe. J'ai pour principe d'essayer d'être transparent au maximum quand je suis sûr des infos que j'ai. Je veux que les gens me fassent un minimum confiance, et ce n'est pas en leur cachant tout ou en édulcorant la réalité que ça pourra se faire. Par contre j'ai appris à attendre un peu pour donner des informations que je pense non sûres pour être certain de donner la bonne information.

Ne centraliser l'attribution du travail. Vous n'avez pas besoin d'avoir un rôle de distributeur de travail, et ce n'est de toutes façons pas le rôle d'un lead dev : dans une équipe qui fonctionne bien, chacun prend sa part du travail à faire et on avance avec du dialogue. De plus, en tant que lead dev, on a toujours beaucoup de choses à gérer, donc centraliser l'attribution des tâches serait une erreur, car on coupe l'autonomie saine des différent·e·s développeurs·euses ce qui va vous placer en SPOF (Single Point Of Failure) et vous ne pourrez même plus partir en vacances sans que tout soit bloqué.

Il peut arriver qu'en tant que lead j'ai demandé à un·e dev de l'équipe de prendre spécifiquement une tâche, pour des questions de délai / d'organisation / de manque de temps à le faire moi-même du fait que j'avais d'autres choses à traiter aussi urgente, dans ce cas à mon avis, la bonne manière faire c'est d'être transparent sur pourquoi on demande à la personne de faire cette tâche, on lui ouvre une porte sur le fait de refuser, et comme soyons honnête c'est rarement les tâches les plus funs, je l'accompagne toujours par une priorité pour choisir la tâche suivante et/ou pré-réserver un ticket pour compenser.

Vous allez vous planter. (ça me rappelle un autre article que j'ai écrit tient…) C'est normal, c'est ça être un humain. Mais ne cherchez pas à être le "lead parfait qui sait tout et ne se plante jamais". Au contraire : si vous vous plantez, montrez-le directement au reste de l'équipe, expliquez l'erreur, faites-en quelque chose de pédagogique, ça vous aidera à créer un cercle vertueux et d'apprentissage continu.

Conclusion

Je pourrais écrire encore longtemps des conseils sur comment à mon sens être un bon lead dev, mais je vais m'arrêter là. Déjà parce que je vous ai déjà assez soulé avec mon avis. Ensuite parce que ce n'est pas mon avis qui compte, c'est bien que vous construisiez le vôtre, que vous forgiez votre vision du rôle de lead dev, rôle dans lequel vous serez à l'aise et qui vous fera vous lever le matin dans la joie et la bonne humeur.

Ou peut-être que cet article vous aura fait prendre conscience que vous n'êtes pas fait pour ça, que coder c'est ça qui vous éclate, que vous ne voulez surtout pas rentrer dans un rôle comme celui de lead dev. Et vous avez potentiellement raison ! Pour moi la seule erreur serait de se dire que vous n'êtes pas fait pour ça parce que vous vous comparez à d'autres qui vous semblent meilleurs que vous : vous n'êtes pas les autres, vous êtes vous, et c'est largement assez !

Parfois on est dans un cadre sain, parfois on sait qu'on est entouré de gens bienveillants, parfois tout le monde croit en notre capacité à faire quelques choses, parfois on en a envie aussi, mais on a peur de se lancer. Si tout est réuni comme ça, posez-vous la question "il me faudrait quoi de plus pour être à l'aise de passer lead ?".

Je vais ajouter un dernier conseil à ceux qu'on essaie de forcer la main à devenir lead : si vous n'en avez pas envie, dites non. C'est un rôle qui implique des contraintes, un peu de pression / stress, des responsabilités, une redevabilité. Ce n'est pas un rôle qu'on peut faire par obligation.

Source :

Crédit photo : Générée via Mistral AI avec le prompt suivant

L'image montre un pont élégant et moderne s'étendant entre deux rives, symbolisant la connexion et la communication. D'un côté du pont, un groupe de développeurs est représenté, travaillant ensemble sur des ordinateurs et des tableaux blancs remplis de code et de diagrammes techniques. Ils semblent engagés et concentrés sur leur travail.

De l'autre côté du pont, divers groupes de personnes représentent les autres parties prenantes : des membres du management en costume, des équipes métier avec des graphiques et des plans, et des clients discutant autour d'une table. Ces groupes symbolisent les différentes parties prenantes avec lesquelles l'équipe de développement doit interagir.

Au centre du pont se tient une figure symbolisant le lead. Cette personne est représentée avec des caractéristiques qui évoquent la confiance, l'écoute et la médiation. Elle porte une tenue qui est un mélange de celle des développeurs et des autres parties prenantes, illustrant son rôle de pont entre les deux mondes. Le lead a une main levée en signe de communication et de facilitation, et semble écouter attentivement les deux côtés.

Autour du lead, des icônes et des symboles flottent, représentant les différentes responsabilités du lead : un bouclier pour la défense des intérêts de l'équipe, une balance pour l'équilibre des objectifs, une ampoule pour les idées et l'innovation, et des mains serrées pour la médiation et la négociation.

Le ciel au-dessus du pont est clair et ensoleillé, symbolisant un environnement de travail positif et collaboratif. Sous le pont, une rivière calme coule, représentant la fluidité et l'harmonie dans les échanges et la communication.

Des éléments de transparence et de confiance sont également illustrés par des lignes de communication visibles reliant les développeurs et les autres parties prenantes, passant par le lead au centre du pont.