De développeur à CTO : ce que personne ne te dit

Le passage de développeur à CTO est la transition de carrière la plus mal comprise en tech. Les gens supposent que c'est devenir un meilleur ingénieur. Ce n'est pas ça. C'est devenir un type de professionnel complètement différent.

J'ai fait cette transition moi-même, d'abord comme CTO chez OneRagtime puis à travers différents rôles de leadership. J'enseigne maintenant un module appelé "Developer to CTO" à Harbour.Space University à Barcelone. À chaque cohorte, je regarde des étudiants confronter les mêmes prises de conscience que j'ai eues il y a des années.

Voici ce que personne ne te dit sur cette transition.

Ta meilleure compétence devient ton plus gros handicap

En tant que développeur, tu as été promu parce que tu écrivais du bon code. Tu résolvais des problèmes difficiles. Tu livrais des fonctionnalités. Ta valeur était directement liée à ta production.

En tant que CTO, écrire du code est généralement une mauvaise utilisation de ton temps. Pas parce que coder est en dessous de toi, mais parce que ton job a changé. Tu n'es plus responsable d'écrire le meilleur code. Tu es responsable de t'assurer que le meilleur code soit écrit.

J'ai galéré avec ça chez OneRagtime. Au début, c'est moi qui construisais tout : la Platform, le Core, Deepdive. J'étais plongé dans la codebase Django, écrivant du Python, déployant sur Docker Swarm. Et ça faisait du bien parce que c'était familier. Je savais que j'étais productif parce que je pouvais le mesurer en commits et en fonctionnalités.

Mais au fur et à mesure que l'équipe grandissait, chaque heure passée à coder était une heure que je ne passais pas sur les choses que moi seul pouvais faire : définir la direction technique, aligner le travail d'engineering avec la stratégie business, ou débloquer des gens qui étaient coincés.

Le jour le plus dur de ma carrière a été celui où j'ai réalisé que je devais fermer mon IDE et commencer à passer la majorité de mon temps en réunions, dans des documents et en one-on-one. Ça ressemblait à une rétrogradation. Il m'a fallu des mois pour accepter que c'était ça, le vrai job.

La crise d'identité est réelle

Les développeurs ont une identité claire. Tu écris du code. Tu résous des problèmes techniques. Tu as un craft, et tu t'améliores au fil du temps. Il y a une satisfaction là-dedans qui est difficile à reproduire.

Quand tu deviens CTO, cette identité se dissout. Tes journées sont remplies d'activités qui ne ressemblent pas à du "vrai travail." Tu es en réunion sur le recrutement. Tu revois des budgets. Tu expliques des contraintes techniques à des investisseurs. Tu arbitres des désaccords entre membres de l'équipe. Tu écris des documents que personne ne lira.

À la fin d'une journée typique en tant que CTO chez OneRagtime, je ne pouvais souvent pas pointer vers une seule chose concrète que j'avais "construite." Pas de code, pas d'architecture, pas de fonctionnalité déployée. Juste des conversations, des décisions et des plans. Il m'a fallu du temps pour comprendre que ces conversations et ces décisions étaient le produit de mon travail.

Je dis à mes étudiants à Harbour.Space : si tu mesures ta productivité par ce que tu construis de tes mains, le leadership te semblera profondément insatisfaisant. Tu dois apprendre à la mesurer par ce que ton équipe construit.

Ce qu'il faut arrêter de faire

Voici une liste concrète de choses que j'ai dû arrêter de faire quand je suis passé de développeur à CTO. Cette liste m'aurait économisé un an d'erreurs.

Arrête d'être le premier à répondre aux questions techniques. Quand quelqu'un dans ton équipe demande comment résoudre un problème, ton instinct est de répondre immédiatement. Résiste. Demande-lui d'abord ce qu'il en pense. Si tu as toujours la réponse, ton équipe ne développe jamais la capacité de trouver des réponses par elle-même.

Arrête de relire chaque pull request. Tu n'as pas besoin d'approuver chaque ligne de code. Définis des standards de code, mets en place des vérifications automatisées, et fais confiance à tes développeurs seniors pour se relire mutuellement. Ta review devrait être réservée aux décisions d'architecture, pas aux détails d'implémentation.

Arrête d'optimiser pour la meilleure solution technique. La meilleure solution technique n'est pas toujours la bonne. Parfois la solution "suffisante" qui sort cette semaine est meilleure que la solution parfaite qui sort le mois prochain. Ton job est de faire cet arbitrage, et ça demande de comprendre le contexte business, pas seulement le contexte technique.

Arrête de travailler seul. En tant que développeur, tu pouvais mettre tes écouteurs et disparaître dans un problème pendant des heures. En tant que CTO, l'isolement est dangereux. Les décisions que tu prends affectent toute l'équipe. Si tu les prends sans input, tu feras des erreurs qui auraient pu être facilement évitées.

Ce qu'il faut commencer à faire

Commence à déléguer le travail dans lequel tu es le meilleur. C'est contre-intuitif. Tu veux déléguer le travail que tu n'aimes pas et garder ce qui est intéressant. Fais l'inverse. Délègue le travail technique intéressant à ton équipe. Garde le travail organisationnel, stratégique et humain pour toi. C'est là que tu apportes le plus de valeur maintenant.

Commence à communiquer les décisions techniques en termes business. Quand je proposais des changements d'architecture chez OneRagtime, j'ai arrêté de les présenter comme des améliorations techniques. À la place : "Ce changement va nous permettre de livrer le dashboard investisseur deux semaines plus vite" ou "Cette migration va réduire nos coûts d'infrastructure de 30 %." Les interlocuteurs business se fichent d'une architecture propre. Ils se soucient de la vitesse et des coûts.

Commence les one-on-one. Des conversations régulières et planifiées avec chaque personne de ton équipe. Pas des points d'avancement. De vraies conversations sur comment ils vont, ce qui les frustre et ce qu'ils veulent apprendre. Chez Consentio, mes one-on-one avec chacun de mes dix ingénieurs sont les réunions les plus importantes de mon agenda. C'est là que j'apprends ce qui se passe vraiment, pas dans les boards Jira ou les standups.

Commence à dire "je ne sais pas." En tant que développeur, admettre que tu ne sais pas quelque chose donne l'impression d'incompétence. En tant que CTO, c'est essentiel. Tu ne peux pas être expert dans tout ce que fait ton équipe. Dire "je ne sais pas, mais je vais me renseigner" ou "je ne sais pas, qu'est-ce que tu en penses ?" construit plus de confiance que de prétendre avoir toutes les réponses.

Les compétences que personne n'enseigne

Il y a des compétences dont tu as besoin en tant que CTO qu'aucun programme d'ingénierie ne couvre.

Le recrutement. Lire des CV, mener des entretiens, évaluer la compatibilité culturelle, vendre ta boîte aux candidats. J'étais mauvais au début. J'ai recruté des gens techniquement forts mais incapables de collaborer. Il m'a fallu plusieurs expériences douloureuses pour apprendre qu'un excellent développeur qui ne peut pas travailler avec les autres est pire qu'un bon développeur qui le peut.

La résolution de conflits. Les équipes techniques sont en désaccord. Sur l'architecture, sur les priorités, sur le style de code. Ton job est de résoudre ces désaccords d'une manière qui maintient le respect et fait avancer l'équipe. C'est plus dur que n'importe quel problème technique que j'ai rencontré.

La gestion de budget. Comprendre les coûts d'infrastructure, planifier les effectifs, prévoir les dépenses engineering. Chez OneRagtime, je devais justifier chaque recrutement d'ingénieur auprès des investisseurs. Chez Consentio, je gère des budgets qui impactent directement la rentabilité de l'entreprise. Personne ne m'a enseigné ça. J'ai appris en faisant des erreurs.

La gestion des parties prenantes. Traduire entre la réalité de l'engineering et les attentes business. Quand un product manager demande une fonctionnalité "pour vendredi", ton job est d'expliquer ce qui est réaliste sans être dédaigneux. Quand le CEO demande pourquoi quelque chose prend si longtemps, tu dois traduire la complexité technique en termes qu'il peut comprendre et sur lesquels il peut agir.

La transition prend plus de temps que tu ne crois

À Harbour.Space, je donne aux étudiants un calendrier : attends-toi à ce que la transition de développeur à CTO prenne deux à trois ans avant de te sentir vraiment à l'aise. Pas deux à trois mois. Des années.

Pendant ce temps, tu te sentiras imposteur. Le code te manquera. Tu te demanderas si tu as fait le bon choix. Tu auras des jours où tu voudras jeter les livres de management et simplement ouvrir ton laptop pour coder.

C'est normal. Chaque CTO que je respecte est passé par là. Ceux qui ont réussi à traverser cette phase l'ont fait en acceptant que l'inconfort fait partie du processus, ce n'est pas un signe que quelque chose ne va pas.

Est-ce que ça en vaut la peine ?

On me pose cette question à chaque cohorte. Ma réponse est toujours la même : ça dépend de ce qui te motive.

Si tu es motivé par le craft de l'écriture de code, par l'élégance d'une fonction bien conçue, par la satisfaction de résoudre un problème technique difficile de tes propres mains, alors reste contributeur individuel. Il n'y a rien de mal à ça. Les ingénieurs senior et staff ont un impact énorme.

Si tu es motivé par construire des choses qui comptent, par voir un produit réussir sur le marché, par regarder une équipe grandir et s'améliorer, alors le chemin de CTO vaut l'inconfort. Le levier est différent. Tu ne construis plus la chose. Tu construis l'équipe qui construit la chose. Et quand ça marche, la satisfaction est profonde.

C'est ce que j'essaie de transmettre à Harbour.Space. Pas que tout le monde devrait devenir CTO. Mais que ceux qui choisissent de le faire devraient savoir dans quoi ils s'engagent vraiment.