De développeur à CTO : ce que personne ne vous 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 vous dit sur cette transition.

Votre meilleure compétence devient votre plus gros handicap

En tant que développeur, vous avez été promu parce que vous écriviez du bon code. Vous résolviez des problèmes difficiles. Vous livriez des fonctionnalités. Votre valeur était directement liée à votre production.

En tant que CTO, écrire du code est généralement une mauvaise utilisation de votre temps. Pas parce que coder est en dessous de vous, mais parce que votre job a changé. Vous n'êtes plus responsable d'écrire le meilleur code. Vous êtes responsable de vous 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. Vous écrivez du code. Vous résolvez des problèmes techniques. Vous avez un craft, et vous vous améliorez au fil du temps. Il y a une satisfaction là-dedans qui est difficile à reproduire.

Quand vous devenez CTO, cette identité se dissout. Vos journées sont remplies d'activités qui ne ressemblent pas à du "vrai travail." Vous êtes en réunion sur le recrutement. Vous revoyez des budgets. Vous expliquez des contraintes techniques à des investisseurs. Vous arbitrez des désaccords entre membres de l'équipe. Vous écrivez 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 vous mesurez votre productivité par ce que vous construisez de vos mains, le leadership vous semblera profondément insatisfaisant. Vous devez apprendre à la mesurer par ce que votre é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êtez d'être le premier à répondre aux questions techniques. Quand quelqu'un dans votre équipe demande comment résoudre un problème, votre instinct est de répondre immédiatement. Résistez. Demandez-lui d'abord ce qu'il en pense. Si vous avez toujours la réponse, votre équipe ne développe jamais la capacité de trouver des réponses par elle-même.

Arrêtez de relire chaque pull request. Vous n'avez pas besoin d'approuver chaque ligne de code. Définissez des standards de code, mettez en place des vérifications automatisées, et faites confiance à vos développeurs seniors pour se relire mutuellement. Votre review devrait être réservée aux décisions d'architecture, pas aux détails d'implémentation.

Arrêtez 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. Votre job est de faire cet arbitrage, et ça demande de comprendre le contexte business, pas seulement le contexte technique.

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

Ce qu'il faut commencer à faire

Commencez à déléguer le travail dans lequel vous êtes le meilleur. C'est contre-intuitif. Vous voulez déléguer le travail que vous n'aimez pas et garder ce qui est intéressant. Faites l'inverse. Déléguez le travail technique intéressant à votre équipe. Gardez le travail organisationnel, stratégique et humain pour vous. C'est là que vous apportez le plus de valeur maintenant.

Commencez à 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.

Commencez les one-on-one. Des conversations régulières et planifiées avec chaque personne de votre é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.

Commencez à dire "je ne sais pas." En tant que développeur, admettre que vous ne savez pas quelque chose donne l'impression d'incompétence. En tant que CTO, c'est essentiel. Vous ne pouvez pas être expert dans tout ce que fait votre é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 vous avez 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 votre 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. Votre 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", votre job est d'expliquer ce qui est réaliste sans être dédaigneux. Quand le CEO demande pourquoi quelque chose prend si longtemps, vous devez traduire la complexité technique en termes qu'il peut comprendre et sur lesquels il peut agir.

La transition prend plus de temps que vous ne croyez

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

Pendant ce temps, vous vous sentirez imposteur. Le code vous manquera. Vous vous demanderez si vous avez fait le bon choix. Vous aurez des jours où vous voudrez jeter les livres de management et simplement ouvrir votre 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 vous motive.

Si vous êtes 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 vos propres mains, alors restez contributeur individuel. Il n'y a rien de mal à ça. Les ingénieurs senior et staff ont un impact énorme.

Si vous êtes 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. Vous ne construisez plus la chose. Vous construisez 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.