Engineering Manager ou Tech Lead : de quoi avez-vous vraiment besoin ?

Les fondateurs de startups qui cherchent à structurer leur équipe technique tombent souvent sur le même réflexe : recruter un Tech Lead. C'est un titre rassurant, qui évoque un profil expérimenté capable de porter la technique. Mais dans la majorité des cas, ce n'est pas d'un Tech Lead dont ils ont besoin. C'est d'un Engineering Manager. Et la confusion entre les deux rôles est l'une des erreurs d'organisation les plus fréquentes que je rencontre.

Deux rôles, deux missions très différentes

Le Tech Lead est avant tout un expert technique. C'est en général un développeur très expérimenté qui connaît les bons patterns à appliquer, les pièges à éviter, et qui peut prendre les décisions d'architecture les plus structurantes. Le mot "technique" dans son titre a toute son importance : c'est un leader sur le plan du code, pas sur le plan humain. Il ne gère pas les carrières, ne fait pas d'entretiens individuels, ne s'occupe pas de la montée en compétence de l'équipe au-delà de la dimension purement technique.

L'Engineering Manager, à l'inverse, est un manager. Sa mission première est de faire grandir les développeurs qui composent son équipe : gérer leur progression de carrière, identifier leurs forces et leurs axes d'amélioration, s'assurer qu'ils s'épanouissent dans leur travail et qu'ils progressent. C'est aussi ou c'était aussi un développeur, mais ce n'était pas forcément le meilleur d'entre eux. Ce qui le distingue, c'est avant tout une appétence pour le management et pour tout ce qui fait qu'une équipe fonctionne bien ensemble : la répartition de la charge, l'équilibre entre temps forts et temps faibles, la vélocité collective.

L'intelligence collective plutôt que l'expertise centralisée

En général, les entreprises qui cherchent des Tech Leads n'ont pas compris que la principale force d'une équipe technique réside dans son intelligence collective et dans sa résilience. Avoir un Tech Lead va à l'encontre de tout ça : il centralise des compétences au lieu de les faire rayonner dans l'équipe. Si cette personne part, prend des vacances ou veut simplement changer de projet, l'équipe se retrouve démunie sur les sujets qu'elle portait seule.

C'est l'inverse que je cherche systématiquement. Plutôt que de concentrer l'expertise chez une seule personne, je préfère répartir le rôle de leadership technique entre les membres de l'équipe. Chaque développeur senior peut porter une partie de cette responsabilité : l'un est référent sur les choix d'architecture, l'autre sur les pratiques de test, un troisième sur la performance. Cette répartition rend l'équipe beaucoup plus résiliente et permet à chacun de monter en compétence sur des sujets qui dépassent son périmètre habituel.

La bonne progression : du dev au manager

La transition vers le rôle d'Engineering Manager ne se décrète pas du jour au lendemain. C'est un chemin progressif que j'ai pu observer et accompagner chez quasiment tous les Engineering Managers avec qui j'ai travaillé. Le schéma est presque toujours le même : un développeur commence à s'intéresser à ce qui pourrait rendre l'équipe meilleure. Il passe souvent par un rôle de Scrum Master, ce qui lui donne une première exposition aux dynamiques d'équipe, à la facilitation et aux problèmes d'organisation. C'est là qu'il prend conscience de ce qu'il peut apporter au-delà du code : plus d'épanouissement au travail pour ses collègues, une meilleure vélocité collective, une répartition plus intelligente de la charge.

On lui confie ensuite des responsabilités progressives. D'abord l'encadrement d'un stagiaire, puis d'un alternant. Si ça fonctionne, il bascule petit à petit vers un rôle d'EM sur une petite équipe de 4 à 5 personnes, avant éventuellement de prendre une équipe plus grande pouvant aller jusqu'à 10 personnes. Cette progression graduelle a un double avantage : on peut évaluer le candidat à chaque étape, et lui-même peut décider si le rôle lui convient vraiment. J'ai vu des développeurs excellents tester le management et revenir vers un rôle purement technique sans que personne ne le vive mal, justement parce que la transition avait été progressive.

Un point essentiel dans cette transition : il faut essayer de laisser à l'Engineering Manager au moins 50% de son temps en développement. Ne pas perdre la main sur son expertise technique lui permet de rester crédible auprès de son équipe et surtout de bien comprendre les enjeux concrets de ses collaborateurs. Un manager qui ne code plus du tout finit par perdre le contact avec la réalité du terrain, et les développeurs le sentent très vite.

Comment repérer les bons candidats internes

Le signal le plus fiable que j'ai observé, c'est le développeur qui commence spontanément à réfléchir à comment l'équipe pourrait aller encore mieux. Pas uniquement sur le plan technique, mais sur le plan organisationnel et humain. Les entretiens trimestriels sont un excellent moment pour sonder cette appétence : demander à chaque développeur comment il se voit évoluer dans les 2, 5 et 10 ans à venir permet de détecter ceux qui envisagent naturellement une trajectoire managériale.

Quand le Tech Lead en prestation fait sens

Il existe tout de même des situations où une expertise technique pointue est nécessaire et où personne dans l'équipe ne la possède. Dans ce cas, plutôt que de recruter un Tech Lead permanent, je recommande de faire appel à un expert en prestation courte, de 3 à 6 mois maximum. J'ai par exemple fait intervenir des SRE pour mettre en place une infrastructure de monitoring, des experts en développement mobile pour lancer une application native, ou des spécialistes data pour structurer un premier pipeline. La mission est claire : mettre en place le projet, former l'équipe, transmettre les connaissances, puis partir en laissant le projet entre de bonnes mains.

Cette approche a plusieurs avantages considérables. D'abord, c'est l'équipe entière qui monte en compétence, pas une seule personne. Ensuite, le prestataire sait qu'il est là de manière temporaire, ce qui élimine les questions d'ego et de territoire. Il n'a aucun intérêt à garder son expertise pour lui puisque sa mission est précisément de la transférer. On apporte ainsi une bien plus grande résilience à l'équipe, et on évite le risque classique d'avoir une compétence critique concentrée chez une seule personne qui peut partir du jour au lendemain.

Le cas du fondateur non technique

Il y a un cas de figure où recruter un Engineering Manager en externe fait particulièrement sens : quand les fondateurs exercent d'autres expertises, que ce soit le métier, le marketing, les sales ou le produit, et ne se sentent pas légitimes à manager des développeurs. Dans ce contexte, l'EM est le premier profil technique à structurer. Il saura aussi faire du développement, ce qui est crucial dans une petite équipe, mais sa valeur ajoutée principale sera de manager l'équipe tech avec la crédibilité technique que les fondateurs n'ont pas. C'est un choix bien plus pertinent qu'un Tech Lead qui ne fera que du code sans s'occuper de la dimension humaine.

En résumé

Avant de publier une offre de Tech Lead, posez-vous la question de ce dont vous avez réellement besoin. Dans la grande majorité des cas, c'est un Engineering Manager qui fera la différence : quelqu'un capable de faire grandir votre équipe, de maintenir sa cohésion et de distribuer l'expertise plutôt que de la centraliser. Faites-le émerger en interne en identifiant les développeurs qui s'intéressent naturellement aux dynamiques d'équipe, et laissez les expertises techniques pointues à des prestations ciblées et temporaires.