La complainte d’un Tech Manager : « je suis passé du commit quotidien aux réunions interminables »

Le monde de la tech, ce n’est pas toujours tout beau, tout rose. Derrière les projets, les réussites, les livraisons, il y a aussi de la fatigue, des doutes, et disons-le, un vrai ras-le-bol parfois.

Cette série d’articles, que l’on a naturellement baptisée “La Complainte”, donne la parole à des techs, des managers, des CTO, des SRE… Un exutoire pour livrer en tout anonymat leurs galères. L’occasion de mettre des mots sur ce qu’on ne voit pas toujours, et d’esquisser des pistes de solutions.

Dans ce premier épisode, le bâton de parole est donné à un Tech Manager. Il nous raconte l’histoire du jour où il a dû googler une commande kubectl basique devant ses équipes. Un détail en apparence, mais qui lui a fait comprendre qu’il perdait peu à peu sa technique au profit des réunions et des arbitrages. Place à la complainte.

Découvrir nos services d’ESN

Le récit qui suit est à la première personne, tel qu’il nous a été confié. Toute ressemblance à votre quotidien… est une ressemblance à votre quotidien.

Je m’appelle Loïc [ndlr : prénom modifié pour préserver la complainte]. J’ai 38 ans, et ça fait plus de quinze ans que je suis dans la tech.

Aujourd’hui je suis Tech Manager dans un grand groupe de l’agroalimentaire. Avant ça, j’étais développeur senior, spécialisé en Java et Spring Boot. Je passais mes journées à concevoir des API pour nos applications internes, à optimiser des batchs qui tournaient la nuit, et à bricoler des scripts SQL pour faire parler SAP et nos applis maison. Je touchais aussi au déploiement avec Kubernetes, que ce soit pour relancer un pod en crashloop ou configurer un helm chart.

C’était concret, gratifiant. Je pouvais finir ma journée en sachant que j’avais réglé un bug critique qui bloquait la production ou amélioré un algo de planification des livraisons. J’avais moins de réunions, plus de temps pour me plonger dans un sujet de fond. Et surtout, j’avais le sentiment de progresser techniquement.

Quand on m’a proposé le poste de Tech Manager, j’étais aux anges. Pour moi, c’était une étape logique dans ma carrière. Je le précise : j’aime mon poste. J’aime confronter ma vision, écouter celle des autres, accompagner mes équipes. Mais la vérité, c’est qu’on perd petit à petit le terrain. Et c’est ça qui me manque le plus.

Au début, les réunions ne me faisaient pas peur, bien au contraire. J’avais envie de participer à la stratégie, de porter une vision. Mais au fil des jours, elles ont commencé à prendre plus de place. Un comité de pilotage par-ci, une réunion métier par-là, et sans que je m’en rende compte, mon agenda était rempli. Je ne choisis plus vraiment mes priorités : elles sont dictées par les invitations qui tombent.

Le souci, c’est que ça ne me laisse plus beaucoup de temps pour lire de la documentation, me renseigner sur un nouveau langage ou débattre avec mes collègues. Et j’ai aussi cette impression de produire moins de concret. Je ne plonge plus dans un sujet comme avant : monter un POC, tester une nouvelle techno, ou creuser un problème jusqu’à le connaître sur le bout des doigts. Je suis passé du commit quotidien aux réunions interminables. Je sais que ça fait partie du rôle, mais mon âme de tech en souffre. 

Et en parallèle, il y a toujours autant de pression métier. On me demande d’aller plus vite, de livrer hier. Je dois trancher, accepter des compromis techniques qui sont parfois bancals. Je crois que c’est ça qui me frustre le plus : je dois défendre des choix que je ne maîtrise plus autant qu’avant.

Le problème ce n’est pas le poste. J’ai découvert le management, et je trouve ça gratifiant de voir mes équipes monter en compétences, évoluer, me challenger. Ce n’est pas non plus une question d’ego. J’adore qu’on me montre de nouvelles façons de faire.

Ce qui me fait peur, c’est de perdre le lien avec le terrain. Je ne veux pas devenir un manager déconnecté, qui ne raisonne qu’en termes de roadmap et de livraisons. Je veux être capable de comprendre les choix techniques, de prendre les bonnes décisions, de ne pas vendre du rêve aux chefs de projets. Quand on est leader technique, on a cette responsabilité-là.

Et puis il y a eu, ce que je qualifie de “kubectl de la honte”. C’était un lundi matin, en daily. En plein partage d’écran, un dev me demande de vérifier quelque chose sur Kubernetes. Une commande kubectl basique, je l’avais utilisée des centaines de fois. Et là, je m’en souviens plus. J’ai dû aller chercher sur Google. Personne n’a rien dit, ils ont été bienveillants. Mais moi, je me suis senti à côté de la plaque. Avant, ça je le faisais les yeux fermés.

Je me suis dit : si je continue comme ça, je deviens un chef de projet déguisé en Tech Manager. Et ce n’est pas ce pour quoi j’ai signé.

Quand j’ai pris conscience de ça, je suis allé chercher des conseils. J’ai discuté avec d’autres Tech Managers dans l’entreprise, avec des amis qui bossent dans d’autres secteurs, j’ai même contacté mon ancien manager. Je voulais savoir comment ils faisaient, comment ils arrivaient à garder un pied dans la technique malgré la charge de travail.

Les retours ont été assez similaires. Un collègue m’a dit qu’il s’impose une session de pair programming chaque semaine, coûte que coûte. Une amie m’a raconté qu’elle choisit une seule merge request par semaine, mais qu’elle la suit jusqu’au bout. Mon ancien manager, lui, organise des “lunch & learn” avec son équipe, où chacun partage une découverte technique.

Et tous m’ont dit la même chose : il faut apprendre à dire non. Non aux réunions où ta présence ne sert à rien. Non aux comités où tu n’apportes rien.

J’ai aussi fini par comprendre qu’on ne peut pas tout assumer seul. Parfois, il faut du renfort technique. Je me souviens d’un prestataire venu filer un coup de main sur une migration Kubernetes. Il a réglé en deux jours un blocage qu’on traînait depuis des semaines. Et au passage, il m’a montré une autre façon de mettre en place du monitoring. Rien que ça, ça m’a redonné le goût d’apprendre.

Après mon passage à blanc avec ce kubectl, j’ai décidé de tester plusieurs rituels, pour voir ce qui me convenait.

J’ai commencé simple : un ticket par sprint. Pas énorme, mais suffisant pour garder les mains dedans. Une session de pair programming par mois. Et une demi-journée par mois, bloquée dans mon agenda, pour explorer un sujet technique sans interruption. Je fais ça depuis 6 mois maintenant.

Et honnêtement, c’est à partir du moment où j’y ai consacré du temps que j’ai vu la différence. Ce n’est jamais facile quand on est dans le rush, mais selon moi, la clé, c’est de créer des habitudes, et arrêter de reporter.

Grâce à ça, j’ai retrouvé ce petit plaisir que j’avais perdu : résoudre un bug, tester une nouvelle approche, discuter d’architecture. J’ai même remis les mains dans le cambouis récemment : j’ai corrigé un bug tout bête sur le module de facturation. L’équipe m’a chambré, on m’a demandé ce que ça faisait de remettre le nez là-dedans. Ça m’a fait sourire.

Je sais que je ne redeviendrai pas un dev à temps plein. Mais je sais aussi que je peux rester crédible dans mon leadership technique. Peut-être que je ne commit plus chaque jour, mais je veux rester un Tech Manager qui parle encore la langue du code.

Merci d’avoir écouté ma complainte.