Attention spoiler : pas de recette magique dans cet article ! Ni dans le premier et deuxième de la série d’ailleurs.

Même si chaque TL (Tech Leader) est différent, l’urgence, les changements de contexte ou encore les priorités mouvantes donnent peu de maîtrise sur le contenu de ses journées. Efficacité réduite, frustration , épuisement ; tant de possibles conséquences de cette spirale vicieuse. Quelques idées pour combattre ces fléaux.

Proposition théorique d’un idéal

La répartition du travail du TL est un grand débat dans les équipes de développement. Dans un contexte agile, elle pourrait, s’elle existe, s’approcher de ce diagramme :

Un TL épanoui devrait pouvoir se donner les moyens d’être à l’aise avec les décisions techniques prises, sentir une progression dans ses objectifs personnels et réussir à insuffler une dynamique positive dans l’équipe coachée.
Ces éléments permettent non seulement de gagner en crédibilité mais aussi d’établir des lignes directrices pour sa carrière.

Dans cette perspective de bien-être, le volet interaction d’équipe reste clairement important.
Malgré cela, le fait est qu’à l’image d’un product owner ou d’un scrum master, le TL a une dimension transverse qui le marginalise de l’équipe de développement. A fortiori, ces profils peuvent être habités d’un sentiment d’isolement.

Sublimer la solitude

Le TL a souvent une place définie et précise : il est érigé comme garant de la qualité et de la cohérence applicative de l’ensemble des développements. C’est d’ailleurs cette place qui fait de lui une interface technique naturelle pour les autres équipes.
Dans des dispositions d’équipe avec un mindset agile avancé, des développeurs peuvent être invités dans ces échanges mais le manque de temps, de priorisation et d’envie font que leur présence reste occasionnelle.
Le TL s’engage donc pour l’équipe à la manière d’un capitaine, seul.
De plus, en gardant en tête les objectifs de l’idéal présentés plus haut, ma répartition actuelle est sensiblement différente :

L’anti-pattern « Professeur »

Présent sur le plateau, on pourrait croire que cet excédent de coaching m’a rapproché de l’équipe. Paradoxalement, cela m’a enfermé dans une vie annexe à celle de l’équipe de développement. Je suis tombé dans un anti-pattern appelé “Professeur” à vouloir répondre à toutes les sollicitations des développeurs.

D’une part, j’ai fait face à beaucoup de frustration à cause de la débauche d’énergie dépensée pour faire collaborer les développeurs et leur donner plus d’autonomie. L’envie de créer de la synergie d’équipe et de m’y inclure a abouti à une vraie déception. Je prône énormément la collaboration horizontale et surtout dans cette relation TL/Dev. Cette situation m’a montré que certains développeurs, par réflexe ou habitude, n’ont peut-être simplement pas besoin ou envie de ce type de collaboration.
Ainsi, pour gérer cette phase, j’ai dû mettre entre parenthèses ce volet coaching car il phagocytait le reste de mon activité.

D’autre part, les nombreuses sollicitations extérieures (réunions de cadrage technique, fonctionnelle, interactions avec les équipes connexes, etc.) ont marginalisé mon statut à cause de mon absence physique sur le plateau : perte en delivery, indisponibilité récurrente pour les développeurs et manque d’implication technique sur les projets.

Gagner en sérénité

A mon retour de congés, je décidais de prendre la chose sous un autre angle. Une citation de Nietzsche m’a beaucoup inspiré : « Souffrir de la solitude est mauvais signe ; je n’ai jamais souffert que de la multitude. »
J’en ai ressorti deux choses :

• l’effervescence de cette multitude, intra et extra-équipe, est source d’urgence, de frénésie et de désorganisation ;
• la libre réflexion que peut apporter cette solitude permet de prendre du recul et de mûrir une réflexion sur son périmètre de compétence.

Cela m’a permis de mettre en lumière une façon d’accepter ce sentiment d’isolement, de gagner en sérénité.
J’ai pris conscience que cette solitude fait partie de l’essence du métier. La pensée collective connote cette notion de manière plutôt négative. Étrangement, j’y ai trouvé une certaine quiétude.

La multitude n’a pas que du mauvais ! Loin de moi l’idée de faire l’apologie de « l’enfer, c’est les autres » de Sartre. Mon objectif n’est pas d’opposer ces notions mais de jouer sur leur dualité pour y extraire le meilleur.

S’entourer de relais

L’un des aspects de la collaboration qu’il est important de maîtriser est le nombre d’interactions. Mathématiquement, il est plus efficient de préférer des petites équipes par rapport au nombre de connexions à établir :

L’une des solutions pour borner ce nombre de liens est de définir un rôle où le développeur sera responsable d’une fonctionnalité, d’une méthode, d’une technologie, etc ; un relais qui concentrera de la valeur pour le projet et où le TL servira de backup.
J’ai été un de ses relais sur ma mission avant de passer TL. Cela m’a permis d’avoir un test « grandeur nature » pour prendre la température et montrer également mes qualités de leadership et de communication ; idéal pour ceux qui auraient cette perspective en tête.
La nuance du terme “relais” à celui de “référent” fait que ce rôle est beaucoup moins engageant dans la conscience collective aussi bien vis-à-vis de l’équipe que de soi-même.

Ainsi, le TL se dégage du temps mais l’intérêt est surtout que l’équipe gagne en autonomie et donc en auto-organisation.
Sur le versant montée en compétences, ces relais sont aussi intéressants à exploiter car ils seront par la suite des exemples à suivre.

Le mot de la fin

TL n’est pas qu’une question de technique, l’organisation est le véritable défi pour pouvoir exprimer ses compétences dans leur entièreté.
Les questions à se poser sont variées et j’espère que ces quelques pistes de réflexion vous permettront d’avancer et de vous en poser davantage. Il faut accepter ses difficultés et faire confiance à son ressenti pour ne pas confondre remise en question et résignation.

Mahamoud Saïd Omar