Les signaux précurseurs de la dépression technique et psychologique de votre CTO

Depuis que je fais ce métier, j’ai entendu toutes sortes de raisons invoquées par le management technique pour ne pas faire un audit ou ne pas outsourcer telle ou telle partie.

Quand il s’agit d’une décision d’outsourcing de la maintenance ou du dev, les raisons invoquées sont soit un risque pour l’IP, soit un risque de perte de contrôle technique. Le premier, dans le cas d’une société comme Pentalog n’a tout simplement aucun sens. Si nous avions organisé des fuites d’IP de nos clients, il y a longtemps que nous serions morts. Pentalog Software Factory développera cette année plus de 250 produits pour ses clients. Ça se saurait. Les vraies raisons de ce refus peuvent parfois être ailleurs.

Crédit photo : Shutterstock

En aucun cas ce que je vais dire ici ne doit être pris pour une généralité. Heureusement nos clients et nos prospects sont majoritairement des gens d’expérience. De même que les tâches de recherche et le leading des devs doivent autant que possible être assumées par des collaborateurs directs de l’entreprise. Là non plus, mon propos n’est pas de faire un plaidoyer pro-domo. En tant qu’investisseur direct ou indirect dans plus de 300 startups, je suis très attentif à trouver le chemin critique de la startup.

Mais il y a parfois des cas où le refus de se faire aider cache des peurs non exprimées encore. Par exemple quand l’architecture technique est réputée stabilisée, ainsi que les choix techno, les normes de codage…, que c’est le CEO qui vous a sollicité pour rattapper du retard et que, pourtant, le CTO traîne les pieds, en disant que c’est une bonne idée… mais que c’est un peu tôt. Là il peut y avoir baleine sous gravillon.

D’abord de très nombreuses startups n’ont pas vraiment de CTO, même si elles ont quelqu’un qui porte ce titre. 25-26 ans, aucune expérience du feu, n’a jamais eu plus de 10 users dans un système, jamais travaillé sur une grosse plateforme et là… la traction explose ! Panique. J’ai une dizaine de gens que j’adore en tête en écrivant ces lignes. Il y en a qui ont découvert le mot DevOps avec nous, qui n’avaient jusqu’ici jamais envisagé qu’un dev allait en production un jour. Je parle de sociétés où l’on parle tout le temps du produit et de la tech alors qu’on lui alloue le moins possible. Un jour ou l’autre, on a tous connu ça.

Il y a d’autres cas. Tout début 2016, j’ai croisé un CTO de 35 ans, absolument épuisé. Incapable de parler correctement sous l’effet de la fatigue. Contexte : hyper succès de la startup mais le CEO n’a jamais su financer la technique. Résultat son CTO associé fait TOUT, tout seul : les choix techno, le monitoring des serveurs qui le réveille la nuit, ses 3 dev sont juniors ou stagiaires et il les anime seul. Et là paf… le drame pour lui, le moment tant attendu arrive enfin. Levée de fond énorme. Il faut scaler et pour scaler il faut industrialiser. Le mur de la dette technique arrive alors à toute vitesse.

J’ai rarement vu un garçon qui avait autant besoin d’aide. Physiquement. Pourtant il a tout fait pour que nous ne l’aidions pas. Et il y a réussi. Il a continué à souffrir et il a pris la décision qu’il ne fallait pas prendre à ce moment précis : recruter très vite, tel que le plan avait été formulé pour les VCs. Il avait plutôt besoin d’une aide immédiate en organisation, puis de mettre en œuvre une équipe outsourcée pour rattrapper de la dette techno et délivrer au plus vite… et enfin de recruter en prenant le temps de bien construire son équipe. Il faut dire aussi qu’il y a les VC français et leur obsession des équipes internes. Comme si les gens leur appartenaient quand ils sont en contrat de travail ! Le statut de collab. interne n’a de sens que si vous envisagez clairement de distribuer du capital. Autrement, dans ce monde de compétition, le mot appartenance n’a pas de sens. Ce qui compte c’est que le code soit propre, récupérable, portable, commenté, audité, et délivré le plus rapidement possible. Et j’ai rarement vu une startup on-boarder 15 personnes en 4 semaines comme nous sommes capables de le faire quand il faut aller vite.

Demandez un devis

Des signaux faibles qui s’accumulent, précurseurs de dépressions techniques… et humaines

Pourquoi je vous parle de ça ? Pour vous sensibiliser à tous ces petits signaux plus ou moins faibles. Que vous soyez un CTO qui n’a pas encore conscience qu’il se cache la réalité ou que vous soyez un CEO qui n’a pas l’impression de voir une production de code aussi agile qu’on le lui dit, ce post est pour vous. Quand les délais s’allongent systématiquement, quand on refuse l’aide, quand les moyens augmentent fortement mais que les nouveaux produits sortent de moins en moins vite, quand l’équipe technique repousse l’intervention d’une aide extérieure, quand on vous dit que la dette ne se compare pas, quand on vous dit que la vélocité est un indicateur théorique… n’attendez pas et réagissez immédiatement, car votre capacité d’innovation et votre équipe sont déjà en danger.

Une gouvernance agile et des KPIs, c’est la promesse que nous faisons au CTO et au CEO

Nous rencontrons ces situations plus souvent que vous l’imaginez. Je pense dans au moins 10% des cas aux US et 20% en Europe. Les meilleurs acteurs de la profession ont le discours et des méthodologies pour vous aider à réaligner vos projets par :
– le partage plus équilibré des tâches et la reconnaissance des responsabilités,
– l’implémentation d’une gouvernance technique pour casser l’opacité de la réalisation technique et créer un langage commun entre l’équipe technique et les autres fonctions de l’entreprise.

Pentalog est aujourd’hui un expert de la gouvernance de la delivery technique. Nous avons réussi à couvrir 90% de nos projets de KPIs agiles, et d’une évaluation continue de la dette, comparables et accessibles à tous les acteurs.

Et enfin… communiquer !

Quand ces situations se produisent il faut le plus vite possible faire admettre à vos collaborateurs qu’ils ne sont pas les seuls à être passés par là et que l’entreprise a besoin de tout le monde pour réussir. C’est par là qu’il faut commencer. Il y a finalement très peu de cas où les personnes ne peuvent pas être aidées et doivent quitter l’équipe. On est heureusement bien plus souvent entre coaching agile/conseil technique et plus rarement repositionnement vers une fonction plus adaptée.

Que ce soit pour un consulting ponctuel ou un outsourcing long, toute mission doit de toute façon commencer par un travail en commun, sur site, les yeux dans yeux. Travailler en agile requiert la confiance, de se sentir collègues. C’est ce que nous appelons chez nous le pivot. Ça marche à chaque fois. Entre autres deliveries de cette phase, outre la confiance, nous amenons le cadre de gouvernance de la relation. Bref plus de sérénité.

Qu’il soit outsourcé ou non, le développement est un processus très complexe et qui incarne littéralement la création de valeur de l’entreprise. C’est un processus technique où « presque » tout est prévisible tant que l’on a les connaissances et l’expérience, seules les erreurs humaines peuvent le dévoyer et elles sont normales dans un environnement de R&D en ajustement permanent. Ce qui est moins normal, c’est de croire que l’on ne peut rien faire pour améliorer sa performance et laisser le système se transformer en boîte noire dans laquelle plus rien ne peut plus être challengé, ni les hommes, ni les KPIs. Les outils et les méthodes de management existent, mais c’est à vous CTO et CEO, de vous assurer que toute votre production technique est encadrée et quantifiable.

Lisez aussi l’interview d’un directeur de projets en mode agile de Pentalog pour une startup française.