Devenir Tech-Lead : le guide de la transition

Développeur, vous étiez jugé sur vos tickets. Tech-Lead, vous êtes jugé sur la capacité de l’équipe à livrer, souvent et sans casse, pendant des années.

Votre agenda change aussi. Moins de longues plages de concentration, plus de revues, de questions, d’arbitrages et de discussions avec le produit. Beaucoup de nouveaux Tech-Leads vivent mal cette fragmentation les premiers mois ; c’est normal, et ça s’organise.

Le code reste la référence, puisque c’est lui qui tourne en production. Un Tech-Lead qui ne lit plus le code perd vite le fil.

Personne ne suit un Tech-Lead qui ne comprend pas le système. Avant la prise de poste, visez une vision de bout en bout : d’où viennent les données, qui les consomme, ce qui casse quand un service tombe.

Connaître la production compte autant que connaître le code. Savoir déployer, lire les logs, comprendre une alerte : c’est ce qui vous rend utile la nuit où tout brûle.

Le Tech-Lead tranche les choix techniques : base de données, framework, découpage en services, dette à rembourser ou à garder. La plupart de ces choix n’ont pas de bonne réponse universelle ; ils ont une bonne réponse dans votre contexte.

Une décision prise à l’oral se déforme dans les mémoires, puis disparaît. Écrivez le contexte, les options écartées et la raison du choix. Six mois plus tard, c’est ce document qui évite de rouvrir le débat.

La dette technique fait partie des décisions. Il y a celle que l’on subit, héritée, et celle que l’on choisit consciemment pour livrer plus vite. Le rôle consiste à rendre la seconde explicite et à garder la première sous contrôle.

Le réflexe du nouveau Tech-Lead est de reprendre les tâches difficiles « parce que ça ira plus vite ». Ça marche une semaine. Ensuite vous devenez le goulot de l’équipe, et personne d’autre ne progresse.

Déléguez les sujets qui font grandir, relisez sans réécrire, laissez de la place pour se tromper sur ce qui est réversible. Les entretiens individuels réguliers servent à capter les signaux faibles avant qu’ils deviennent des départs.

Adaptez le niveau de cadre à la maturité de l’équipe. Une équipe jeune a besoin de règles claires, une équipe autonome a besoin d’espace.

Un Tech-Lead passe une partie de son temps avec le produit, le commercial ou la direction. Il traduit les contraintes techniques en délais, en risques et en coûts, et il fait l’inverse pour son équipe.

Garder l’équilibre entre vision produit et vision technique est un travail continu. Et l’entreprise doit gagner de l’argent : une architecture élégante qui retarde la mise sur le marché n’aide personne.

Vous n’avez pas besoin d’attendre un poste ouvert pour vous entraîner. Prenez ces responsabilités une à une dans votre équipe actuelle :

• rédigez la prochaine décision d’architecture avec son rationnel ;
• préparez l’accueil du prochain arrivant ;
• transformez une convention orale en règle vérifiée par la CI ;
• remontez un problème récurrent jusqu’à sa cause, plutôt que de le contourner une fois de plus.

Une fois en poste, commencez par écouter et cartographier avant de changer quoi que ce soit. Les premières semaines servent à comprendre pourquoi les choses sont comme elles sont.

• Rester le meilleur développeur de l’équipe et garder pour soi les tâches clés : l’équipe stagne et vous saturez.
• Décider seul et à l’oral : chaque nouvel arrivant rouvre le sujet.
• Garder le contexte pour soi : la plupart des frictions entre personnes qui partagent les mêmes objectifs viennent d’un écart d’information.
• S’épuiser : le rôle se tient sur des années, il se gère comme un marathon.