A quoi sert le tech lead ?

La première bataille dans l’Arène a eu lieu avec cette question : Le tech lead est-il indispensable ?
Ce qui était un jeu au départ s’est révélé finalement beaucoup plus sérieux que prévu et il y a eu dans l’échange une matière très intéressante. Au final ce sont plus d’une centaine de votants et une soixantaine de commentaires.
De quoi faire un bel article de synthèse !

Ironie de l’histoire, j’avais déclaré le camp du OUI vainqueur, mais c’est en fait le camp du NON… J’avais lu la barre de résultat à l’envers ! 😳
On a compris d’où venait l’erreur de lecture et c’est maintenant corrigé. Comme quoi…
Au final, ce n’est pas très important car le résultat est en fait très serré. Si on prend en compte les emails non confirmés, il l’est encore plus : à un vote près.
Ce qu’il faut donc retenir, c’est plutôt que cette question divise les participants en deux camps. Il n’y a pas vraiment de consensus qui émerge.
Pourtant quand on lit les commentaires on trouve à la fois des points de convergence très forts. Mais aussi des points de divergence fondamentaux.
Qu’est-ce qui caractérise ceux qui sont pour ou ceux qui sont contre ? Sur quoi sont-ils d’accord ou farouchement opposés ?
C’est ce qu’on va voir maintenant.

Les arguments du ‘OUI’

“Est-ce que Obi-Wan Kenobi serait un maître Jedi sans Yoda ?”

Tout d’abord, le tech lead apparaît comme un maître Jedi exigeant qui transmet la connaissance :
* Il guide les débutants
* Il veille à la cohérence technique
* Il accompagne les équipes qu’il fait monter en compétence
* Il coordonne et donne le cap
* Il peut aussi donner l’impulsion
* Il tranche quand aucune décision ou consensus n’émerge

Il a besoin de compétences relationnelles pour déléguer, écouter ou communiquer ses positions. Ce n’est donc pas forcément l’image du tech lead contrôlant qui domine, même si elle apparaît parfois, mais celle d’un leader bienveillant qui mène son équipe vers l’excellence.

En fait cette vision du tech lead semble admise par le camp du non qui reconnaît l’utilité du tech lead mais surtout la nécessité de laisser la place au leadership. Ce qui leur pique les oreilles, c’est plus la suite :

Le tech lead est responsable. Il sert de fusible. En gros, c’est lui qui prend les coups quand il y a des soucis dans le projet et il protège l’équipe.
Par ailleurs il est nommé par la hiérarchie avec cette idée sous-jacente que l’auto-organisation, c’est l’anarchie et ça ne marche pas.

Je pense que ce sont ces deux derniers points qui irritent le plus le camp du non. Et d’ailleurs on voit bien que la réaction est émotionnelle, même épidermique parfois !
76 % des up/down votes viennent du camp du non.
Quand ils votent sur les arguments du camp du oui, c’est à 82% pour descendre les arguments.
Donc en substance : ceux qui ont choisi le camp du non ont beaucoup plus voté et ont voté contre les arguments du camp adverse. Les arguments qui sont le plus critiqués concernent précisément ces deux derniers points.

Et c’est bien là la pomme de discorde : le tech lead oui, mais pas UN tech lead. DES tech lead.

Les arguments du ‘NON’

Pour le camp du non, Le leardership émerge, il ne se décrète pas. C’est Ok si c’est l’équipe qui le décide, mais pas la hiérachie. Car nommer un tech lead va à l’encontre de l’esprit d’auto-organisation. C’est d’ailleurs considéré comme le signe d’une carence managériale par certains.

“Je déteste les super héros, personne ne peut sauver le monde quand ils sont en congés”

Il devient aussi un SPOF (Single Poing of Failure). C’est à dire que s’il fait défaut, c’est toute l’équipe qui est paralisé. Comment va-t-il partir en vacances plusieurs semaines ? Il amène le bus factor de l’équipe à 1 : il suffit qu’une personne de l’équipe passe sous un bus pour qu’elle soit fortement ralentie.
Et puis il représente aussi un risque : s’il n’est pas au niveau, cela peut virer à la catastrophe pour le projet. Sans en arriver jusque là, il peut être un frein à l’innovation en gardant l’équipe dans sa zone de confort.
D’où l’idée de ne pas avoir un seul tech lead mais plusieurs tech lead sur un projet. La dimension hiérarchique est gommée pour laisser la place à la remise en question.

Une question trollesque

« Non mais ton truc, c’est trollesque, tu vas produire plus de chaleur que de lumière »

Certains m’ont dit : c’est une question qui ne mérite pas qu’on s’y intéresse… Les reproches ne manquaient pas : question mal posée, termes mal définis. Je pense le contraire : La question était volontairement ouverte. Assez précise pour donner un angle, et assez flou pour laisser la place aux arguments. Et la participation a plutôt tendance à me donner raison.
Mais bon… A l’image d’Evan, même ceux qui râlent ont un avis.
En fait tout le monde a un avis sur cette question.

Et c’est tant mieux : on ne peut pas plaire à tout le monde, et c’est pas grave. La société essaie de nous faire croire le contraire. Allez voir ce qui se passe en Chine…

Mais ce n’est pas vrai.

Quand on est apprécié par tout le monde, ça donne nos hommes politiques qui essaient de ratisser le plus large possible. Ca donne des gens lisses, capables de retourner leur veste au moindre coup de vent.
De qui est important, ce n’est pas d’être consensuel, c’est d’être respectueux.

Porter ses convictions avec respect : voilà la clef.

Nier que nous avons des idées opposées est une aberration.
Par contre le respect permet de les confronter et de s’enrichir. La divergence de point de vue est une source de progrès, pour peu qu’on lui laisse la place.
Après on a tous des limites et on n’est pas obligé de les dépasser.
Par exemple, je ne peux plus travailler sur un projet sans écrire de tests unitaires. Je suis infecté par les tests. C’est une maladie rare et peu contagieuse, hélas, avec une longue période d’incubation. Et cela m’empêche de travailler sur pas mal de projets. Quand un client me demande de reprendre un projet qui n’a aucun test, c’est non.

Dur d’être un artisan

Je sais qu’être Artisan Développeur n’est pas facile. On aime ce qu’on fait et on est exigeants. D’ailleurs on fait parfois peur : trop exigeants qu’ils disent les managers. Ok. Mais quand le projet croule sous les bugs, c’est qui qu’on appelle au secours ?

Et c’est parfois trop tard.

Le problème c’est qu’une fois que tu as goûté à la légèreté d’un projet bien mené, que tu as dansé avec ton binôme derrière le clavier, que tu t’es libéré de la peur de casser quelque chose pour laisser la place à la créativité pure, que tu as pris l’habitude de livrer de la valeur plus vite que lucky luke ne met pour écrouer les daltons, c’est dur de revenir dans la norme des projets.

Alors si tu cherches un endroit épanouissant dans lequel tu pourras déployer ton savoir faire, laisse moi tes coordonnées.
Je connais des boîtes qui cherchent des gens comme toi. Y‘en a pas beaucoup c’est sûr, mais ces endroits existent.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.