Dans l’esprit d’un TechLead: une vidéo qui fait date

Le but de ces « posts » sur mon rôle de TechLead est pour moi de mieux le comprendre et le développer, pour les mois (années?) à venir.

Par le plus pur des faux hasard au temps d’Internet (le suivi de certaines catégories de personnes sur Twitter amène forcément à des rencontres utiles), je suis tombé sur une vidéo d’Arnaud Lemaire.

Je ne suis pas un fan de YouTube. Personnellement, je préfère de loin la lecture pour apprendre quoi que ce soit. Mais là, il faut bien le dire, Arnaud explique avec énormément de pertinence et de maturité le métier de développeur à l’intérieur du contexte de cette jeune industrie (contexte qui manque cruellement à la plupart des quelques vidéos que j’ai tenté de visionner…).

De bout en bout, Arnaud déroule un discours censé, pertinent, intelligent. Cette vidéo fera date pour moi, et je vais en reparler sur ce blog.

Dans l’esprit d’un TechLead: décollage

[Access the English version of the article initially published at the end of december 2018]
[Accéder à toute la série d’articles en français]

J’ai tout juste débuté il y a mois à travailler comme « leader technique » dans une équipe de développeurs pour un projet logiciel ambitieux. Ce rôle n’est pas entièrement nouveau pour moi, puisque j’ai travaillé comme « Head of Software » pour une startup durant 2 ans. Mais à ce moment là, j’ai surtout été submergé par les aspects opérationnels du département de la « R&D » (c’est-à-dire 90% de l’entreprise). Cette fois, je peux me concentrer sur ce rôle intéressant uniquement.

J’aimerais prendre l’occasion de cette nouvelle aventure pour partager quelques unes de mes réflexions, en essayant d’explorer autant que possible tous les aspects. C’est-à-dire la technologie, bien sûr, mais aussi, la confiance en soi, la communication, l’architecture, la progression de carrière, le mentoring, la politique…

(Un petit peu de contexte: j’ai 44 ans. J’ai commencé ma carrière comme astrophysicien, puis j’ai basculé dans le développement logiciel en 2011, travaillant pour des petites entreprises, mais aussi pour des organisations plus grandes. J’ai eu l’occasion de faire pas mal de code scientifique, de modélisation, de traitement d’images, mais aussi une application « desktop » professionelle, des bibliothèques scientifiques, des composants applicatifs, des APIs REST et finalement une app front-end. Peu importe les détails, mais disons que j’ai « mangé » passablement de languages, dans passablement de contextes différents, et – le plus important – livré en production passablement de projets.

La première idée qui me vient, quand je regarde en arrière le déroulement de ce premier moi est la suivante: le TechLead doit avoir un sens aigu de l’équilibre. De nombreux espoirs, rationnels ou non, sont souvent mis sur les épaules de ce rôle, de la part de personnes techniques mais aussi non-techniques. Cela était particulièrement le cas que je suis arrivé: un projet qui a 6 développeurs juniors, un scrum master, un architecte, deux « Product Owners » scrum (et un directeur de projet), and qui a commencé déjà depuis 3 mois. Mais tout le monde dans l’équipe de développement et le management alentour partageait le même sentiment que le projet avec un besoin impératif de « séniorité », étant donné le contraste entre la jeunesse de l’équipe et l’ambition du projet (qui est un sujet en soi).

Quand je suis arrivé, j’ai ressenti fortement le besoin d’équilibre entre de nombreuses forces. Mais concentrons-nous sur la partie la plus pertinente, selon moi, durant ce moment spécial que sont les premières semaines.

J’ai ressenti le besoin d’un sens de l’équilibre entre l’urgence de me couler le mieux possible dans la nouvelle organisation, d’un côté, et d’user de mon ignorance des détails pour questionner les hypothèses existantes du projet, d’un autre. Avec un management très ouvert d’esprit (une chose dont l’importance est cruciale), les gens sont souvent très ouverts à entendre quelles sont les choses qu’elles auraient pu faire autrement, ou quelles éventuelles erreurs elles ont fait. C’est un pouvoir que vous avez seulement durant les première semaines, et il n’y en a qu’une quantité limitée. Il vous est donné de parler librement, mais avec prudence malgré tout, pour partager vos impressions.

C’est aussi l’occasion de fournir déjà ce que sera les grandes lignes de votre action. Ce dernier point ne vous permet pas de vous sentir parfaitement dans votre rôle facilement, mais au moins, cela aide à le remplir

En d’autres termes, si vous entrez dans un environnement essentiellement problématique (comme c’était le cas pour moi), vous devez rapidement révéler les blocages (mais sans les exagérer) et ouvrir des possibles pistes de solutions (sans les imposer!). C’est un équilibre assez fin. Si vous insistez trop sur les problèmes, ou apparaissez trop rapidement impliqué émotionnellement, c’est facile de comprendre que vous ne servirez pas bien votre rôle, ou que vous ne serez simplement pas une part de la solution. Le risque existe d’être poussé hors du projet très peu de temps après votre entrée.

De plus, si vous imposez des solutions, vous perdez rapidement du crédit: comment pouvez-vous avoir une idée de l’ensemble du projet dès le début ? Des problèmes qui n’ont pas été réglé après de nombreuses semaines, voire mois sont forcément interconnectés avec d’autres forces, et impliquent d’autres gens. Les gens présents sont certainement de bonne foi, esayant de faire de leur mieux. Vous ne pouvez pas faire plus que suggérer des solutions, et si possible, des solutions que le management vous a suggérer au début, plus ou moins explicitement (vous êtes nécessairement un peu « utilisé » par quelqu’un pour modifier l’état existant des choses – c’est parfaitement normal).

Si vous invoquez votre « énorme » expérience pour essayer d’imposer vos solutions, vous semblez devoir vous justifier, et cela affaiblit votre position encore neuve. (Les démonstrations de virilité dans des environnements tech auront besoin d’un post dédié). And vous devez rester ouvert aux solutions suggérées par d’autres; solutions qui ne vous satisfont peut-être pas, alors que vous continuez à vous ajuster à un nouveau contexte, une nouvelle place de travail, une nouvelle pile technique… Tout cela est difficile.

Dans le cas opposé d’un environnement essentiellement positif, ces premières semaines sont, je pense, un bon moment pour construire des pistes de développement à la fois technologiques mais aussi humaines, de long-terme. Ce qui est sûr, c’est que dans les deux cas vous pouvez engranger de grandes quantités de crédit, si vous réussissez à acquérir rapidement la confiance de l’équipe de développement en lui fournissant de l’aide rapidement sur des points difficiles (ce qui est finalement le coeur de votre rôle). L’équipe de dev est le terreau sur lequel quelque chose se construit, et c’est à vous de le cultiver.

Comment réussir à ressentir ce sens aigu de l’équilibre ? Il n’y a pas de magie. Personnellement, je ne vois que deux choses: écouter et dormir, dès le premier jour. Ecouter est absolument clé. Ecouter tout le monde, faire attention un peu au language non-verbal, mais surtout pour confirmer des impression, écouter dans toutes les occasions, les réunions, les déjeuners, écouter tout le temps. C’est épuisant. C’est pourquoi, assurez-vous de dormir assez. Vous aurez certainement l’occasion de profiter de temps plus calmes après quelques semaines.


J’espère que vous aurez trouvé cet article intéressant. Il souligne un peu les sujets à venir dans cette série: comment acquérir la confiance d’une équipe, comment gérer la présence de figure autoritaires, l’équilibre entre être fort, et être une partie d’un tout que vous ne contrôlez pas… A bientôt !