Pourquoi j’écris encore du code en tant que CTO

• De nombreux CTO basculent vers un rôle davantage centré sur le management, mais certains continuent à écrire eux-mêmes du code et à développer le produit
• Trois types de travail de développement — projets expérimentaux, demandes urgentes de clients et correction de bugs — permettent de créer un fort effet de levier dans l’organisation
• Continuer à coder permet de mesurer directement l’utilité réelle et les limites des outils d’IA, et de garder des décisions techniques ancrées dans la réalité
• Plutôt que le management, l’auteur met ses points forts et sa motivation dans la résolution de problèmes et la construction de produit, et conçoit une organisation qui le rend possible
• Il n’existe pas de modèle unique pour le rôle de CTO : l’essentiel est de trouver une forme de leadership adaptée à ses forces et à la situation de l’entreprise

---

Pourquoi je continue à coder en tant que CTO

• Beaucoup de CTO arrêtent de coder avec le temps, mais l’auteur continue à développer et déployer lui-même des fonctionnalités
  • Au cours des 12 derniers mois, il a lancé plusieurs fonctionnalités majeures sans avoir de collaborateurs en direct report
  • Il ne s’agit pas d’un simple hobby, mais d’un véritable rôle de développeur de fonctionnalités clés intégrées au produit réel
• Il considère cela comme « l’une des activités au plus fort levier pour un leader technique »

Les trois types de projets qu’il construit réellement

1. Projets expérimentaux de long terme (Long-horizon experimental projects)

• Dans une organisation, très peu de personnes sont réellement en mesure de construire un nouveau produit
  • La plupart des organisations sont surtout focalisées sur la maintenance et l’extension des produits existants
  • Seuls les fondateurs, certains dirigeants et quelques contributeurs individuels très performants (IC) ont la marge nécessaire pour tenter de nouveaux produits
  • À cause de la structure de l’organisation, des incitations liées à la roadmap et d’un budget risque limité, la plupart des ingénieurs ne peuvent pas porter pendant plusieurs mois un projet incertain
• Le CTO est dans une position unique pour faire avancer rapidement des projets expérimentaux incertains, grâce à sa compréhension profonde des pain points clients et de l’architecture
• Il y a eu des échecs, mais aussi de grands succès
  • Exemple d’un produit de chat IA : l’équipe reconnaissait sa valeur, mais le projet avait été repoussé faute de temps et de bande passante ; l’auteur en a développé un prototype pendant les vacances de Thanksgiving
  • Il a ensuite collaboré avec l’équipe pour en faire un produit commercialisé générant plusieurs millions de dollars d’ARR

2. Traitement des demandes critiques de clients (Critical customer asks)

• Il arrive qu’une fonctionnalité réclamée en urgence par un client important devienne un blocage pour un gros contrat ou un renouvellement
• Au lieu de mobiliser un ingénieur déjà engagé dans le sprint en cours, le CTO s’en charge lui-même grâce à une prise de décision rapide et une vision d’ensemble du système
• Exemple concret : une demande de fonction de réduction de données pour répondre aux exigences de conformité d’un client à un million de dollars par an
  • L’examen initial de l’équipe laissait penser que le client devrait construire lui-même une intégration API, ou qu’il faudrait plusieurs réunions entre produit, juridique et ingénierie
  • Le CTO a construit et déployé une version fonctionnelle en une journée, ce qui a permis de préserver la relation client

3. Corrections de bugs (Bugfixes)

• Beaucoup de gens sont surpris, mais corriger des bugs est l’une de ses façons préférées de garder une carte mentale du codebase
• Qu’il s’agisse de comprendre pourquoi la pagination casse sur la troisième page des résultats de recherche, ou pourquoi une connexion WebSocket se coupe exactement au bout de 60 secondes, cela l’amène à parcourir l’ensemble du système
  • Cela permet d’acquérir une compréhension intuitive de la dette technique qu’il est difficile d’obtenir via de simples code reviews ou discussions d’architecture
  • Cette expérience lui permet de conserver l’intuition nécessaire pour décider de l’orientation et des priorités des investissements techniques

Pourquoi continuer à coder

1. Pour comprendre ce qui fonctionne réellement

• L’usage quotidien d’outils d’IA comme Claude Code, Codex ou Cursor lui permet de distinguer la réalité du battage médiatique lorsqu’il prend des décisions sur les outils ou les recrutements
• Exemple récent : il a tenté de faire en vibe-coding une fonctionnalité touchant à des intégrations complexes, sans réel progrès ; en la codant lui-même à la main, il a avancé bien plus vite
  • Le volume de code n’était pas énorme, mais la logique devait être précise, ce qui est un domaine où les LLM sont fragiles
  • À l’inverse, une autre grosse fonctionnalité a été presque entièrement développée avec Claude Code
  • Comprendre les domaines où l’IA excelle (CRUD, tests, boilerplate) et ceux où elle échoue (précision, nuances système) vaut mieux que des décisions guidées par le hype sur Twitter
• Quand on est plongé dans le code, on peut sentir quand il faut pousser et quand il faut relâcher
  • On repère le moment où l’architecture devient excessivement complexe ou quand la dette technique commence réellement à poser problème
  • Un manager qui ne s’appuie que sur des reportings peut passer à côté de beaucoup de choses

2. Pour se concentrer sur ce qu’on fait bien et ce qu’on aime

• L’auteur n’aime pas particulièrement construire une organisation ni gérer les personnes
  • Le management engineering implique des dynamiques interpersonnelles, des évaluations de performance et de la conception organisationnelle
  • Ce sont des fonctions importantes, mais pas là où se situent ses points forts
• C’est pourquoi il recrute d’excellents engineering managers et leaders
  • Ils le font mieux, et ils aiment ça davantage
  • Cela permet au CTO de se concentrer sur le développement produit, la résolution de problèmes techniques et le code
• Une startup ressemble à « un marathon couru en sprint », donc il conçoit son rôle autour de travaux qui maintiennent son intérêt et lui permettent de tenir longtemps à un rythme élevé
  • C’est ainsi qu’il parvient à durer pendant des années, et c’est crucial pour l’entreprise

3. Parce que les outils d’IA ont élargi l’effet de levier

• Il y a quelques années, il était difficile de trouver du temps pour coder tout en gérant les sujets stratégiques
  • Avec la croissance de l’entreprise, il passait ses journées en réunion et travaillait souvent hors de sa zone de force
  • Ce fut l’une des périodes les plus difficiles de sa carrière
• Les outils d’IA modernes ont fondamentalement changé l’équation (surtout ces derniers mois)
  • Sa productivité a été multipliée par 2 à 3
  • Ces outils ne remplacent ni le jugement ni la connaissance technique ; au contraire, ils rendent ces compétences encore plus précieuses
• Si l’on demande à un outil d’IA de « construire un export de données qui respecte le format d’export CSV existant tout en ajoutant trois champs supplémentaires depuis la table de profils utilisateurs », il peut générer correctement l’essentiel du code
  • Parce que l’auteur possède un contexte profond sur ce qu’il faut exactement et où le trouver
  • Un ingénieur peu familier avec cette partie du codebase passerait beaucoup de temps à reconstituer les détails
• Le travail est passé de « rédiger chaque ligne de code » à « fournir du contexte, prendre des décisions et évaluer des solutions »
  • Et il se trouve qu’il dispose de beaucoup de contexte

Trouver la manière qui vous correspond

• Pour définir le rôle de CTO, l’auteur s’est appuyé sur le billet de blog de Greg Brockman sur la définition du rôle de CTO chez Stripe
  • Après avoir parlé avec plusieurs CTO, il a constaté qu’il existait d’énormes variations dans la forme que peut prendre ce rôle
  • Certains CTO sont des visionnaires techniques, d’autres des bâtisseurs d’organisation, d’autres encore sont centrés sur l’infrastructure
  • Leur point commun est que les meilleurs CTO identifient le domaine où ils peuvent créer le plus de valeur, en tenant compte de leurs compétences particulières, de leurs centres d’intérêt et du contexte de l’entreprise
• Dans son cas, cela signifie écrire beaucoup de code
  • Il aime davantage construire des logiciels que concevoir une organisation
  • Sa connaissance approfondie des clients et du codebase le rend particulièrement efficace
  • Il recrute des engineering managers solides
• Mais il s’agit d’un parcours personnel, pas d’une prescription
• Le rôle de CTO est très flexible
  • Construction d’organisation, stratégie produit, etc. : le leadership technique peut prendre des formes très diverses selon les forces, les sources d’énergie et les besoins de l’entreprise
• Aux ingénieurs qui s’inquiètent de voir le leadership signifier l’abandon du travail technique : il existe de nombreux chemins
  • L’essentiel est d’identifier le domaine où vous êtes singulièrement excellent