- Fournit le contenu le plus récent du Startup CTO's Handbook, avec un texte consultable en Markdown
- Le livre est disponible à l’achat sur Amazon et Audible
- Le lien vers la dernière version Markdown rendue en PDF est en statut Coming Soon, et le manuscrit original existe actuellement dans une ancienne version sous forme de Google doc
- Les contributions sous forme d’issues et de pull requests sont encouragées afin d’intégrer ajouts, modifications, suggestions et critiques dans les futures éditions
- La licence autorise la copie, la modification et la redistribution, à condition de ne pas revendre l’ouvrage, de conserver le nom de l’auteur et l’attribution, et de publier les versions ultérieures sous une licence similaire ou identique
1 commentaires
Avis sur Hacker News
Il y a clairement des points avec lesquels je suis d’accord. Par exemple, je suis pour l’enregistrement de toutes les réunions. Mais il y a aussi beaucoup d’éléments avec lesquels je ne suis personnellement pas d’accord, comme la gestion de la performance[0]
Ce n’est pas forcément une critique : je veux surtout dire que l’approche et le style de leadership peuvent varier selon le domaine du problème. J’espère qu’on ne prendra pas ce guide comme quelque chose de sacro-saint. Si son contenu ne correspond pas à votre propre expérience, je vous conseille plutôt de faire confiance à votre expérience
[0] https://twitter.com/bcantrill/status/1216491216356823040
En tant que CTO, je ne vois pas comment formuler cette demande sans qu’elle soit coercitive
Cela dit, dans la pratique, il existe souvent de vrais écarts de compétences techniques, et je pense qu’un manager, lorsqu’il joue un rôle de coach, peut accélérer la progression et la performance de quelqu’un
Là-bas, il est question de gestion prospective de la performance, c’est-à-dire comment améliorer la performance à l’avenir. Mais dans la plupart des entreprises, l’évaluation de la performance ressemble plutôt à une évaluation rétrospective, qui classe les performances passées dans le cadre de l’allocation des rémunérations et des promotions
Les processus prospectifs sont excellents, mais au final il faut tout de même une certaine évaluation des performances passées
J’ai eu l’occasion de travailler avec l’auteur dans deux entreprises, et il est difficile d’exprimer à quel point ce qui est écrit ici peut faire la différence lorsqu’il est réellement mis en œuvre
L’impact ne se limite pas au produit ou à l’ingénierie, il se diffuse dans toute l’organisation. Comme pour tout système ou toute recommandation, il faudra bien sûr l’adapter à votre propre organisation, mais je recommande d’exploiter autant que possible la manière dont Zach enseigne
J’aime plutôt l’enregistrement des réunions. Pas pour s’en servir comme preuve quand une équipe commence à se renvoyer la responsabilité, mais parce que c’est vraiment utile de pouvoir revoir les réunions et les discussions
Si je dois mobiliser une bonne partie de mes capacités dans une discussion importante ou une réunion d’alignement, il est difficile de rester concentré sur le sujet tout en prenant des notes et en se souvenant de tout. Savoir qu’il y a un enregistrement me permet, pendant la réunion, de me consacrer pleinement à l’attention, aux bonnes questions et à la vérification des hypothèses
Le lendemain, je peux réécouter l’appel, mettre en pause, écouter en vitesse 2x ou 3x, prendre des notes personnelles, rédiger un compte rendu ou un résumé interne, repérer des incohérences de raisonnement, ou lancer un outil de prise de notes IA selon mon emploi du temps
C’est aussi utile si quelqu’un est malade, doit aller chercher sa belle-mère à l’aéroport, a une autre réunion en même temps, ou rejoint l’équipe une semaine après une réunion d’alignement importante. Si la réunion n’est pas importante, il suffit de l’ignorer, et de mettre en place des règles raisonnables de suppression automatique
Je ne pense pas vraiment que les gens passent leur temps à fouiller en douce là où ils ne devraient pas aller, donc je ne vois pas ça comme un gros problème
Les réunions d’équipe ont aussi tendance à orienter la conversation vers les personnes qui sont à l’aise à l’oral. C’est particulièrement désavantageux pour les nouveaux arrivants ou pour les personnes dont la langue principale est différente
Je ne suis pas contre les réunions en soi. Certaines personnes préfèrent largement communiquer à l’oral plutôt qu’à l’écrit, et une bonne équipe doit pouvoir s’adapter aux modes de travail préférés de chacun
Mais si une réunion d’équipe est importante et exige fortement les capacités des participants, alors elle ne devrait pas être une réunion. Il ne faudrait tenir une réunion que lorsque tous les participants estiment que c’est le meilleur média pour une conversation donnée
Une réunion, c’est comme être assis devant un tuyau d’arrosage : on finit par manquer des détails
Nous sommes passés à Google Workspace parce qu’il est facile d’enregistrer et de rechercher dans les réunions. Par exemple, l’enregistrement est intégré à l’événement de calendrier
Si une réunion n’est pas assez importante pour être enregistrée, il y a de fortes chances qu’elle ne valait probablement pas la peine d’être tenue
Personnellement, je mets plus d’heures dans une journée que d’autres, mais ce n’est pas quelque chose qui se produit de façon synchrone. Des réunions importantes peuvent se chevaucher, et si l’on ne lit que le compte rendu, beaucoup de nuances disparaissent. En plus, les gens ne lisent pas bien les comptes rendus
Malgré tout, avoir l’enregistrement d’une réunion permet de relire rapidement et correctement le compte rendu, ce qui est très utile. C’est pourquoi je pousse assez fortement à l’enregistrement des réunions
Plus on comprend vite la cause réelle, plus on peut corriger le problème rapidement. Pour comprendre ce concept et la manière de l’appliquer en entreprise, je recommande vivement Extreme Ownership, de Jocko Willink et Leif Babin, anciens Navy SEALs
La participation asynchrone aux réunions est excellente pour les raisons évoquées plus haut. Elle rend les informations contenues dans les réunions recherchables. Désormais, les réunions peuvent être sous-titrées par traitement automatique du langage naturel, et leur contenu devient trouvable par un LLM
Nous entraînons actuellement notre chatbot interne sur du contenu Confluence, et nous cherchons à l’étendre au contenu des réunions enregistrées
Avec un peu d’autopromotion, je développe https://designpro.ai, un outil qui transforme des entrées issues de plusieurs sources en insights et en tâches. Je l’ai utilisé pour extraire des insights à partir de transcriptions d’appels, et je sais que cela fonctionne réellement
Je suis devenu CTO récemment, et l’une des plus grandes difficultés est la communication avec le CEO. C’est peut-être abordé dans le livre, mais je n’ai lu que l’index.
Ces huit derniers mois, le CEO ne veut pas de réunions d’alignement, ne veut rien planifier, ne veut pas porter de vision, et veut se concentrer uniquement sur la killer feature.
Il n’a même pas envie de créer des maquettes ou des prototypes à tester auprès des utilisateurs, et dit que si on en fait, ils doivent être beaux. Il ne veut pas faire quelque chose qui prenne plus d’une semaine, et a aussi refusé des réunions efficaces.
Ce que je veux dire, c’est que les choses qui ne sont pas dans le livre sont précisément celles qui me manquent. Pour info, nous ne sommes que 3 cofondateurs.
Le CTO était le « responsable technique » du CEO, et il avait reçu le titre de CTO parce qu’il était en quelque sorte le plus doué ou le plus important des responsables techniques.
C’est triste à entendre, mais il faut envisager la possibilité que le CEO vous voie comme un employé de plus avec un beau titre. Avec cet état d’esprit, inclure votre avis dans ses décisions lui semblera être une perte de temps.
Je me souviens encore exactement de la réponse de Marc : « S’il y a un doute, il n’y a pas de doute. »
Je sais que c’est une décision trop importante pour qu’un simple commentaire sur Internet vous convainque, mais je le dis quand même : huit mois se sont déjà écoulés. Vous avez probablement déjà essayé tout ce qui valait la peine d’être tenté pour arranger les choses.
Que reste-t-il que vous n’ayez pas encore essayé ? Logiquement, qu’espérez-vous voir se produire à partir de là ? Vous devez réfléchir au temps de vie que vous comptez encore investir dans cette situation, alors que vous pourriez facilement aller vers quelque chose de productif.
Plus sérieusement, ce à quoi vous vous heurtez est précisément ce qui rend ce travail difficile.
D’abord, vous devriez essayer de programmer des 1:1 avec les autres dirigeants. S’il y a d’autres membres de l’exécutif avec qui vous travaillez, en dehors du CEO, vous pourrez obtenir davantage de contexte sur la situation dans laquelle vous arrivez. Comprendre leurs besoins permet aussi de voir ceux de l’organisation au sens large.
Vous avez été recruté pour faire disparaître les problèmes du CEO, même s’il ne vous le demande pas. Votre capacité à vous intégrer dans l’équipe dirigeante est l’une des meilleures façons de prouver votre valeur, et ce qu’il faut, c’est de la constance, du sérieux, de l’ouverture d’esprit et la volonté de poser des questions sincèrement utiles.
Ensuite, si le CEO et l’équipe dirigeante se réunissent régulièrement, demandez à y participer ; s’il n’y a pas ce type de réunion, essayez de l’organiser vous-même. Idéalement, il vaut mieux d’abord vous aligner avec les dirigeants autres que le CEO. Même si le CEO ne peut pas assister à toutes les réunions, ou à la plupart d’entre elles, il appréciera l’initiative et la confiance se construira.
Puisque vous dites qu’il ne veut déjà pas de ce genre de réunions, il faudra peut-être commencer indirectement, via un autre dirigeant qui a de l’influence sur le CEO.
Troisièmement, si vous êtes CTO, le CEO voudra très probablement des 1:1 avec vous à une certaine régularité, ne serait-ce que pour s’assurer que vous ne partez pas. Il suffit de trouver une cadence qui corresponde à son agenda : hebdomadaire, toutes les deux semaines, mensuelle, etc.
L’objectif de cette réunion est de s’aligner avec le CEO et d’obtenir du feedback sur les domaines où vous vous en sortez bien et ceux à améliorer. Si vous n’arrivez pas à la mettre en place, je vous conseille de considérer que ce n’est pas un environnement dans lequel vous pouvez réussir, et de partir.
Si obtenir cette réunion est difficile, mieux vaut d’abord pousser les deux approches précédentes pour construire la relation, puis réessayer. Si vous n’arrivez à bloquer aucun créneau régulier, quelle qu’en soit la fréquence, avec le CEO et les autres dirigeants, alors vous n’êtes pas réellement CTO et vous devriez envisager de partir.
J’ai déjà écrit sur cette différence ici : https://www.mooreds.com/wordpress/archives/2555
Cela dit, l’absence de planification et l’absence de vision portée m’inquiètent. Les deux sont au cœur du rôle d’un CEO en phase early-stage. Savez-vous pourquoi il se concentre autant sur le court terme ? Est-ce qu’il pousse un MVP pour lever des fonds ou vendre, ou est-ce qu’il n’a tout simplement pas de vision ? J’essaierais de creuser ce point pour en comprendre la raison. Sinon, comme d’autres l’ont dit, partir est aussi une option.
Est-ce que vous en êtes arrivé au stade où, quand vous détaillez les étapes court terme indispensables, le CEO répond : « OK, très bien, voilà ce qu’on va faire » ?
Ou bien est-ce le stade formidable où, quand vous poussez la certification SOC2, le CEO dit « pas encore », tout en déclarant dans les pitchs commerciaux : « Nous avançons vers la certification SOC2 » ?
Ne vous inquiétez pas. Ce n’est pas vous qui êtes schizophrène.
Wikipédia décrit DevOps comme un ensemble de pratiques combinant développement logiciel et opérations IT ; traduire cela par « tout ce qui garantit que le logiciel métier tourne ailleurs que sur la machine d’un développeur » me semble être une interprétation assez étrangement différente de la définition d’origine.
C’est particulièrement vrai pour la partie spécialiste DevOps.
Je vais le réécrire pour mieux transmettre cela.
Je ne connais aucune des entreprises ni aucune des personnes mentionnées ici. Je me demande si les autres les connaissent.
Avant d’y consacrer du temps de lecture, je dois dire que j’ai d’emblée une méfiance instinctive envers les gens qu’on appelle « directeurs techniques ». Est-ce que ça vaut la peine de le lire ?
Le public visé semble plutôt être des personnes devenues cofondateurs techniques de startup, avec le titre de CTO, alors qu’elles ont peu ou pas d’expérience professionnelle.
J’ai été CTO dans trois entreprises au cours des dix dernières années, et peut-être que je vieillis et que je deviens moins patient, mais comme d’autres le disent, cela ressemble davantage à un livre destiné à de jeunes diplômés qui viennent tout juste de devenir CTO en tant que cofondateurs. Je fais du conseil technique auprès de personnes de ce profil.
D’après mon expérience, plus on occupe longtemps ce rôle, plus on recherche des informations concrètes, comme dans des livres tels qu’Accelerate.
Les technologies ennuyeuses sont vraiment importantes. Les startups du secteur privé sont déjà des entités instables ; pourquoi accroître encore le risque avec des technologies non éprouvées ?
Par exemple, entre 2013 et 2016, il y a eu une période où MongoDB est devenu, de façon difficile à expliquer, la base de données par défaut de facto. On aurait dit qu’environ un tiers des startups étaient passées de MySQL ou Postgres à MongoDB. C’était vraiment un chaos total, une catastrophe stupide
Dans ce cas, il est difficile d’imaginer une bonne raison de choisir Mongo. À part gagner un peu de temps les premiers jours du développement parce qu’on n’a pas besoin de créer ni de mettre à jour un schéma, il n’y a pas grand-chose.
Le problème, c’est qu’au moment où les données deviennent complexes et où l’on a besoin de choses comme de la BI, on rembourse cet avantage initial avec des intérêts énormes.
De toute façon, même si les données ne sont pas relationnelles, le JSON de Postgres fonctionne mieux que Mongo
Certaines nouvelles technologies disparaissent, d’autres restent.
Au début de ma carrière, SQL était une nouvelle technologie brillante. J’ai fortement poussé mon entreprise à abandonner les bases de données réseau pour passer à SQL, et le résultat a été excellent.
Même chose pour la programmation orientée objet par rapport au C traditionnel.
Certaines technologies ne finissent jamais par tenir leurs promesses et deviennent un boulet pour les organisations qui les ont adoptées.
Il y a eu une période où il était trop tôt pour adopter les technologies de LLM de manière responsable. Mais bientôt viendra le moment où les conseils d’administration demanderont pourquoi on ne les a pas adoptées. Peut-être pour les cas d’usage externes, et certainement pour les cas d’usage internes.
L’une des tâches difficiles du CTO est de juger le moment où adopter une nouvelle technologie. Il faut savoir quand une technologie ennuyeuse est ce qu’il y a de mieux pour l’entreprise, quand il est acceptable d’introduire une technologie encore précoce, et quand une nouvelle technologie devient un accélérateur si puissant qu’il faut absolument l’adopter
Je trouve intéressant de diviser les CTO en trois types : orienté technologie, orienté personnes et orienté externe.
Une startup à un stade très précoce me propose un rôle de CTO. Il n’y a pas encore de produit, seulement quelques démos de base, et elle prépare une levée pre-seed.
Je me demande ce dont ce rôle aurait le plus besoin. Un CTO technique, ou un CTO people ? Au début, comme il faut développer le produit, j’imagine que ce sera surtout un rôle technique. Mais je me demande à quel moment il faudra évoluer vers un CTO davantage centré sur les personnes. Je serais preneur de toute intuition ou expérience sur le sujet
Tu deviens principalement ce rôle, tu soutiens tant bien que mal le reste, puis quand cela devient trop lourd ou trop important, tu recrutes quelqu’un pour prendre en charge au moins deux des autres domaines.
La deuxième question, plus difficile, est de savoir ce qu’eux — les autres CXO — veulent que tu deviennes. Cela peut bloquer la première. Dans certains cas, on est un CTO sans C : juste un responsable technique à qui l’on dit quoi faire, qui fait tourner des démos de parade, et à qui l’on n’explique pas le « pourquoi » business.
J’ai quelques liens en favoris sur « qu’est-ce qu’un CTO, au juste ? »
http://www.startuplessonslearned.com/2008/09/what-does-start...
https://www.allthingsdistributed.com/2007/07/the_different_c...
Je recommande aussi The Manager’s Path de Camille Fournier
Il est écrit que « rembourser la dette de manière proactive est un investissement nécessaire dans la santé globale de l’ingénierie », mais certaines dettes techniques coûtent globalement moins cher à faire défaut qu’à rembourser.
À condition que le product manager n’essaie pas de les recouvrer
Mais un projet d’une certaine taille et complexité n’atteint la faillite technique que si l’on n’a pas suivi les conseils du livre. Si l’on ignore la dette technique pour livrer des fonctionnalités, les releases deviennent de plus en plus difficiles et les bugs de plus en plus fréquents
Félicitations pour la publication du livre.
J’écris Opinionated Launch (https://opinionatedlaunch.com) pour partager des idées pratiques issues de mon expérience comme CTO d’une petite startup et VPoE d’une société cotée.
En commençant à écrire, je me suis rendu compte que le sujet se divisait en deux branches : la gestion, l’équipe et les personnes d’un côté, la technologie de l’autre. J’ai fini par me concentrer sur le côté technique, qui me passionne davantage, et je suis heureux que quelqu’un s’occupe du reste