The slow death of the hands-on engineering manager
- Auteur
- manager.dev
- Thème
- Leadership
- Mots-clés
- engineering manager, hands-on, dette de compétence, mentorat technique, outillage interne
- Ton
- opinion
Résumé
Ce billet de la newsletter manager.dev part d'un constat chiffré : 95 % des engineering managers voudraient coder davantage mais s'en sentent incapables. L'auteur décrit le glissement progressif du manager « hands-on » vers le manager 100 % réunions, puis propose une méthode concrète pour renouer avec le code sans empiéter sur le chemin critique de l'équipe : choisir de petites tâches à fort bénéfice pour les développeurs. Il illustre cette approche avec deux exemples internes — un chatbot documentaire RAG construit par un collègue manager, et un outil d'automatisation qu'il a lui-même développé pour simplifier un processus pénible de copie de données.
💡 Pourquoi ça compte
Ce billet donne une méthode concrète et peu coûteuse en temps pour qu'un manager technique reste crédible et connecté au code, un enjeu d'autant plus sensible à l'ère des agents où l'on demande justement à ces managers d'accompagner l'adoption de l'IA par leurs équipes.
Analyse approfondie
Le texte s'ouvre sur le paradoxe vécu par beaucoup de managers techniques : on attend d'eux qu'ils aident leurs équipes à adopter l'IA efficacement, alors qu'ils peinent eux-mêmes à rester dans la pratique du code. L'auteur distingue deux trajectoires : le manager « super hands-on », qui prend des tâches à chaque sprint et connaît la base de code en profondeur, et le manager à plein temps en réunions, qui ne code plus du tout. Presque tout le monde commence dans la première catégorie et glisse vers la seconde — lui-même dit avoir vécu cette transition deux fois. Le mécanisme est insidieux : ce n'est pas un choix brutal mais une accumulation de sprints sans tâche de code, jusqu'à ce qu'une année entière passe sans qu'on ouvre son IDE. Le vrai obstacle au retour n'est alors plus le temps (il reste toujours deux ou trois heures disponibles par semaine) mais la perte de l'habitude et l'auto-persuasion qu'on ne pourra rien produire d'utile en si peu de temps.
Pour sortir de ce piège, l'auteur recommande de choisir des tâches précises, hors du chemin critique, qui répondent à l'un des trois critères suivants : aider concrètement les ingénieurs de l'équipe, apprendre quelque chose de nouveau, ou traiter un sujet utile à l'entreprise que personne d'autre ne prendra en charge. Il détaille un premier exemple vécu par un collègue manager avec huit ans d'ancienneté dans l'entreprise : interrompu en permanence par les mêmes questions sur des parties historiques du code, il a fini par documenter ses réponses — sans succès, car personne ne consultait cette documentation, non par paresse mais parce qu'elle restait invisible. Sa solution a été de construire, à partir d'un dépôt open source existant (sans compétence frontend requise), un chatbot interne interrogeant Confluence, les README GitHub et les canaux Slack publics de l'entreprise, avec à la clé un article détaillé publié sur Medium expliquant la démarche technique (RAG, Langchain, base vectorielle).
Le second exemple est personnel : lors d'une rétrospective, un membre de l'équipe se plaint d'un processus long et pénible de copie de données de production vers les environnements de QA, jusque-là géré par un job Jenkins limité à de petits volumes. L'auteur construit alors une interface simple (avec l'aide de ChatGPT, se disant « nul en CSS ») et un backend Python qui permet de lancer la copie selon des critères précis et de recevoir une notification par e-mail (via SendGrid) une fois l'opération terminée. Il souligne le double bénéfice de ce type de projet : améliorer concrètement le quotidien des ingénieurs, tout en permettant au manager d'apprendre quelque chose de nouveau au passage. Sa conclusion est un plaidoyer pour que tout manager technique, jusqu'au CTO, conserve une pratique minimale du code — rendue plus soutenable en choisissant des tâches modestes, à son propre rythme.