Interview Wojciech Wojcik "On ne naît pas Tech Lead, on le devient !"

Après plus de 5 ans chez OCTO et plus de 10 ans de métier, d'abord en tant que Développeur, puis en tant qu'Architecte, Wojciech nous dévoile son rôle de Tech Lead et la raison pour laquelle il s'y sent à sa place...

Quel est ton parcours ?

Avant OCTO j’ai travaillé dans une société de service pendant 10 ans, 10 000 personnes, assez classique, “à la papa” diraient certains. Mais je ne regrette rien !! C’est là que j’ai fait mes armes, acquis mon expérience et mon expertise, et notamment un intérêt particulier pour l’architecture.

Dans cette ancienne boîte on ne parlait pas vraiment de Tech Lead, on disait juste “Architecte”, intitulé qui désignait quelqu’un qui avait de la bouteille, faisait des choix techniques et en portait la responsabilité. C’est à OCTO que j’ai découvert que Tech Lead allait bien au-delà de ça : de la tech oui, mais pas que !

Comment es-tu passé de développeur à Tech Lead ?

Je suis Tech Lead ET développeur avant tout ! Cela ne s’oppose pas, bien au contraire. Pour ce qui est de le devenir, l’expérience technique a été un premier critère assez naturel : j’ai développé de l’expertise, j’ai intégré et pris du recul sur les technologies, les architectures, la qualité de code, le craftsmanship, la méthodologie projet.

Ensuite la seconde qualité essentielle du Tech Lead est de transmettre, accompagner, coacher, faire grandir ses compagnons de fortune. Et pour le coup c’est une fibre que je pense avoir eu dès les premiers instants de mon aventure professionnelle. J’adorais passer du temps avec les gens et expliquer des choses (je dois avoir une carrière ratée de prof !) : toujours désigné volontaire pour l’onboarding des nouvelles recrues fraîchement débarquées. Instinctivement j’ai dès le début rejeté les patterns où chacun développe dans son coin. Tellement plus intéressant de s’entraider, comprendre là où ça bloque et de trouver ensemble une solution.

Quels types de compétences doit-on avoir pour être un bon TL ?

On ne se réveille pas Tech Lead, on le devient, doucement, mais sûrement !

Chez OCTO, le Craftsmanship est primordial. En soit déjà parce qu’il va permettre de produire un code de meilleure qualité. Mais surtout parce que produire seul du code de qualité n’a pas vraiment de sens dans un projet. C’est une expertise qu’il faut de facto partager et faire vivre à l’échelle d’une équipe : code review, pair programming, rétrospectives tech et autres moments de partage, un pilier essentiel du craft !

Il y a aussi les soft skills. Elles servent à créer un contexte de travail apportant confort psychologique, où chacun va pouvoir se sentir à l’aise et en confiance. On ne se pointe pas du doigt, ce n’est pas une compétition entre le plus fort et le moins fort, on a le droit de se tromper, ce n’est pas grave. Selon moi une équipe dysfonctionnelle à ce niveau a peu de chance de produire du code de qualité et un produit à succès. Attention ! Confort de l’équipe ne veut pas dire que le Tech Lead va tout résoudre, prévenir tous les problèmes et préserver tout le monde du moindre pépin. Je suis aussi notamment convaincu que l’on apprend avant tout de ses erreurs et des challenges que l’on surmonte. Quand on se prend un mur on s’en rappelle toute sa vie ! Ainsi en tant que Tech Lead il m’arrive parfois de “laisser un dev se planter”. J’arrondie les angles pour éviter une catastrophe, mais je ne me fais surtout pas papa poule ! En faisant cela (parfois, pas toujours) je sais que je vais maximiser un élément d’apprentissage. Je vais aussi montrer à la personne concernée que ce n’est pas grave de se planter, et que toute l’équipe le soutient ! Ca n’a pas de prix.

L’idéal est d’arriver à embarquer les autres, déléguer ce qui peut l’être et ne pas tout contrôler, même si ça peut paraître surprenant avec une casquette “Tech Lead”

Enfin une dernière compétence est ce que j’appelle parfois “flair” : le fait d’avoir vu pas mal de projets, de systèmes, de technos, les trucs qui marchent bien, le trucs trop compliqués, les échecs cuisants. Ce que l’on attend d’un Tech Lead plus expérimenté, c’est sa vision : qu’il soit capable de tracer une route avec son équipe dans la complexité inhérente à tout projet IT. Il éclaire de son expérience les choix collectifs, il aide l'émergence des arguments, il pointe les risques que les moins expérimentés ne voient pas encore.

Ok, ça commence déjà à faire pas mal de compétences, et la liste n’est pas terminée. Je suis néanmoins persuadé qu’on n’est pas obligé d’être vieux avec des cheveux gris pour avoir la casquette Tech Lead. Dès que l’on commence à être à l’aise avec le Craft, on peut commencer à embarquer ses amis dans l’aventure du code de qualité : c’est déjà une première marche du tech leading ! Par exemple chez OCTO on peut la franchir après seulement 2-3 ans d’expérience.

Comment définis-tu un bon Tech Lead ?

On a déjà eu des discussions chez OCTO sur “Qu’est-ce qu’on attend vraiment d’un Tech Lead ?” (grande question) et l’un des débats a mené à une réponse assez originale : “Le rôle du Tech Lead, c’est de disparaître.”

Le concept de disparition du TL est assez simple : une fois que toutes les pratiques de craft sont partagées, que tout le monde est à l’aise avec l’architecture, que le cadre et l’ambiance de travail sont au rendez-vous et que la sécurité psychologique est instaurée, le rôle de Tech Lead devient de moins en moins important.

L’idéal c’est qu’il ait tellement réussi à embarquer l’équipe qu’au final il n’ait plus besoin d’être identifié comme Tech lead. Je trouve ça top comme challenge, et arriver à une telle maturité collective nécessite un sacré travail en début de projet.

Différence entre un TL extérieur et un TL OCTO ?

Il y a des gens géniaux partout !

Ce qui ne marche définitivement pas, c’est la posture du Tech Lead qui se croit supérieur à l’équipe et qui n’aborde que l’aspect technique des choses. Le TL est souvent réduit à cette approche technique : quand on est bon, voire le meilleur techniquement, on devient Tech Lead. Chez OCTO, nous n’avons pas du tout cette approche. On accorde une part importante aux rapports humains. Petite anecdote qui m’est arrivé ici : j’intègre un projet en tant que TL et m’aperçois que finalement un développeur de 5 ans d’expérience se trouve être bien meilleur que moi sur notre stack technique (alors que j’ai 15 ans d’expérience…) Du coup, je commence à me poser des centaines de questions, je remets ma légitimité en cause, je me demande si je dois lui céder ma place. Pas très à l’aise, j’en discute avec des gens autour de moi, et je me rassure qu’être “le meilleur” dans une techno ou un framework n’est pas le seul critère.

J’ai fini par demander à ce développeur ce qu’il en pensait et s’il ne trouvait pas ça bizarre. Il m’a dit qu’au contraire, j’apportais de la vraie valeur ajoutée sur d’autres aspects (vision, rapport humain) et que finalement, on se complétait lui et moi \o/

J’en ai tiré un enseignement assez fort sur ma propre casquette et la posture associée : repousser toute forme d’égo liée au rôle de Tech Lead, et au contraire, oeuvrer à faire cohabiter les talents de chacun.

Mais alors, quel est le ratio code / accompagnement ?

Il n’y a pas de logique, chacun conçoit son rôle comme il le sent.

De mon côté j’aime bien coder, donc je reste sur un ratio d’environ 75 % code et 25 % accompagnement, certains préfèrent se laisser plus de temps pour d’autres sujets que le code. Mais in fine, la matière première du projet c’est le code. Je ne pourrais donc pas appeler un 100% non-codeur un Tech Lead. Ne serait-ce que pour la partie Craft qu’il se doit de porter.

Pourquoi aimes-tu le Tech Leading ?

D’abord parce que j’adore (toujours) développer. J’aime avoir la main dans du concret et ne pas faire que du conseil. Clairement, ca me rend heureux. Mon autre kiff, c’est la dynamique d’équipe et le plaisir de travailler ensemble : aider mes pairs, tout faire pour que chacun arrive le matin avec le sourire, partager des moments intenses et relever des challenges, tous ensemble !