Le rôle de Tech lead selon Damien Beaufils d’OCTO Technology

Pour la sortie de notre Parcours Tech lead, nous avons rencontré Damien Beaufils, développeur et consultant chez OCTO Technology. Damien occupe aussi notamment le rôle de Tech lead sur des projets de développement.

Nous avons posé à Damien des questions pour vous aider à mieux voir ce qu’est, en pratique, le rôle de Tech lead : comment on s’y forme, quels en sont ses avantages et inconvénients, ses missions principales et ses responsabilités.

Qu’est-ce qui t’a amené à être développeur chez OCTO et Tech lead ?

J’ai eu un parcours hétéroclite pendant mes études d’Informatique (je suis passé par un IUT, la Fac, et une école d’Ingénieurs). Cela fait dix ans que je développe. Dans l’une de mes premières entreprises, Backelite, je développais en Java, et je suis vite passé Lead Dev. À un moment, j’ai vu ma courbe d’apprentissage ralentir : j’ai alors pris mon emploi actuel chez OCTO Technology, il y a 5 ans.

Que fais-tu chez OCTO ?

Comme “consultant” chez OCTO, mes anciens collègues se sont dit que j’allais moins développer. Tout faux ! Je me suis pris une claque parce que je n’étais plus le plus “senior”, certains développeurs avaient 15 ans de bouteille. J’avais à nouveau de beaux challenges. Et je fais 90% de développement. J’ai également le rôle de Tech lead, notamment sur le projet sur lequel je suis en ce moment, où j’accompagne trois autres développeurs.

J’appartiens à la tribu “Software Craftsmanship”, une communauté de pratiques spécialisée dans la qualité du développement. Nous aidons nos clients à produire des logiciels de meilleure qualité. En plus de mon rôle de Tech lead, j’anime des formations sur la pratique TDD (Test Driven Development). Brièvement, cette pratique consiste en sécuriser le code en le testant avant d’écrire l’implémentation, pour prévenir les bugs, et pouvoir le mettre à jour facilement.

Qu’est-ce qu’un bon Tech lead  ?

Un Tech lead, c’est la personne qui prend le rôle de responsable de la qualité logicielle sur un projet. Pour moi, ce n’est pas la même chose qu’un Lead Dev, qui est un expert sur une techno. Du coup, il peut y avoir plusieurs Lead Devs sur un projet, là où il n’y a généralement qu’un Tech lead, sauf équipe nombreuse. Ce n’est pas non plus le même rôle que le CTO (Directeur Technique en Français), qui lui a la responsabilité globale de toute la tech, et des responsabilités juridiques et administratives.

Un bon Tech lead a les 4 facettes suivantes :  

L’expertise technique.

• Il faut que tu passes au moins 30% de ton temps à coder avec l’équipe, car si tu codes moins d’1/3 de ton temps, tu ne sentiras pas le projet de l’intérieur, tu seras en décalage avec l’équipe et ne pourras pas l’aider. C’est aussi à toi de porter la vision technique du produit !

La capacité à former.

• Ton objectif, c’est de faire progresser chaque membre de l’équipe, techniquement comme humainement.  Cela peut être juste par de l’écoute, des réponses aux questions, de l’aide, du travail en binôme, des formations au bon moment. Nous, on a une heure de rétrospective technique hebdo, où on partage notre veille, et où l’on se met à jour !

L’aptitude à faciliter, interagir.

• Comme un scrum master, tu fluidifies la communication tant avec les devs qu’avec les équipes qui gravitent autour.

L’aptitude à mener son équipe vers l’excellence.

•  Pour cela, il faut les accompagner au quotidien et soulever les points qui suscitent les bons questionnements.

Le parcours d’OpenClassrooms vous donnera autant les compétences techniques que la capacité de manager, gérer les projets, recruter et former. Dans le Projet 4, par exemple, vous apprenez à organiser votre équipe Tech. Il y a un cours sur le leadership, un sur le sourcing et un sur la sélection des meilleurs candidat·e·s !

Quelles sont les compétences clé pour être Tech lead ?

C’est plus important d’avoir des soft skills que des hard skills : tu fais partie de l’équipe, et codes avec elle, mais il faut que les autres aient envie de te suivre. La posture est donc plus importante que l’expertise.

Il faut savoir notamment prendre la parole en public, faire des feedbacks et être l’interface entre le client et l’équipe au global (et pas uniquement les développeurs).

Et du côté technique, il faut quand même, évidemment, au moins avoir un domaine d’expertise, pour assurer sa légitimité.

Comment t’es-tu formé ? Qu’est-ce qu’une bonne formation Tech lead doit comporter ?

Pour moi, il y a deux canaux principaux pour acquérir les compétences nécessaires :

Lire. 

• Par exemple The Software Craftsman de Sandro Mancuso ou Becoming a technical leader de Gerald Weinberg. La plupart des bons livres sont en anglais. D’ailleurs, si vous vous intéressez au développement et au rôle de Tech lead, j’ai participé à l’écriture du livre blanc Culture Code, que vous pouvez télécharger ici.

Avoir des mentors.

• J’ai pu progresser parce que j’ai vu ce que c’était d’être Tech Lead, et j’ai suivi l’exemple. Si tu n’as pas de mentor, il reste que les formations. Ou à la rigueur les meetups et les conférences. Mais un mentor, c’est plus direct et efficace.

Est-ce que tu penses que quelqu’un peut se reconvertir en Tech lead ?

Pas si l’on n’a rien à voir avec les études en informatique. Il faut quand même avoir de la légitimité, de la technique, en plus des skills de management, de négo et de gestion de projet. Mais si on est développeur·se, oui !

Pourquoi manque-t-on cruellement de Tech leads ?

On manque de développeur·se·s avec une vision panoramique. Sur le produit, sur la technique, et facilitateurs sur un projet et dans la relation client.

C’est difficile d’avoir les compétences pour argumenter et négocier avec le client. Les clients nous disent toujours qu’ils veulent un logiciel nickel chrome, mais c’est plus compliqué de leur expliquer que “pour avoir zéro bugs”, il faut (entre autre) faire des tests.

Alors, je leurs fais comprendre que la “perte de temps” à tester sera en réalité un gain considérable de temps et d’argent dans la maintenance du logiciel. Généralement, je leur cite les étude réalisées par Capers Jones sur les pratiques telles que le TDD sur plusieurs milliers de projets : il a mesuré que ces pratiques réduisent de 50% le temps nécessaire en phase de TMA (la maintenance) et que les équipes qui pratiquent la revue du code réduisent de 60% le nombre de bugs en production.

Quelles sont les trois choses que tu fais tous les jours ?

1) Coder. C’est important, au moins un tiers de mon temps !

2) Travailler en binôme. Cela peut être du peer programming avec quelqu’un, au moins à 2 voire plus sur un même écran – Je le fais souvent parce que le rôle de Tech lead amène à être interrompu, donc je me lance dans des tâches que je vais pouvoir réaliser simplement, ou je travaille à plusieurs, pour pouvoir sortir du groupe de travail sans casser la dynamique.

3) Écouter, échanger, discuter, aussi bien avec les membres de l’équipe de dev qu’avec les clients, car je suis tout pile entre les deux !

Que préfères-tu dans le fait d’être Tech lead ?

Le fait d’aider mon équipe à résoudre des problèmes complexes. J’aime ce rôle de facilitateur. Je dois faire en sorte que tout se passe bien, que mon équipe soit dans de bonnes conditions de travail, tout en satisfaisant le client. C’est vraiment un rôle positif !

Quel est le plus grand défi ?

Se préserver du temps. C’est inhérent à ce rôle, tu seras très souvent interrompu. Entre tes tâches en solo, le boulot avec le reste de l’équipe, le fait que tu sois le point d’entrée pour le client, difficile de gérer son temps !

Moi, j’essaie de travailler entre 9h30 et 18h30, et si je rentre chez moi plus tard, cela signifie que je me suis mal organisé.

En deux mots, il faut être prêt à accepter les interruptions, ne pas s’énerver. Éviter aussi de se lancer sur des tâches où tu as besoin d’être concentré 8h d’affilée sur un sujet complexe. Et surtout, savoir dire non. Répondre qu’on peut se voir, oui, mais plutôt dans une heure ou deux. On peut très souvent programmer un rendez-vous !

Comment aides-tu tes collègues à monter en compétences ?

Dans 90% des cas, par du peer learning. Dans l’équipe où je travaille, on fait du mob programming. Avec 1 seule machine, on projette le code sur un projecteur, on écrit le code à plusieurs, et on tourne toutes les 10 minutes.

C’est particulièrement adapté pour réaliser une nouvelle fonctionnalité tous ensemble, car cela forge une expertise commune. On cherche la meilleure solution ensemble. Cela prend du temps, mais c’est un gain de temps colossal dans la durée, car on aura une solution meilleure et bien plus maintenable, et que chacun sera capable de faire évoluer la fonctionnalité. C’est un investissement.

Et après ? Tes projets d’évolution ?

Question tricky ! (rires). Je suis heureux dans ce que je fais aujourd’hui, et j’ai du mal à voir un poste supérieur où je continuerais à faire ce que je fais aujourd’hui.

La suite logique serait un poste de CTO, mais je ne le veux pas à titre personnel. J’ai encore des axes de progression sur des aspects purement techniques. Chaque équipe est différente. Et chaque projet, notamment en fonction du produit et de la taille de l’équipe, est différent.

Je souhaite aussi continuer à dispenser des formations en TDD, et partager ces savoirs aux développeurs. D’ailleurs, en prolongement de cette interview, si vous souhaitez lire le livre blanc Culture Code, vous pouvez le télécharger gratuitement ici

*         *         *

Si vous même souhaitez devenir CTO, la parcours est fait pour vous. Le projet 7 mêle ce métier au fait de monter sa startup. Vous aurez toutes les clefs pour vous lancer.

Et pour adopter comme Damien le rôle de Tech lead, suivez notre formation diplômante en un an !