Manuel du CTO de startup

Manuel du CTO de startup

Compétences essentielles et bonnes pratiques pour une équipe d’ingénierie haute performance

Introduction

• Toujours apprendre : l’auteur nourrit depuis l’enfance une passion pour les ordinateurs et la programmation logicielle, ce qui lui a fait comprendre l’importance de l’apprentissage continu. Pour réussir en tant que leader technique, il est essentiel d’apprendre et de progresser sans cesse.
• Le dilemme du leader technique en startup : la plupart des startups ont un cofondateur technique, qui écrit la base de code initiale et recrute les premiers ingénieurs. Mais à mesure que l’équipe grandit, le leader technique doit évoluer vers un rôle de management, alors même qu’il peut lui manquer des compétences en leadership.

Présentation de l’auteur

• L’auteur a acquis de l’expérience dans plusieurs startups et y a exercé des fonctions de leader technique. Grâce à ces expériences variées, il en est venu à comprendre les nombreuses compétences et les défis nécessaires au leadership technique.

Comment utiliser ce livre

• Ce livre est une référence destinée aux leaders qui gèrent des équipes d’ingénierie logicielle, et traite de différents sujets sous forme de chapitres indépendants. Chaque chapitre présente le sujet, en donne une vue d’ensemble et propose des bonnes pratiques.

Processus métier

• Le livre décrit les processus métier afin de fournir un point de départ pour résoudre les problèmes. Il est nécessaire d’adapter et de faire évoluer ces processus en fonction de la taille de l’équipe et de l’entreprise.

Personnes et culture

Principes fondamentaux du management

• La règle d’or du management : la performance de l’équipe est le critère qui mesure celle du manager. Il faut aider les membres de l’équipe à donner le meilleur d’eux-mêmes.
• Arbre des compétences professionnelles : pour exercer un leadership technique, il faut investir non seulement dans la technique, mais aussi dans les compétences managériales.

Amélioration continue

• Kaizen : l’équipe comme les individus doivent viser l’amélioration continue. Il faut faire des erreurs des occasions de progresser.

Coaching

• Le manager doit jouer le rôle de coach pour aider les membres de l’équipe à donner le meilleur d’eux-mêmes.

Trouver un mentor en management

• Il est important de trouver un mentor en management pour réussir sa transition vers le leadership. Un mentor adapté permet d’améliorer ses compétences de leadership.

Entretiens en tête-à-tête

• Les entretiens en tête-à-tête sont l’occasion de construire une relation avec les membres de l’équipe, de comprendre leurs points forts et leurs points faibles, et de les aider à donner le meilleur d’eux-mêmes.

Réunions skip-level

• Organiser régulièrement des réunions avec les collaborateurs de ses managers permet de recueillir des points de vue variés et, grâce à cela, d’améliorer l’entreprise.

Coaching des managers

• La performance des managers intermédiaires est essentielle à celle de l’organisation. Il faut les développer grâce à une formation continue et à un accompagnement adapté.

Entretiens en tête-à-tête avec les ingénieurs

• Les entretiens en tête-à-tête avec les ingénieurs sont l’occasion d’écouter les problèmes auxquels ils font face et de les aider à trouver des solutions. Il faut clarifier l’objectif de la réunion et conduire une conversation productive.

[GN⁺]

Avis sur Hacker News

• Quand je lis ce genre de document, j’ai tendance à aller d’abord sur les sujets que je connais en profondeur pour voir ce qui en est dit. Ici, il est indiqué qu’il faut généralement 6 à 12 mois pour préparer et mener des audits PCI DSS ou SOC 2, et qu’il ne faut donc pas essayer d’obtenir la certification au dernier moment, mais pour une startup, j’aurais presque envie de donner le conseil inverse
  En particulier, obtenir une attestation SOC 2 est facile, et dépenser de l’argent de manière proactive avant même qu’un bon de commande soit en jeu est du gaspillage. Bien sûr, il vaut mieux mettre en place tôt ce qui servira plus tard de base à l’attestation, comme la configuration du single sign-on ou des branches Git protégées, mais cela relève surtout des bonnes pratiques de base qu’il faut de toute façon appliquer, même sans prévoir d’obtenir SOC 2. À mon avis, inutile de faire SOC 2 si un gros client ne l’exige pas. Ce serait bien que quelqu’un vérifie aussi les autres parties de ce document

  • Bonne approche. J’ai cherché du côté des bases de données et, dans l’ensemble, c’était correct. En revanche, en 2025, je ne pense pas qu’une startup ait besoin de se focaliser sur SQL contre NoSQL. Les bases de données SQL populaires prennent bien en charge JSON, donc il suffit d’utiliser PostgreSQL ou MySQL, que les ingénieurs connaissent mieux, ainsi que CloudSQL ou RDS pour gérer les sauvegardes et la réplication
    Avec une réplique de lecture pour la BI et un bon outil de visualisation, on peut tenir assez longtemps, largement avant de devoir dépenser des montants à 5 ou 6 chiffres dans quelque chose comme Snowflake
  • D’après mon expérience, les entreprises prêtes à travailler avec des startups en phase initiale et qui demandent un rapport SOC 2 n’ont généralement pas de problème à avancer en inscrivant au contrat une obtention de SOC 2 Type 1 sous 6 mois, à condition que le responsable technique puisse parler avec leur équipe IT et les convaincre que les capacités sont correctes
  • Je me permets de ne pas être d’accord, mais uniquement dans le cas où les processus comptables et de supply chain se trouvent dans un ERP d’entreprise. Revenir plus tard sur des processus non auditables coûte trop de temps et d’argent, tandis que l’activité doit continuer à tourner. Dans ce cas précis, je pense qu’il est moins cher et préférable de les rendre auditables dès le premier jour
  • L’applicabilité de ce conseil peut beaucoup varier selon le secteur. Si vous vendez un produit B2B qui traite des informations permettant d’identifier une personne, SOC 2 est pratiquement indispensable si vous ne voulez pas être tourné en ridicule lors des rendez-vous de pitch
    Selon votre situation financière, utiliser un service automatisé de check-list de conformité SOC 2 comme Secureframe peut coûter quelques milliers de dollars. Cela vous aide non seulement à suivre les bonnes pratiques, mais aussi à les organiser de la manière spécifique attendue par SOC 2, ce qui facilite l’audit. Comparé au temps de développement et de gestion de projet nécessaire pour remettre une organisation déjà profondément ancrée dans des processus non conformes sur la voie de SOC 2, ce n’est pas un gros investissement
  • Je ne connais pas bien la conformité, mais cela me paraît assez étrange. En lisant rapidement SOC 2, on voit qu’il faut une énorme collecte de preuves pendant les mois qui précèdent l’audit. Si l’on n’a pas investi de temps en amont, je ne vois pas comment savoir plus tard ce qu’il faudra avoir en place
    L’idée qu’une attestation SOC 2 soit facile à obtenir est aussi exactement l’inverse de ce que j’ai entendu d’autres personnes sur le sujet. On m’a plutôt dit que c’était généralement très difficile et très chronophage, donc je me demande ce qui m’échappe. Si c’est vraiment facile, j’aimerais avoir tort

• Je vois souvent dire que lorsqu’on devient VP ou CTO, on arrête de coder. Je sais que les compétences de management ne sont pas des compétences de codage, mais j’ai du mal à comprendre pourquoi les gens posent le clavier et gaspillent leur première superpuissance
  On peut rester un CTO technique du début à la fin. Il faut traiter l’équipe et l’entreprise comme un service qui nécessite des contributions actives, de la maintenance et du support d’astreinte, tout en continuant à mettre les mains dans le cambouis, seul comme avec l’équipe

  • Au niveau VP/CTO, on n’a pas le temps de contribuer au code ni de le maintenir. Si on a ce temps, le titre est probablement surtout symbolique. Par exemple, le « CTO » d’une équipe de startup de 3 personnes
    Le vrai problème, c’est d’accepter tôt dans sa carrière un rôle où l’on n’a pas le temps de coder. Par exemple un rôle d’architecte qui consiste seulement à dessiner des boîtes sur un tableau blanc et à enchaîner les réunions, ou un rôle qui est en réalité managérial mais qu’on appelle « tech lead ». On s’habitue à ne plus écrire de code, puis quelques années plus tard, quand il faut chercher un nouvel emploi, on passe des entretiens pour des postes de dev en étant confronté au fait qu’on a passé une part importante de sa carrière de programmeur sans écrire de code. Pour beaucoup de gens, les réflexes ne reviennent pas vite
  • Dans mon expérience, le problème était simplement qu’il n’y a qu’un certain nombre d’heures dans une journée. Pendant 7 ans, j’ai été responsable directement ou indirectement d’environ 20 à 25 personnes, et il me manquait vraiment du temps pour faire quelque chose d’utile dans le code
    Mon temps était bien mieux employé à résoudre les problèmes que les autres ne pouvaient pas résoudre. Il m’arrivait de prendre en charge un changement très simple pour parcourir moi-même nos processus et voir où les améliorer. Je continuais à coder le soir ou le week-end, mais ce n’est pas la même chose, et avec le temps on rouille forcément un peu. Cela dit, pendant une période sabbatique, c’était vraiment agréable de passer mes journées à coder les mains dans le cambouis
  • Dès qu’on n’est plus simple contributeur individuel, d’autres priorités apparaissent. Le travail de contributeur individuel peut donc être interrompu à tout moment. On ne peut alors pas prendre en charge des tâches proches du chemin critique, car sinon on bloque les autres ou on doit leur passer le relais
    Les revues ou les réunions de conception restent possibles, mais si l’on prend en charge le travail cœur, cela finit par poser problème
  • Je ne pense pas qu’il existe une seule bonne réponse, mais à partir d’un certain point, recruter le prochain ingénieur clé, construire une feuille de route technique pour garder une longueur d’avance sur la concurrence, ou aligner l’organisation engineering avec le reste de l’entreprise a beaucoup plus d’effet de levier que les contributions de code d’un VP/CTO
    Le code qu’un VP/CTO peut écrire, quelqu’un d’autre dans l’équipe peut l’écrire aussi, et peut-être même mieux. En revanche, les autres tâches que j’ai listées sont probablement celles que le VP/CTO est le mieux placé pour accomplir dans l’entreprise. Il est donc assez rationnel de laisser de côté la plupart du travail technique pratique pour se concentrer sur ce qui compte davantage pour l’équipe et l’entreprise
  • Mon dernier rôle de CTO concernait une équipe de 40 personnes, et j’ai été complètement surchargé dès le premier jour. Pourtant, je gère plutôt bien mon temps. Si possible, j’aurais voulu passer 50 % de mon temps à programmer, mais je n’avais pas ce temps, ni la structure de support à laquelle déléguer, donc j’ai dû la construire moi-même dans la douleur. Et c’était justement une autre raison pour laquelle je n’avais pas de temps
    L’idée de continuer à coder est séduisante, mais ce n’est généralement pas pour cela qu’on est payé. Je me considère comme un très bon développeur, mais on peut trouver ce type de développeur pour moins cher qu’un salaire de CTO. Il est inefficace qu’un CTO plus coûteux fasse ce travail. Pour info, je suis redevenu contributeur individuel quelques années plus tard, et je compte poursuivre ainsi le reste de ma carrière

• J’ai envie de dire qu’un chat synchrone, ça n’existe pas
  Si quelque chose doit être synchrone, il ne faut pas le faire dans une fenêtre de chat. Du moins, sauf si l’on s’est mis d’accord pour « se concentrer quelques minutes sur une discussion en temps réel ». À distance, il faut appeler ; sur site, il faut parler en face à face. Il ne faut pas balancer un message dans un chat et s’attendre à une réponse immédiate

• Je me demande s’il existe des cas où le système à « deux équipes » n’a pas suscité de ressentiment. Je ne sais pas non plus s’il y a eu des situations où les gens ne voulaient pas naturellement rejoindre l’équipe du futur.
  Sur le papier, ça ressemble à une bonne idée, mais j’ai du mal à croire que ça fonctionne bien en pratique. La forme la plus proche que j’aie vue, c’était plutôt une équipe bibliothèque qui créait des services comme un design system et des composants pour que les autres équipes les utilisent.

  • Dans un précédent poste, il existait une version d’un produit on-premise pour laquelle l’entreprise avait vendu un support prolongé sur une très longue durée, alors que cette version devait être en fin de vie. Une petite équipe, probablement trois personnes environ, était uniquement responsable de s’assurer que cette version reste supportée, que les pipelines fonctionnent et que de grosses corrections puissent être déployées si nécessaire.
    Tant qu’elle remplissait cette responsabilité, elle était libre, sur le temps restant, de travailler sur ce qu’elle jugeait utile pour l’entreprise. C’était un assez bon compromis. Les autres étaient reconnaissants à cette petite équipe de prendre en charge le sale boulot, et l’équipe de maintenance appréciait de pouvoir, sur son temps restant, corriger des irritants de longue date ou faire de la recherche. J’ai oublié les détails, mais je me souviens qu’il en était sorti des améliorations et des travaux de recherche assez impressionnants. Le fait que les membres de l’équipe soient très compétents et autonomes a aussi contribué au succès, mais cela coûtait aussi plus cher.
  • Le livre semble proposer une rotation régulière comme solution à ce problème. L’article de blog de Microsoft recommande de faire passer chaque semaine une partie des membres d’une équipe à l’autre, et de définir l’équipe client comme une équipe temporaire.
    J’ai effectivement connu plusieurs endroits où des équipes totalement séparées fonctionnaient bien. Dans le jeu vidéo, il suffit de penser à l’équipe moteur et à l’équipe jeu. Dans l’un de mes anciens rôles, même au sein de l’équipe jeu, on prenait en charge une fonctionnalité qui demandait 6 à 12 semaines, on la lançait, puis on s’occupait de la maintenance, des mises à jour et de la dette technique. Ce qu’on venait de livrer restait le principal sujet d’attention, mais on avait aussi du temps pour revenir sur des travaux précédents, tandis qu’une autre équipe suivait le même cycle avant d’onboarder une nouvelle fonctionnalité 6 à 8 semaines plus tard, et ainsi de suite.
  • J’ai déjà expérimenté un système à deux équipes. La Red Team s’occupait du développement de fonctionnalités, tandis que la Blue Team gérait la stabilité et les corrections de bugs.
    Nous ne les traitions pas comme des équipes fixes, mais comme un flux de travail dans lequel les gens passaient de l’une à l’autre à chaque sprint, donc toutes les deux semaines. Cela a bien fonctionné pendant environ trois mois, puis ce n’était plus adapté ; à ce moment-là, l’organisation avait grossi et nous avons réorganisé les équipes autour de capacités métier ou de domaines.
  • Dans le même esprit, j’ai déjà mis en place un roulement où les ingénieurs prenaient en charge le support et les rapports de bugs pendant une semaine chacun. Cela permettait d’éviter pas mal des pièges des « deux équipes » complètement séparées. J’en ai écrit un peu plus ici : https://news.ycombinator.com/item?id=43337703#43339972.
  • Si l’« équipe client » dispose de ressources suffisantes et d’une rémunération appropriée, je ne pense pas qu’il soit forcément tentant de passer dans l’« équipe du futur ». Mais même sans séparation, la maintenance est généralement affamée tandis que les nouvelles fonctionnalités captent toute l’attention et toutes les ressources. En divisant en deux équipes, cela risque fort d’empirer.

• Ce qui est bien avec ce genre de document, ce n’est pas qu’on soit censé l’utiliser comme une Bible, mais qu’il donne une vue d’ensemble des responsabilités et des sujets d’attention.
  À moins d’avoir un excellent mentor ou d’avoir travaillé sous quelqu’un de vraiment exceptionnel, quand on arrive à ce poste, personne ne vient s’asseoir à côté de vous pour vous donner la liste des choses dont il faut s’occuper. Chaque section pousse à se demander : « quelle est notre réponse ? », « sommes-nous d’accord ? », « notre processus est-il meilleur ? », « qu’est-ce que je rate ? », et c’est utile.

• C’est donc explicitement recommandé, cette séparation en « deux équipes ». C’est une méthode fantastique pour continuer à livrer jusqu’à ce que le coût de sortie de quelque chose de correct devienne prohibitif.
  Si vous coupez la boucle de feedback qui revient vers les personnes qui ont écrit le logiciel au départ, elles seront un peu plus heureuses pendant un moment, et les autres un peu plus malheureux pendant un moment. Puis l’équipe fonctionnalités ne voudra plus jamais être interrompue, et l’équipe client n’obtiendra jamais les ressources nécessaires pour corriger correctement quoi que ce soit.
  Pire encore, l’équipe fonctionnalités n’apprend rien d’autre qu’à expédier des lignes. Si les choses deviennent de plus en plus lentes et coûteuses avec le temps, c’est parce qu’on a supprimé la seule fonction d’adaptation du bon développement logiciel : la réintégration du feedback négatif dans la source du développement. Un vrai manuel de leadership pour CTO devrait dire clairement : « il est de votre responsabilité d’aider les développeurs à s’améliorer pendant qu’ils livrent, et ils n’aimeront pas toujours ça ».

  • Dire que cela « permet à l’équipe fonctionnalités de se concentrer à 100 % sur l’avenir sans être interrompue par le support client » revient plutôt à dire qu’on la laisse continuer, sans la moindre conscience du désastre qu’elle a déclenché, jusqu’à ce que le navire soit entièrement encastré dans l’iceberg.
    Il y aura aussi des conflits de merge entre l’équipe fonctionnalités poussée par les ventes et l’équipe maintenance poussée par les interlocuteurs client. Dès lors que l’« équipe client » est décrite comme une étape dont on sort plus tard, il est évident de quel côté penchera la lutte de priorités. L’expression « une autre voie permettant aux ingénieurs individuels, en particulier les juniors, d’apprendre et de progresser » finit par sonner comme « les seniors ne veulent pas nettoyer la merde, alors on la fait nettoyer par les juniors ».
  • Dans le même ordre d’idées, parmi les entreprises où j’ai travaillé, celles qui avaient une équipe plateforme étaient généralement contaminées par le sur-engineering. Ici, par équipe plateforme, j’entends une sorte de troisième équipe de support chargée des outils, des pratiques et du code commun.
    Ce genre d’équipe a tendance à attirer des gens qui méprisent le fait de livrer des fonctionnalités et de corriger des bugs, et qui cherchent à abstraire excessivement les problèmes. Au lieu de corriger les bugs, ils disent vouloir empêcher qu’ils apparaissent dès le départ en créant des abstractions de plus en plus complexes, et le résultat est prévisible.
  • C’est le travail du PM. Il faut une ou plusieurs personnes qui travaillent avec les clients et définissent, à partir du feedback, une vision de la manière dont toutes les fonctionnalités doivent s’articuler.
    Les clients, surtout non techniques, n’ont pas une vision produit cohérente, et veulent souvent seulement une correction immédiate, indépendamment des autres plans. Comme les clients ne communiquent pas entre eux, leurs retours peuvent aussi se contredire. Si l’on fait porter cette charge aux développeurs, ils doivent gérer toute la communication en plus de leurs compétences techniques — connaître la base de code et bien la maintenir —, et tous les développeurs doivent partager la même vision cohérente pour pouvoir prendre des décisions réfléchies. À une époque où les développeurs gèrent aussi l’infrastructure, cela revient en réalité à faire faire deux ou trois métiers par une seule personne.
  • Pour compenser cela, nous changions les équipes à chaque sprint, ou tous les quelques sprints. Les gens acquéraient ainsi une expérience plus variée, et s’ils créaient une fonctionnalité pleine de bugs, ils finissaient par devoir la corriger eux-mêmes, ce qui maintenait aussi le feedback.
    Les gens semblaient préférer nettement cette approche. Ils ne s’épuisaient pas à ne corriger que des bugs en permanence, et on évitait aussi la rupture de feedback que vous avez justement pointée.
  • Les développeurs doivent exploiter et maintenir les logiciels qu’ils créent. Le principe est aussi simple que ça.

• À ce stade, j’ai fait tellement d’entretiens que je ne pourrais plus les compter, donc j’ai un peu de mal à être d’accord. L’une des difficultés, c’est qu’à l’étape de réception des candidatures, les postulants peuvent être très nombreux, et qu’à ce stade c’est généralement l’équipe de recrutement qui interagit avec eux
  Inclure les questions de l’exemple me semble acceptable, mais pour filtrer les candidats non qualifiés, il faut des questions qui ne soient ni oui/non ni à échelle. Je préfère des questions très simples avec une réponse claire. Il y a un nombre étonnant de personnes qui disent être « très à l’aise » avec JavaScript mais ne savent pas ce qu’est ===. Je pose donc des questions comme « Quel est l’opérateur d’égalité stricte en JavaScript ? ». N’importe quel programmeur JavaScript le sait, mais une seule question de ce type permet déjà d’écarter 50 % du vivier de candidats et de faire gagner énormément de temps à l’organisation

• On parle beaucoup d’adéquation culturelle, mais une bonne partie de ce discours semble faire remonter à la surface une couche de discrimination cachée qui nuit à l’entreprise. Je pense que l’ouverture culturelle est un facteur de réussite, tandis que la discrimination mène dans la direction opposée
  Quand je lis la phrase « les meilleurs leaders suivent les taux de réussite, n’ont pas peur de reconnaître leurs erreurs de recrutement, recrutent lentement et licencient rapidement », j’ai envie de poster l’image que JWZ (Jamie Zawinski) affiche lorsqu’il détecte un en-tête referrer pointant vers ce site. Il suffit de chercher sur Google ce que Jamie Zawinski a dit à propos de Y Combinator. C’est aussi quelqu’un à qui l’on doit la décision de Netscape de publier Netscape Navigator en open source, ainsi qu’une grande partie du travail qui a mené au moteur de rendu de ce navigateur. C’est grâce à cela que Firefox existe

  • Voir l’« adéquation culturelle » comme de la discrimination cachée est une lecture cynique et, dans les cas que j’ai vus, elle servait plus souvent à éviter qu’un candidat se retrouve avec un travail qu’il détesterait
    Dans l’un de mes premiers emplois, on a essayé d’interdire de nos critères de recrutement tout ce qui pouvait être qualifié d’adéquation culturelle. Résultat : plusieurs personnes ont rejoint l’entreprise, l’ont immédiatement détestée et sont parties au bout de quelques semaines ou quelques mois. Un candidat mettait l’accent sur la planification et la prévisibilité, et se plaignait que ses anciennes entreprises allaient trop vite. Nous étions une startup et, comme prévu, il a détesté l’entreprise. Mais nous ne pouvions pas exprimer cette inquiétude dans le processus de décision de recrutement, parce que c’était de l’« adéquation culturelle » et que cela pouvait mener à de la discrimination. Après quelques incidents similaires, cette politique a discrètement disparu, et nous avons de nouveau pu évaluer la compatibilité avec la culture d’ingénierie
  • Tout processus d’embauche discrimine. L’important est de savoir quelles caractéristiques il favorise ou défavorise, et ce qu’il exclut
    L’« adéquation culturelle » est généralement un compromis : on gagne en efficacité de communication et en confiance élevée, au prix d’une partie de la diversité de pensée. Comme les gens savent déjà comment se comporter et quoi attendre les uns des autres, il n’est pas nécessaire d’établir beaucoup de directives, mais on devient plus vulnérable à la pensée de groupe et aux biais cognitifs associés. C’est un peu : « Il y a toutes les couleurs de l’arc-en-ciel sur ce navire, mais même nos Klingons pensent que les Klingons sont mauvais »
  • J’ai accepté cette digression et j’ai cherché, mais tous les résultats de la première page n’étaient que des commentaires de Hacker News mentionnant Jamie Zawinski, alors j’ai abandonné. J’aimerais donc qu’on m’explique de quoi il s’agit

• Je ne suis pas sûr que le conseil de « créer une bibliothèque de vidéos explicatives » soit bon. Pour des choses spécifiques comme l’UI ou l’animation, cela peut avoir du sens
  Mais en général, lire du texte est plus efficace que regarder une vidéo. Quand on est pressé, il est aussi beaucoup plus facile d’aller directement aux passages importants dans un texte que dans une vidéo

  • Certaines personnes préfèrent la vidéo, d’autres le texte. Les deux sont des investissements qui demandent des efforts et produisent des effets. Désormais, grâce à l’IA générative, il est plus facile de créer les deux