J’ai déjà écrit plusieurs articles au sujet des collègues qu’on peut croiser au cours de notre vie professionnelle : les globalistes et les incrémentalistes, les affectifs, les revendicateurs, les nocifs…
Je vais maintenant vous partager une expérience qui est intéressante. Je ne vous souhaite pas de vous retrouver face à ce genre de situation, mais c’est bien d’y être préparé.

À un moment de ma carrière, j’ai postulé pour une entreprise qui cherchait un directeur technique. Dans ce cadre, j’ai été confronté à un type d’individu que je n’avais encore jamais rencontré.
Je vais vous raconter cette histoire, et voir les enseignements qu’on peut en tirer.

Les entretiens

Après un premier entretien très positif avec une représentante des ressources humaines, j’ai eu un entretien avec deux développeurs, le lead front et le lead back. Cet entretien se passe aussi très bien. Ils m’expliquent notamment que l’équipe a besoin d’une vraie direction technique, car elle a été un peu livrée à elle-même par les deux précédents⋅es CTO.

L’entretien suivant se passe avec le CEO, et là encore tout est au top. Nous sommes alignés sur notre vision des startups et de la technique dans une startup comme la sienne.

Ensuite, j’ai eu un entretien avec le lead QA et deux développeurs. Là, je me rends compte que je n’ai pas la même vision qu’eux sur un certain nombre de choses. Ce n’est pas forcément un souci, mais vu que j’étais complètement aligné avec celle du CEO, cela m’étonnait. J’en viens alors à poser des questions sur la direction de l’entreprise et sur les processus de prise de décision.
Les réponses que j’obtiens sont à charge contre le patron de l’entreprise. Sa communication et la manière dont il prend des décisions au sein du CODIR sont fortement décriées.

À la suite de cet entretien, le développeur le plus critique m’écrit sur LinkedIn pour me conseiller de prendre contact avec les anciennes CTO et CPO, pour que je comprenne « comment ça se passe au sein du CODIR » (sous-entendu, comprendre à quel point le CEO fait n’importe quoi, ce qui les a poussées à partir).
À ce moment-là, je suis assez interloqué. Quel est son but ? Me faire fuir ? Me dégoûter à tout prix de rejoindre cette entreprise ? C’est quand même bizarre… Si la boîte est si horrible que cela, pourquoi y reste-t-il ?

J’ai alors décidé de ne pas prendre contact avec ces personnes. Par contre, j’ai passé du temps (au téléphone et en réel) avec le CEO, lui disant que même s’il ne m’embauchait pas, il finirait par avoir des soucis avec certaines personnes de l’équipe technique.

J’apprends alors qu’à un moment donné, ces mêmes personnes ont tenté de convaincre le CEO de ne pas recruter de CTO, demandant qu’il leur laisse les rênes pour s’occuper de la technique. L’expérience a tourné court, les uns s’épuisant au contact du CEO, et lui se rendant compte que l’équipe a besoin de plus de structure.

Sur place

Avance rapide jusqu’à mon recrutement. Quand j’arrive, une majorité des membres de l’équipe technique sont partis ou sont sur le départ. Manifestement, les trois mois passés sans direction technique ont laissé des traces, les « leads » s’étant retrouvés en contact direct avec la direction.

J’ai découvert que celui qui avait voulu me mettre en contact avec les anciennes CTO et CPO avait le titre d’«ingénieur coordinateur». C’est un titre qu’on croise plus facilement dans le BTP ou les télécoms, jamais dans le développement logiciel (encore moins avec les méthodologies agiles). J’ai donc trouvé ça un peu étrange, il y avait forcément un sujet à creuser.

Les premières semaines après ma prise de poste, je m’attache comme d’habitude à parler avec tout le monde, dans l’équipe technique et en-dehors, pour comprendre ce qui fonctionne et ce qui ne fonctionne pas. Globalement, la situation est assez difficile : la dette technique est abyssale, la plateforme est fragile (on modifie à un endroit, ça pète ailleurs), les modifications prennent du temps (non seulement à cause de la fragilité, mais parce que tout est “over-engineered”), le site est extrêmement lent, et l’hébergement coûte très cher (s’il coûtait moins cher, ce serait encore plus lent).

Le CEO attendait de moi que je prenne des mesures rapides pour sortir de l’ornière. Au bout d’un mois d’observation et d’analyse, j’ai proposé des évolutions organisationnelles à l’équipe :

• Garder des sprints de développement de 2 semaines ; ça fonctionnait bien, pas la peine de changer ça.
• Ajouter du temps de tests utilisateurs avant les mises en production ; on m’avait dit que les évolutions n’étaient pas suffisamment testées (donc le nombre de bugs trouvés en prod était conséquent), et que les tests reposaient uniquement sur l’équipe technique (ce qui amenait un clivage avec le reste de l’entreprise). L’idée était ici de faire participer l’ensemble des “clients internes” aux tests, à la fois pour augmenter la qualité et la cohésion.
• Intégrer l’ensemble de l’équipe technique aux spécifications, de même que les clients internes. Le but étant de ne plus avoir une équipe produit qui rédige des spécifications depuis sa tour d’ivoire, mais de générer un sentiment de projet commun. Du temps est donné aux développeurs pour travailler sur ces spécifications, servant en même temps de cool-down entre les sprints pour éviter l’épuisement (qui avait été exprimé).
• Enfin, pour réduire la dette technique, je propose de consacrer du temps aux refactorings et aux débogages. Sans ça, impossible de revenir à quelque chose de plus sain.

Mon message était qu’on pouvait essayer ces modifications quelques mois, et ajuster en fonction des résultats. Les réactions sont allées de “Super, allons-y” à “Essayons, on modifiera si ça ne marche pas”. Sauf évidemment pour mon ingénieur coordinateur (sic), pour qui ce processus était forcément “inadapté” (le reste n’avait pas marché, et il n’avait jamais essayé cette manière de faire, mais il devait sûrement avoir une boule de cristal).

En fait, il s’est même mis en position frontale, en disant “si c’est une proposition, ça veut dire qu’on peut refuser ?”. Cette remarque est évidemment une tentative grossière de manipulation ; plutôt que de montrer qu’il était prêt à jouer le jeu et à essayer des choses nouvelles, il essayait de me pousser à imposer les choses, ce qui lui aurait permis de dire “Ah vous voyez, c’est un connard, il ne nous écoute pas !”. Manque de chance pour lui, mes propositions venaient justement du fait que j’avais écouté tout le monde, et le reste de l’équipe était prêt à essayer.
Il agitait même son fameux titre d’ingénieur coordinateur, pour justifier le fait que sa voix était plus importante que celle des autres.

À côté de ça, tous les développeurs front avaient quitté l’équipe. Nous étions donc un peu coincés à court terme, avec une stack front complexe, mais un seul développeur “full-stack mais avec une préférence pour le back”. Je lui ai donc demandé son avis sur le fait de revenir à des pages web générées côté serveur (permettant au passage d’harmoniser une situation où on avait du Twig + Vue 2 + Nuxt 2 + Vue 3 + Nuxt 3). Quelle aubaine pour lui, qui s’est alors mis à clamer que j’étais un CTO old-school qui ne comprenait rien à la technique.
[Alors qu’en fait, l’évolution moderne est plutôt à la simplification : voir ce qu’en dit DHH (en 2021, en 2023, durant la dernière keynote Rails World), ou encore le projet Symfony UX. C’est qui le has-been ?]
Pour moi, il fait partie des personnes visées par cet article sur le recrutement :

Les gens moyens sont souvent dans la catégorie « en savent assez pour être dangereux » parce qu’ils réfléchissent, travaillent et traitent tout de manière excessive par manque d’expérience plus complète pour découvrir des solutions plus simples et plus propres.

Enfin, lorsque je lui ai demandé de participer à mon onboarding en m’expliquant certains sujets qu’il était désormais le seul à connaître, sa réponse a été “C’est documenté, t’as qu’à lire le wiki”. J’ai répondu qu’une formation est plus efficace que lire un livre, ce à quoi il a rétorqué “Quand je suis arrivé on m’a rien expliqué, alors tu peux te débrouiller”. Ça, c’est un comportement très professionnel !

Alors pourquoi ?

Pourquoi tenait-il cette posture ? Très classiquement pour des questions d’ego et de pouvoir.

Il avait réussi à prendre un rôle assez central dans l’entreprise. Tous les échanges entre l’équipe technique et les autres équipes passaient par lui, ce qui lui avait permis d’être vu comme un apporteur de solutions, voire comme un faiseur de miracles.
Et même si’il faut reconnaître qu’il maîtrisait son sujet technique, il n’était quand même qu’un rouage d’une équipe d’une quinzaine de personnes (avant les départs massifs précédant mon arrivée).

Il avait donc de la considération au sein de l’entreprise, ce qui lui donnait de l’autorité sur les choix techniques. C’est ce qu’il avait cherché à entériner (et qu’il a obtenu) avec le titre d’ingénieur coordinateur, qui officialisait à ses yeux l’ascendant qu’il s’était construit.

D’après ce qu’on m’avait dit, les deux précédents directeur et directrice techniques étaient plus intéressés par les aspects liés au produit et avaient délégué les choix techniques aux développeurs. Il avait donc pu profiter de cette situation.

Donc ma présence, désirée par le PDG qui voulait quelqu’un qui remette la technique sur des rails, ne pouvait que le déranger. Et là où il aurait pu être professionnel et constater simplement qu’il n’était plus en phase avec l’entreprise, il a préféré jouer un jeu puéril jusqu’à son départ − critiquant la moindre de mes décisions sans discernement, et utilisant son influence auprès des autres développeurs pour rendre notre travail commun plus difficile.
Avant et après son départ, il a créé un climat délétère auprès du reste de l’équipe. Je sais que certains sont restés très pros et n’y ont pas participé, mais je n’ai pas d’illusions sur certains autres.

Quels enseignements en tirer ?

Des gens qui veulent tirer la couverture à eux, il y en a plein en entreprise. Parfois cela ne porte pas vraiment à conséquence, parfois cela mène à des comportements véritablement toxiques.

Là, tous les signaux étaient visibles dès le début ; lorsque la personne qui vous fait votre entretien d’embauche semble vouloir vous dissuader de rejoindre l’entreprise, c’est qu’il y a anguille sous roche. Je l’avais senti venir, c’est bien pour ça que j’en avais longuement discuté avec le CEO.
D’ailleurs, je m’étais assuré que le CEO et moi étions alignés dans nos visions. Car il est inutile de se battre contre quelqu’un qui veut votre poste (ou tout du moins les privilèges associés au poste) sans avoir le soutien de la direction, c’est une perte de temps et d’énergie colossale.
Par contre, il est difficile d’évaluer précisément à l’avance les dégâts qu’une telle personne peut faire sur une équipe.

Donc, dans une situation comme celle-ci, il faut savoir dépenser son énergie de manière utile, se concentrer sur l’essentiel. Montrer au manipulateur qu’il s’isole, pendant qu’on bâtit quelque chose avec le reste de l’équipe. Évidemment, son influence restera grande au début, mais elle diminuera avec le temps. Au final, vous pourriez même vous entendre bien avec ceux qui − suivant son exemple − vous insultaient dans votre dos.

Maintenant, si vous pouvez éviter ce genre de scénario, c’est mieux. Moi j’avais un vrai fit avec l’entreprise, son produit, ses équipes, et j’avais reçu des garanties par le CEO. Malgré tout, ce fut assez désagréable, au point de vous en parler aujourd’hui. Donc sans soutien ou sans garanties, fuyez.

Pour la petite histoire

Un peu plus de deux mois après son départ, nous avions enfin vécu un mois de travail efficace et − disons-le − agréable. Son influence se dissipait (au moins en façade), les membres de l’équipe se refocalisaient, et nous avions déployé des évolutions utiles. C’est alors que le PDG nous a annoncé qu’il revendait l’entreprise à son principal concurrent. Bon, tout ça pour ça…

Je me suis évidemment demandé si cet article n’allait pas jeter de l’huile sur le feu. Peut-être un peu. Mais de l’eau a coulé sous les ponts, j’espère que tout le monde est passé à autre chose.
Pour ma part, j’ai toujours partagé mon expérience sur ce blog, ça pourrait être utile à d’autres personnes. Je n’ai pas de raisons de ne pas le faire.