En deux décennies, j'ai été amené à travailler sur des sujets très variés. Des refontes complètes de système d'information pour des opérateurs télécoms, la construction de logiciels financiers massivement utilisés, une application de gestion de déplacements professionnels avec de la recherche hôtelière et avions, la gestion des alertes de compteurs électriques communicants, une marketplace de freelances, entre autres.

Dire que tout s'est toujours bien passé serait assez faux. Très faux.

Mais au fil des expériences, j'ai rencontré plusieurs fois des duos Tech Lead/Manager qui ont été des démonstrations pour moi.

J'ai rencontré des duos, comme sur l'application de gestion de voyages d'affaires, qui ont permis de démultiplier l'impact des projets entrepris.

Des personnes capables de dégoupiller tout type de situations, parce qu'ils bossaient correctement ensemble, bien plus que ce qu'aurait pu faire chaque personne séparément.

Et c'est cela, en tant que senior IC (contributeurs individuels) que vous devriez chercher à créer.

Je sais que c'est loin d'être simple. Construire un duo, une équipe, est de loin l'un des plus grands défis pour un(e) senior en informatique, peut-être même devant l'invalidation de cache et le nommage ;)

Je vous propose donc de discuter de l'importance de ce duo et de son effet multiplicateur lorsqu'il fonctionne.

Deux rôles bien distincts, ou pas

D'abord, je vais rappeler mon hypothèse de départ. Je pars du principe que les deux rôles sont séparés.

Je sais, il est possible d'avoir des organisations dans laquelle l'Engineering manager est également le tech lead. C'est possible. Inefficace à l'échelle, mais possible et je l'évoquais dans un précédent chapitre.

C'est déjà très compliqué d'être bon dans les deux disciplines, et lorsque c'est le cas, vient ensuite la question du temps disponible dans une journée pour bien faire les deux.

Et si vous ne me faites pas confiance, vous devriez écouter ce qu'en dit Charity Major à ce sujet. On peut bien faire les deux, mais pas en même temps.

Evidemment toutes les situations ne sont pas comparables.

Deux personnes, ça coûte plus cher qu'une personne. Je pense que cette assertion hautement incroyable pourra difficilement être remise en cause d'un point de vue mathématique.

Donc, à petite taille, c'est assez naturel de mélanger les deux rôles. Et dans ce cas, ce chapitre aura peu d'intérêt.

Mais si vous n'êtes pas dans cette situation, alors vous pouvez continuer une lecture normale.

Si vous souhaitez une vue exhaustive des responsabilités de chaque rôle, le mieux reste d'aller sur le site engineeringladders.com qui donne une liste de tâches que l'on peut aisément rattacher au tech lead, ou à l'Engineering manager.

the Tech Lead is in charge of the System while the Engineering Manager is in charge of the People.

Mais j'aime résumer cela un peu différemment :

Le ou la Engineering manager est responsable du "qui" et du "quand".

Le ou la Tech Lead est responsable du "quoi" et du "comment".

Et dans une grande majorité des cas, le "pourquoi" est à la charge du product manager. Je dis, dans la majorité des cas, car dans le cadre des équipes plateformes, le pourquoi est souvent à la charge du Tech Lead.

Évidemment cette définition est "simpliste" et dans la réalité, il y a beaucoup de chevauchements, comme la définition des priorités, les processus de développement, la mise en avant de l'impact. Mais, ce n'est pas un bug d'organisation. C'est une feature.

C'est la garantie qu'il y a, a minima, deux personnes qui vont réfléchir ensemble. Et c'est plutôt une bonne chose, car on n'a jamais raison tout seul. Les impacts les plus grands que j'ai pu obtenir dans l'ensemble de mes expériences ont tous été construits quand des personnes m'ont forcé à prendre de la hauteur, et que nous avons construit des solutions à plusieurs cerveaux.

Mais, ça, c'est quand ça se passe bien et bien sûr, ce duo peut rencontrer des conflits.

Les conflits possibles

Plus haut, je citais le site engineeringladders.com

the Tech Lead is in charge of the System while the Engineering Manager is in charge of the People.

Cependant, ce serait illusoire de penser que le système, la technologie, et les personnes qui le construisent n'ont aucun lien.

Si le tech lead et l'Engineering manager travaille chacun avec une priorité différente et donc un souhait d'allocation d'investissement différent, cela peut finir en conflit.

Par exemple, si le ou la engineering manager décide d'investir dans la résolution du support alors que le ou la Tech Lead pense qu'il faut investir dans une nouvelle technologie qui peut changer la future nature du support, il y aura conflit.

Ces deux personnes peuvent ne pas être en conflit sur la finalité, mais être en désaccord sur les échelles de temps, et les moyens les plus efficaces pour résoudre rapidement un même sujet.

Un autre type de conflit que j'ai pu observer est souvent relié à la nature même des deux personnes.

Dans un des premiers chapitres je mentionnais des archétypes de Senior IC, : le tech lead, l'architecte, le solver, le right hand, l'explorateur et le product engineer.

Ces archétypes sont bien évidemment transposables aux Engineerings Managers.

Si l'un des deux est un(e) explorateur, qui cherche la disruption, et l'autre un(e) architecte, qui cherche la stabilité, peut-être que l'alchimie sera explosive. Si les deux ont une approche totalement différente des risques, l'un à l'aise avec l'erreur, l'autre dans la recherche de la réduction des risques, il y a fort à parier que l'un des deux sera dans une situation d'inconfort.

Mais alors, faut-il revenir à un schéma ou l'Engineering Manager a également les responsabilités du Tech Lead ?

La clé, c'est de se mettre d'accord sur la direction dans laquelle il faut aller. Quelle est la finalité recherchée, quel est le contexte. J'abordais ce point dans le chapitre Autonomie, alignement et contexte", car, si on recherche l'autonomie des deux personnes, l'autonomie ne veut pas dire indépendance. Il n'y a aucune issue possible à un duo qui déciderait d'éviter tout conflit en travaillant chacun dans son coin et limitant les interactions.

Il faut toujours garder en tête que lorsqu'un duo fonctionne, il y a automatiquement un effet multiplicateur sur l'impact produit par l'équipe. Mais lorsqu'il ne fonctionne pas, c'est l'effet inverse qui se produit.

L'effet multiplicateur

Si je m'attarde sur ce duo, c'est parce que chaque chapitre de ce livre vise non seulement à voir comment créer de l'impact, mais aussi comment trouver des effets de levier pour l'augmenter. Un(e) senior IC dépend fortement du réseau qu'il ou elle parvient à se créer. C'est ce réseau qui fera office de caisse de résonance pour amplifier l'impact produit.

Et le premier maillon de ce réseau, c'est le duo constitué avec l'Engineering Manager.

Aussi fort et intelligent que n'importe qui puisse être, il est extrêmement rare d'obtenir un large impact sans une autre personne qui nous fasse constamment progresser. C'est presque une forme de coaching mutuel.

Même les plus grands ont eu leur coach. Tiens par exemple, vous connaissez Bill Campbell ? Il a guidé différentes personnes, dont Steve Jobs ou Larry Page. Eh oui, même une personne comme Steve Jobs comprenait qu'il ne pouvait avoir raison tout seul.

Je profite de cet exemple pour préciser que ce type de duo fonctionne uniquement lorsque les deux personnes ont un niveau de séniorité proche. Il faut du répondant entre les deux comparses de ce duo. Il ne peut y avoir de déséquilibre si on veut créer un effet multiplicateur. Il n'est pas possible de créer un duo entre un(e) Principal Engineer et un(e) junior Engineering Manager par exemple. Ou alors, il s'agit juste de coaching à sens unique.

Le duo qui fonctionne

Lorsque le duo fonctionne, cette dualité permet de jouer un rôle de catalyseur.

Par exemple, si l'Engineering Manager travaille sur les topologies d'équipes, l'impact de cette organisation sera décuplé si le ou la Tech Lead y contribue en aidant à la définition de son propre rôle et ses intéractions en amenant sa vision du terrain et des systèmes à construire.

Si le ou la Tech Lead travaille sur l'introduction d'une nouvelle brique technologique, l'impact sera décuplé si l'Engineering Manager aide à diffuser la connaissance, contribue aux communications et aide le ou la Tech Lead à faire ressortir les bénéfices pour discuter avec le business.

etc..

Chacun peut aider l'autre et lui faire gagner du temps dans la phase d'idéation. Il ou elle peut servir à clarifier les objectifs, à s'assurer qu'ils sont bien alignés sur les besoins de l'entreprise. Chacun apportant une vision différente, sa compréhension du contexte, qui diffère forcément entre un(e) IC et un(e) manager.

Lorsqu'un sujet concerne l'organisation humaine, les pratiques, c'est au Tech Lead d'aider à la transformation, sur le terrain, avec l'ensemble des membres de l'équipe.

Lorsqu'un sujet concerne la technologie, les investissements, ou la dette, c'est l'Engineering manager qui permettra d'aider à la diffusion, au marketing interne, à la vulgarisation des impacts pour être compris par le business.

Enfin, les deux ont un rôle de gardien. La comparaison avec Jiminy Cricket est peut-être totalement inconnue pour un grand nombre de personnes ^^

Ce personnage dans Pinocchio représente la petite voix sur l'épaule qui nous fais nous poser des questions. C'est une personne supplémentaire qui va veiller à ce que la voix de l'Engineering soit entendue, en reformulant au passage, qui va veiller également à ce que les bonnes personnes, le/la Tech lead ou l'Engineering Manager, soient présentes autour de la table.

Questions

Quelques questions à vous poser pour déterminer si votre duo fonctionne bien.

Est-ce que vous avez régulièrement des discussions avec votre EM qui vous permettent d'améliorer radicalement vos plans ? Ou bien est-ce que vos discussions ressemblent à des champs de bataille ? Ou pire, est-ce que vous évitez les discussions car vous avez des avis irréconciliables sur les priorités ?

D'ailleurs question bête, mais est-ce que vous parlez stratégie entre vous, ou bien est-ce que votre relation est uniquement une relation hiérarchique "managé/manager" ?

Est-ce que vous avez en tête un moment dans les 6 derniers mois ou votre duo a créé un impact, et vous estimez qu'une partie du succès revient à votre EM qui a joué le rôle de caisse de résonance ?

Ou bien est-ce que vous avez le sentiment d'avoir joué dans deux équipes différentes et vous ressentez de la frustration de partager malgré tout les retombées positives avec cette personne ?

Est-ce que vous avez la sensation que votre duo fait toujours en sorte qu'il y ait les bonnes personnes autour de la table ? Par exemple, votre EM pense systématiquement à vous inclure au bon moment, au bon endroit ?
Ou bien est-ce que vous ressentez de la frustration d'avoir les informations trop tard et que l'Engineering Manager fait de la rétention d'information ou prend des décisions techniques à votre place dans des meetings dont vous n'avez pas connaissance ? Est-ce que vous pensez que votre Engineering Manager n'a pas les mêmes frustrations vous concernant et que vous ne pensez pas à l'inclure aux bons moments ?

Mais au pire, si jamais vous n'êtes pas dans une discussion, mais que votre Engineering manager l'est. Quel est le niveau de confiance existant entre vous, entre 1 et 5, sur le fait que l'autre prenne les bonnes décisions ?

1 étant "si je ne suis pas là, de très mauvaises décisions seront prises et il faudra que je repasse derrière pour tout corriger"

5 étant "j'ai super confiance, même si je ne suis pas là, on en a déjà discuté, il ou elle saura exactement quoi répondre, ou temporisera les discussions si vraiment je suis nécessaire."

Ressources

• Bill Campbell, le "trillion dollar coach"
• la répartition des tâches entre tech lead et d'EM sur engineeringladders.com
• engineering/manager pendulum de Charity Majors