Pourquoi j’écris encore du code en tant que CTO
(assembled.com)- 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
5 commentaires
Je suis CTO en poste et je ne suis pas du tout d’accord avec cet article.
Je suis 100 % d’accord sur le fait qu’il ne faut pas arrêter de coder, mais il suffit pour cela de contribuer à de l’open source sans lien avec le produit de l’entreprise. À mon avis, c’est un propos valable uniquement si l’on se place du point de vue d’un fondateur technique de startup en phase de démarrage, qui doit être polyvalent.
Tant mieux pour lui… mais l’entreprise, elle, y gagne quoi ?
Il faut faire un travail à la hauteur du salaire qu’on reçoit…
Je trouve étrange qu’un CTO prenne directement en charge un projet expérimental. Si on laissait suffisamment de temps aux équipes opérationnelles, elles pourraient très bien le mener à bien. Ce qui m’étonne le plus, c’est l’idée qu’un projet expérimental de long terme doive être mené uniquement par le CTO. S’il a l’autorité pour allouer des ressources, il lui suffirait de mobiliser des ressources dédiées à ce type de projet et de donner suffisamment de temps aux équipes opérationnelles.
Un parcours personnel… Il faut bien gérer les choses pour éviter que les aspects de gestion organisationnelle ne prennent trop d’ampleur, n’est-ce pas…
Discussion Hacker News
Si j’envisageais de postuler dans une entreprise et que je tombais sur un billet de blog où le CTO se vante de commit du code tous les week-ends, je me préparerais à prendre la fuite
Le rôle d’un dirigeant est de construire une culture d’entreprise saine, et se vanter de travailler le week-end va exactement à l’inverse
En plus, dire publiquement qu’on a résolu un problème client en une journée en sautant les validations juridiques ou les revues d’ingénierie, c’est un signal d’alerte
Dans une startup en phase initiale, la culture est totalement différente, et ce type de billet sert plutôt de filtre pour écarter les profils inadaptés
Le code que j’écris concerne surtout des améliorations internes de la DevEx ou le traitement de dette technique
Je ne saute jamais les validations juridiques, et j’en reste à un niveau de PoC plutôt qu’à du code de production
Pour un CTO fondateur, il est important de rester proche du code, mais l’essentiel est de ne pas perdre l’équilibre
Le rôle de CTO varie selon les entreprises
Comme dans le cas de Stripe avec Greg Brockman, certains CTO sont surtout des visionnaires techniques, d’autres des architectes de l’organisation, et d’autres encore sont centrés sur l’infrastructure
Dans mon cas, j’aime coder et je suis profondément impliqué auprès des clients comme de la codebase, donc c’est ainsi que je crée le plus de valeur
Le titre de « CTO » est mal défini
Certains CTO sont des fondateurs qui codent librement, tandis que d’autres travaillent avant tout côté client et finissent par perdre l’accès au code
À l’inverse, il existe aussi des CTO autoritaires
Au final, il faut clarifier de quel type de CTO on parle pour que la question « pourquoi code-t-il ? » ait un sens
Dans ce cas, le nom « CTO » n’est qu’une simple répartition des rôles
Le CTO se concentre sur la stratégie et la direction, le VP sur la gestion quotidienne de l’ingénierie
Que cela passe par la construction d’une organisation ou par du code écrit directement importe peu
Quand un manager écrit lui-même du code, les code reviews peuvent être biaisées et l’équipe peut se retrouver désorientée
Au fond, cette personne n’est peut-être pas vraiment un CTO : dans sa tête, elle est toujours développeur
Je ne suis pas totalement opposé au fait qu’un CTO code, mais dans ce cas précis, on a l’impression qu’il n’assume pas suffisamment le rôle de CTO
Le vrai leadership technique semble porté par l’ingénieur fondateur, avec une rémunération bien inférieure, et c’est là le problème
Un CTO qui n’a pas de chaîne de reporting et se contente de coder ressemble davantage à un développeur senior qu’à un stratège
On m’a déjà proposé ce genre de poste, mais au final ce n’était qu’un titre de façade
Quand l’organisation grandira, le rôle changera probablement
Dans une petite startup, mon travail consiste à avancer avec l’équipe dans les sprints, à résoudre la cause des retards, et à prendre soin des personnes en burn-out
Mais à lire le billet, si l’équipe est dans une situation où elle n’a même pas la bande passante pour tenter un projet IA prometteur, alors c’est un problème d’organisation
Le CTO ne devrait pas coder lui-même, mais résoudre ce type de goulot d’étranglement systémique
D’une entreprise à l’autre, les rôles de « senior » ou de « head » n’ont absolument rien à voir
Les problèmes qui apparaissent quand un CTO s’implique trop dans le code sont clairs
biais dans les reviews de PR, négligence du rôle principal, confusion des responsabilités, atteinte à l’autonomie de l’équipe, etc.
L’idée selon laquelle « un CTO ne devrait pas coder et ne faire que de la stratégie » est une vision mécanique
La nature d’une entreprise tech, c’est la livraison de valeur, et parfois le travail le plus utile consiste justement pour le CTO à implémenter lui-même une grosse fonctionnalité en une journée
Cela peut être une journée bien plus productive qu’une réunion KPI
Parfois, il est nécessaire qu’un C-level retrouve directement le sens du terrain
Pour certains, s’ils sont devenus CTO, c’est simplement parce qu’ils sont cofondateurs
Avec cette approche, dans une autre entreprise, ils pourraient ne même pas atteindre le niveau d’un staff engineer
Enfin, le fait que la page des tarifs du site de l’entreprise n’affiche pas de vrais prix peut prêter à confusion, donc cela mérite d’être corrigé