Tu as posé ton regard sur une offre de technical leader, mais tu es inquiet à l’idée d’accepter un poste/une mission dans une nouvelle équipe, peut-être une nouvelle industrie ? Tu te demandes si tu seras à la hauteur dans ce rôle sans expérience du métier ni de la base de code ?

Je comprends tes craintes, mais je pense que tu peux aussi tirer profit d’être dans cette position. Je suis récemment passé par là, je t’explique ça juste après !

Contexte

On est fin 2021, je suis freelance depuis un peu moins d’un an. Je reçois alors un appel de mon ancien employeur. Il veut me proposer une mission de technical leader dans un département différent de celui pour lequel j’étais employé avant : équipe différente, logiciel différent, business différent.

Ca a l’air intéressant, et après avoir discuté plus en détail de la mission, j’accepte.

Je vais être franc. Quand je rejoins l’équipe, en février 2022, je ne suis pas très à l’aise. Je ne connais pas le business, la stack comprend des technos que je ne maîtrise pas (même pas de loin). J’ai peur qu’on me pose des questions auxquelles je ne sais pas répondre, et de perdre ma crédibilité. Ou de ne pas être crédible tout court.

Mais voici ce que j’ai pu tirer de ma situation.

Regard neuf

Venant juste d’arriver, ne connaissant ni l’équipe, ni le métier, ni le code, j’avais l’opportunité d’aborder l’expérience avec un regard neuf. Lorsque quelque chose me paraissait dysfonctionnel ou qu’un problème survenait je ne souffrais pas du poids de l’historique.

Je ne souffrais pas du fatalisme qu’on peut ressentir après plusieurs années à travailler sur un même projet. Aucune critique ici, je pense qu’on est beaucoup à passer par là, moi y compris. Ne pas avoir la tête dans le guidon permet parfois de proposer des solutions qui n’ont pas encore été considérées. Ou bien des solutions qui ont déjà été essayées, sans succès, mais de les mettre en œuvre différement. Là, il est important d’analyser pourquoi cela a échoué par le passé (et je ne vais pas mentir, c’est une compétence qui laisse encore à désirer chez moi).

Cela vaut aussi pour nos collègues. Lorsqu’on connaît quelqu’un depuis plusieurs années, il est parfois difficile de prendre du recul sur certains comportements, certains fonctionnements. Ici, c’est différent : ce sont de nouvelles relations et chacune est une nouvelle page blanche à écrire ensemble.

Étant devenu technical leader d’une équipe avec laquelle j’étais déjà familier plusieurs années auparavant, je peux te dire que l’expérience est totalement différente. Là où j’étais plein d’à priori (bons comme mauvais) lors de ma précédente expérience, je pouvais ici aborder chacun·e sans idée préconstruite.

Se concentrer sur les personnes

En parlant des collègues. Technical leader peut être vu comme un métier à forte proportion technique. Et, dans une certaine mesure, c’est vrai. Mais les compétences humaines le sont encore plus (quelque chose que j’ai également appris, à mes dépens et ceux de mes collaborateur·rice·s, lors de ma précédente expérience).

C’est un métier de support et d’accompagnement, il est donc capital de s’intéresser à chaque être humain avec qui on collabore. En discutant avec eux, on peut comprendre ce qui les motive, ce qui les intéresse, pourquoi ils sont là. En faisant cela, on se donne les moyens de les accompagner au mieux.

Tout cela tombe bien, car dans une nouvelle mission, tu n’es pas encore une personne centrale au fonctionnement de l’équipe. Et je ne recommande pas que tu le deviennes, c’est une position inconfortable pour toi et qui n’aide en rien l’équipe ni l’entreprise ! Mais en début de mission, tu es vraiment peu sollicité. Et il faut profiter de cette période pour mettre en place de bonnes relations avec tes collègues. Non seulement les comprendre, mais aussi tirer un maximum profit de ce qu’ils peuvent t’apporter. Ce sont eux qui ont la connaissance qui te fait défaut à ce stade.

Expérimenter

Tu peux également profiter de cette période un peu libre pour expérimenter. Tu as repéré des choses qui t’embêtent, des freins au bon fonctionnement de l’équipe. Essaie de trouver des solutions à ces problèmes.

• le temps de build est trop long : regarde si tu ne peux pas le réduire ;
• les tests sont flaky (fonctionnent en local, échouent dans l’intégration continue) : investigue pourquoi ;
• etc.

Je ne parle pas de te cacher pour explorer tout cela. Non, sois transparent, c’est important pour instaurer une relation de confiance avec ton employeur·euse/ton·ta client·e. Mais ces expérimentations t’aideront à comprendre l’environnement dans lequel tu as atteri, te permettront, si elles sont fructueuses, de résoudre des problèmes de l’équipe, etc.

Il n’est pas impossible qu’à ce stade l’équipe n’ait pas, ou ne prenne pas, le temps d’investiguer ces soucis. En effet, elle est sûrement sous une certaine pression de livrer des fonctionnalités dans un certain timing. Ou bien, elle subit le poids du fatalisme (on y revient). Ou bien, elle a simplement la tête dans le guidon. Tu as la possibilité d’essayer de tacler ces soucis pour elle, et de lui (re)montrer à quel point il est aussi important de s’occuper des problèmes non fonctionnels qui se mettent dans le chemin de la productivité de l’équipe. D’ailleurs, cela montre non seulement à l’équipe que c’est important, mais aussi au business et à la hiérarchie.

Conclusion

En résumé, n’aie pas peur d’accepter une mission de technical leader même si tu ne connais pas l’industrie ni le logiciel sur lequel tu vas travailler. Il y a du bon à démarrer d’une page blanche. Profite du temps à ta disposition en début de mission pour bien comprendre tes collègues, les processus en place. Essaie de repérer les problèmes qui empêchent l’équipe de fonctionner à son plein potentiel. Si tu peux, résous-en certains.

Et surtout, éclate-toi ;-)