Table of Contents
Table des Matières

8000+ personnes ont trouvé leur job sur talent.io

Nous serions ravis de t’aider à trouver le job que tu mérites ! Pas de spam, juste des offres sur-mesure qui correspondent au rôle et au salaire que tu recherches.

S'inscrire

C’est une question qui revient inlassablement chez les devs’ : est-ce que je dois forcément manager une équipe pour progresser dans ma carrière ?

À quoi ressemblera mon quotidien si je deviens manager ?

Et est-ce que je vais continuer à coder ?

Etc, etc.

Ces questions, on les a posées à 2 Team Leads, qui se sont eux-mêmes posé ces questions avant de passer de contributeur individuel à Team Lead.

Ils vont te livrer leur retour d’expérience de la manière la plus sincère possible.

Leurs succès, leurs déceptions, et ce qu’ils auraient aimé savoir avant de prendre un poste de Team Lead.

Tu vas notamment voir que, malgré leur titre similaire, leur quotidien et leurs envies sont assez différentes.

🤔 Déjà, c’est quoi concrètement un Team Lead ?

Commençons par le commencement.

Le Team Lead est là pour assurer le delivery de son équipe.

Qu’est-ce que ça veut dire ?

Prenons un exemple classique : une nouvelle feature doit être lancée.

Le Team Lead va devoir imaginer la roadmap qui va permettre l’implémentation de cette nouvelle feature : par où on commence ? Qui fait quoi ? Quelles étapes ? Quelle timeline ? Comment on mesure le succès ?

Concrètement, il est responsable que chaque projet sur lequel travaille son équipe soit livré en temps et en heure, de la manière la plus efficace possible.

Il découpe ces projets en tâches, qu’il ordonne et assigne aux membres de son équipe.

Il fait en sorte que les projets avancent correctement en définissant :

  1. Des méthodes de travail (Scrum, Kanban etc.)
  2. Des cadences d’avancement des projets (standups, weekly etc.)
  3. Des metrics pour mesurer le succès et l’efficacité de l’équipe (ex : cycle time)

Pendant toute la durée du projet, il est en support de son équipe et doit prendre des décisions quand les choses ne se passent pas comme prévu.

(Et l’expérience montre que le déroulement d’un projet se passe rarement 100% comme prévu 😅)

Bon, une fois qu’on a donné cette définition (assez large) du rôle, passons à ce qui nous intéresse le plus : le retour d’expérience de Vivien et Gonzague.

🎯 Devenir Team Lead : un choix pour Vivien

Vivien insiste là-dessus : devenir Team Lead, c’est un vrai choix à faire, et pas simplement une voie par défaut pour progresser dans sa carrière.

“J’avais vraiment envie de devenir Team Lead chez PlayPlay parce que c’est la gestion de projet qui m’intéresse le plus. Je l’ai dit aux managers, et ensuite j’ai dû montrer que j’en étais capable, m’améliorer sur pas mal de points. Ça a pris environ 1 an et demi entre le moment où j’ai fait part de ma volonté et le moment où j’ai eu le rôle.”

Un choix certes, mais qu’il faut faire pour les bonnes raisons :

“En fait ce qu’on veut tous c’est évoluer, avoir de la reconnaissance. Mais ce besoin de reconnaissance peut t’amener à vouloir devenir Team Lead, alors que ce n’est pas vraiment le métier que tu veux faire. Si t’es passionné·e de code, tu seras peut-être frustré·e car tu vas beaucoup moins coder. Il faut bien garder en tête que l’évolution vers Team Lead n’est pas une fin en soi, tu peux aussi continuer sur la voie de contributeur individuel.”

‍

💡 2 conseils pour toi ici :
  • Avant de foncer tête baissée vers la voie du management, réfléchis bien à ce que tu as envie de faire et ce qui t’anime : gestion de projet/management vs technique
  • Si tu as envie de devenir Team Lead, dis le ! Ça paraît bête, mais c’est une étape importante de partager son ambition à son manager.

🧩 Devenir Team Lead : une opportunité pour Gonzague

Pour Gonzague, la situation était différente.

Il était contributeur individuel chez talent.io, et a choisi de tenter l’aventure de Team Lead chez Shopmium, même si ce n’était pas forcément le plan de carrière qu’il avait imaginé :

“Moi je ne cherchais pas forcément à être Team Lead à la base.
J’avais plutôt envie de faire de l’architecture tech plutôt que du management. Mais le rôle de Team Lead qu’on m’a proposé chez Shopmium était très hands-on. C’est ce qui m’a convaincu de tenter le coup !”

👇 Pas d’inquiétude, on t’explique ce que signifie “hands-on” dans quelques secondes.

Du coup, Team Lead = arrêter de coder ?

Eh bien : pas forcément.

En discutant avec Vivien et Gonzague, on s’est aperçu d’une chose : leur quotidien est assez différent.

L’exemple le plus parlant ? Le temps qu’ils passent à coder :

D’un côté Vivien ne code quasiment plus, de l’autre, Gonzague passe la moitié de son temps à coder.

Pourquoi cette différence alors que, sur le papier, ils ont le même job ?

La raison est assez simple : en réalité, ils n’ont pas vraiment le même rôle.

Oui, ils sont tous les deux Team Leads.

Oui, ils ont tous les deux les mêmes objectifs : assurer l’avancement des projets, et maximiser l'efficacité de leur équipe.

Mais c’est la manière d’atteindre ces objectifs qui est différente : Gonzague est un team lead hands-on, Vivien plutôt un team lead hands-off.

Hands-on et Hands-off, ça veut dire quoi ?

Pour faire simple :

Hands-on = tu continues à mettre les mains dans le code.

Hands-off = tu ne codes quasiment plus, tu te consacres surtout à la gestion de projet et management.

Quelles différences entre hands-on et hands-off au quotidien ?

Gonzague, qui continue à coder, est un team lead “hands-on” :

“Je passe beaucoup de temps à écrire des guidelines tech pour mon équipe, c’est un peu du code à trou en quelque sorte. Je fais aussi pas mal de review de code, et de recherche technique. Le reste du temps (environ 30% de mon temps), je prépare les weekly, retro, et 1:1s. ”

Vivien, lui, dans les faits, est plutôt un team lead “hands-off” :

“Mon rôle est avant tout de définir les priorités et les objectifs dans l’équipe mais aussi avec les autres équipes. Organiser les sprints, définir et mesurer les metrics, et m’assurer que tout va bien dans l’équipe. Ça passe par préparer les 1:1s, les weekly, etc. En fait, le management et la gestion de projet me laissent assez peu de temps pour coder.”

On le voit bien ici, Vivien et Gonzague ont tous les deux un rôle de planification et d’organisation. Ils vont aussi reporter tous les deux à leur manager.

Mais c’est bien dans l’exécution que la différence se fait, Gonzague étant plus investi dans le code et la technique, quand Vivien l’est davantage sur l’aspect process et management.

Donc être Team Lead “hands-off” = être tout le temps en réunion ?

Pas tout le temps… mais souvent.

C’est un rôle où tu peux avoir beaucoup d’échanges, de synchronisation, et forcément de réunions (là où le Team Lead hands-on aura généralement davantage de temps seul).

D’ailleurs Vivien prévient que ce rôle n’est pas fait pour tout le monde :

“Je trouve que c’est un rôle où il faut pas mal de soft skills : il faut avoir de bonnes capacités de communication, savoir trancher, ne pas avoir peur du conflit. T’es un peu le tampon entre ton équipe, ton manager, et les autres équipes. Il faut y être prêt.”

Et comment je choisis si je suis hands-on ou hands-off ?

Le fait de continuer à coder en tant que team lead dépend généralement de 2 paramètres :

  1. Ton envie
    Est-ce que tu as envie de continuer à beaucoup coder comme Gonzague vs être dans la gestion de projet de A à Z comme Vivien ?
  1. La taille de ton équipe et de ton entreprise
  2. Être hands-on ou hands-off ne dépend pas que de ton envie, mais aussi de la structure de l’équipe et de l’entreprise, comme le spécifie Gonzague :
  3. “De mon côté, je manage 2 personnes, donc c’est assez logique et simple de continuer à coder. C’est plus compliqué quand tu as 10 personnes dans ton équipe, puisque tu passeras beaucoup plus de temps sur la coordination et les process.”
  4. Vivien, qui doit gérer la roadmap de 4 personnes, a moins de temps pour coder, et davantage de points de synchro. Avec son équipe, mais aussi avec les autres équipes, notamment le produit et l’équipe QA.

💡 Notre conseil : si tu es en process pour devenir Team Lead, pose la question du temps que tu passeras à coder, pour être sûr que ça te convient. La taille de l’équipe que tu vas leader te donnera aussi une bonne indication !

‍

Les difficultés du rôle

Pour terminer, on a voulu en savoir plus sur les parties un peu plus difficiles du rôle en leur posant cette question :

Est-ce qu’il y a des aspects que vous trouvez difficiles dans le rôle ?

On leur laisse la parole 👇

Vivien :

  1. Rester à jour techniquement
    C’est pas simple, surtout quand on ne code quasiment plus comme moi. J’aimerais me bloquer une demi journée ou une journée par semaine pour prendre des tickets, c’est le meilleur moyen de rester à jour.
  1. Le temps d’attente des résultats
    Quand t’es dev’, tu prends un ticket, tu le développes, il est en prod’. L’impact est quasi immédiat. Quand t’es team lead l’impact est plus long terme. Si tu testes un nouveau process dans l’équipe, tu ne verras les résultats que dans plusieurs semaines. Il faut s’adapter à cette nouvelle temporalité, et c’est pas forcément facile au début.
  1. Gérer les demandes de toutes les équipes
    🚗 Prenons un exemple avec la métaphore d’une voiture
  • Le produit te dit : il nous faut une voiture.
  • Tu vas voir les équipes dev’ et tu leur dis : il nous faut une voiture, donc le moteur, les roues, la carrosserie, etc. Tu te rends compte que ça va prendre environ 6 mois.
  • Le produit te dit : 6 mois impossible, on a que 3 mois.
  • En même temps, l’équipe Customer Success te dit : nous, il nous faut une voiture, mais à 3 roues, sinon ça ne fonctionne pas pour les clients.

Du coup tu te retrouves à jongler pour trouver une solution pour construire une voiture, dans le temps imparti, qui convienne à tout le monde et qui fera quand même le job de rouler. En général ça se passe bien, mais c’est pas tout le temps facile.

Gonzague :

  1. Au début : la légitimité
    Je suis arrivé dans une nouvelle boite, donc forcément au début il y a un petit temps d’adaptation. Les personnes de mon équipe allaient plutôt poser leurs questions à leur ancien manager (qui était devenu mon manager). Mais petit à petit, tu montres que tu sais de quoi tu parles, et les choses rentrent dans l’ordre.
  1. Reprendre la codebase existante et la faire évoluer
    Quand tu arrives en tant que Team Lead, tu reprends la codebase existante et tu dois comprendre les choix qui ont été faits durant les dernières années.
  2. Le plus compliqué est de faire évoluer les pratiques. Il faut arriver à montrer l’utilité des changements que tu proposes, pour le bien de l’équipe.
  3. Rester à jour techniquement
  4. Même si je code régulièrement, je dois être le mieux informé possible pour adopter les meilleures pratiques à l’échelle de l’équipe. Je conseille de discuter avec des tech d’autres boites, qui utilisent d’autres stacks, pour rester à jour au maximum de ce qui se fait (et Twitter, évidemment).
No items found.