S’il y a bien un sujet qu’on a l’habitude de voir sur les différents groupes de start-ups sur les réseaux sociaux, ce sont des demandes du genre “Startup à fort potentiel recherche son CTO”.
Un peu comme si le CTO était la pièce maîtresse du projet : sans CTO, point de projet.
Or cette affirmation est fausse et peut créer à moyen terme de vrais problèmes entre associés.
Décryptons pourquoi ce fameux CTO est souvent une mauvaise idée (ou du moins une idée mal formulée).
C’est quoi un CTO ? 👷♂️
CTO ce n’est pas qu’un titre, c’est avant tout une fonction.
Un CTO c’est avant tout un manager. C’est quelqu’un dont vous avez besoin pour gérer une équipe.
C’est donc un profil certes technique, mais surtout capable de piloter une équipe, disons à partir de 10 personnes.
Typiquement un CTO n’est pas un développeur (même s’il sait faire) : sa vraie valeur ajoutée va être de pouvoir faire grandir une équipe et faire en sorte qu’elle travaille efficacement. C’est donc plutôt (et souvent) un profil de type ingénieur.
C’est aussi quelqu’un capable de recruter, de reporter, d’organiser, de planifier… Bref, pas tout à fait le profil du dev dans son garage.
Souvent, on va retrouver dans les start-ups une équipe de 10 personnes habituées à coder un peu à l’arrache et petit à petit ça marche moins bien (régressions, délais qui augmentent pour livrer, corrections de bugs, clients qui râlent etc). C’est généralement le signal que vous avez besoin d’un CTO.
Quand vous recrutez un CTO, c’est généralement quand votre entreprise a acquis une certaine taille, mais ce n’est probablement pas nécessaire au tout début.
Alors pourquoi tout le monde cherche un CTO ? 🔎
Les créateurs de start-up fonctionnent souvent par mimétisme : “si mes confrères cherchent un CTO, alors j’ai besoin d’un CTO”, “A Station F, toutes les start-up ont un CTO”.
CTO c’est un boulot C-Level, signifiant une position Comex dans l’entreprise : un C-level va avoir des parts et la garantie de rester manager le long du chemin.
Hors c’est justement souvent là que ça coince : quand l’entreprise se développe et que se fait jour le besoin d’un vrai CTO, quid de la personne que vous avez associé dès le départ et qui se croit (de bonne foi) compétente dans le rôle ?
Ok compris, alors je dois chercher quoi en fait ? 🧐
Dans 99% des cas, les start-ups en seed ont besoin d’un lead dev.
C’est quoi un lead dev ? C’est un développeur senior, très expérimenté et capable de coder à peu près n’importe quoi et d’y passer 10 ou 12h par jour quoi qu’il en coûte.
Sans être spécialiste, un lead dev saura vous accompagner, seul ou avec peu de ressources, jusqu’à vos 1000 ou 10000 premiers utilisateurs.
Il est aussi capable de gérer une petite équipe de 4 ou 5 personnes, mais le plus souvent le management le gonfle (et oui, il est développeur, pas manager).
Au-delà, dès qu’on commence à vraiment attaquer le travail en mode projet, l’histoire change complètement.
Vous l’aurez compris, on est très loin de notre définition du CTO de départ et sur un poste beaucoup plus opérationnel qu’un CTO.
J’ai le lead dev, mais il veut être CTO 🤔
Cas classique : le poste de CTO est appétant et comme vous lisez les mêmes sources, le lead dev que vous recrutez va vouloir être CTO (“Je suis le premier dev, donc je dois être CTO et avoir 5% de la boîte”).
C’est là qu’il faut être clair et ferme : à la fois vous pouvez tout à fait intéresser un lead dev au capital, autant ça ne veut pas dire qu’il pourra être CTO.
De deux choses l’une, soit votre lead dev a déjà été CTO (voir ci-dessous), soit c’est purement de l’ego. Dans ce cas-là, c’est vraiment à vous de déterminer la position que vous êtes prêt à accepter.
Retenez juste qu’une faiblesse à cet instant précis peut signifier une vraie galère dans le futur.
Et moi j’ai trouvé un vrai CTO 👍🏻
Alors oui bien sûr, il est possible que vous ayez dans votre pool de candidatures de vrais CTOs.
Dans ce cas ça peut être intéressant, car avoir un CTO associé en early stage est évidemment un atout quand vous en aurez vraiment besoin.
Mais là encore la situation n’est pas parfaite car votre CTO, habitué à manager une équipe, va se retrouver à coder 8 heures par jour. Sera-t-il le meilleur pour cela ?
C’est pourquoi il faut vraiment être clair dans votre approche : “Ok, tu seras CTO à terme, mais là on a surtout besoin d’un lead dev”.
Dans les deux cas, l’important c’est d’énoncer clairement les objectifs.
Autre possibilité : votre CTO nouvellement associé vous convainc de l’urgence de recruter immédiatement un lead dev 🙂
Mais mon VC exige un CTO ! 🎩
Un grand classique là encore, mais toujours une erreur à mon sens, qu’elle soit dans votre façon de le présenter ou dans l’appréciation du VC.
Un vrai VC, qui connaît votre sujet, sera à même d’apprécier vos choix, surtout s’ils influencent la table de capitalisation de l’entreprise.
Un VC est là pour vous aider à remporter vos challenges, notamment technologiques
Si votre VC boucle sur le terme CTO quand vous lui expliquez votre stratégie, alors ce n’est probablement pas le bon VC.
Parts, dilution, capital 📊
Même si évidemment on se lève pour changer le monde, on n’en reste pas moins vigilants sur la répartition de l’actionnariat de notre future licorne.
Donner 3, 5 ou 10% du capital dès le départ à un associé technique que l’on ne connait pas est presque toujours une mauvaise idée (ou s’approche d’un tour de roulette au casino).
Je dis presque car évidemment il y aura toujours des contre-exemples, mais dans l’ensemble, quand un on associe un lead dev et qu’on se rend compte qu’on a “surévalué” son rôle, on le regrette.
On le regrette parce qu’on a quelqu’un de significatif dans la table de capitalisation mais qui n’est finalement qu’un dev parmi d’autres, mais aussi parce que l’on a moins de BSPCE à distribuer au vrai CTO quand il arrive (ainsi qu’aux autres managers d’ailleurs).
La règle que je conseille c’est d’éviter d’associer un responsable technique en actions dès le départ. Si vous le pouvez, préférez des BSPCE. Souvent le pari technologique est tel qu’il est difficile d’évaluer le chantier technique, notamment quand on n’a pas les compétences (cas typique du cofondateur business.). Avec les BSPCE, vous posez quand même une certaine obligation de résultat.
Je suis une star et je prends une star ⭐️
La encore, bien évidemment le choix d’un CTO (ou d’un cofondateur en général) dépend de la maturité de votre projet.
Si vous avez LE projet sexy pour les VC qui vont investir un pognon de dingue à une valorisation de dingue, bien sûr la situation est différente.
Si vous recrutez les salariés par dizaine, avec des dizaines de millions d’euros, bien sûr vous devrez prendre un CTO dès le départ. Mais là c’est justifié, car vous en aurez vraiment besoin.
Bon alors je fais quoi ? 😅
Objectivement, le fait de chercher un CTO à la place d’un lead dev ne fait que vous compliquer la tâche.
Il faut aussi prendre en compte la capacité d’évolution des gens : peut être que votre lead dev d’origine pourra devenir CTO à la fin.
De la même manière, peut-être que votre CTO va se révéler capable de pondre ce fameux MVP.
Bref, je suis désolé de vous dire que ce post n’apporte pas de réponse ferme, mais plutôt des pistes basées sur mon expérience.
Comme souvent, vous n’aurez aucun problème à prouver que mon analyse est fausse ou que votre situation est différente, mais ça fait avancer le débat. 👍🏻
From zero to CTO : notre REX chez Sellsy
L’organisation des équipes techniques chez Sellsy est passée par plusieurs phases, assez symptomatiques de ce que font les start-ups en général.
La phase 1 : “les devs”
Pendant toute la phase de Seed de Sellsy, jusqu’à atteindre une taille une équipe de 10 personnes, l’organisation était assez facile à résumer :
C’est une période où tous les développeurs font un peu tout : fonctionnalités, corrections de bugs, tests (éventuellement 😅), architecture, base de données etc.
C’est la période “garage”, tout le monde travaille en immédiate proximité.
Tout le monde est un peu CTO, enfin disons que les leads devs sont les CTO.
Bien évidemment, ça devient assez rapidement ingérable.
La phase 2 : répartition par business units
Pour répondre à ce défaut d’organisation, nous choisissons alors la solution qui semble la plus logique à l’époque : créer des équipes spécialisées sur les différents grands sujets que nous avons à traiter.
Par exemple, nous allons créer une équipe dédiée à nos fonctionnalités CRM. Cette équipe intègre l’ensemble des ressources nécessaires : product owner, développeurs, testeurs, etc.
À ce stade les équipes commencent à travailler en mode projet, principalement grâce au kanban.
C’est déjà un progrès énorme et le développement prend une autre dimension.
Ce n’est cependant pas satisfaisant car plusieurs points de faiblesse apparaissent :
- produit et engineering sont mixés
- les équipes connaissent peu ou mal les sujets des autres
- travailler sur le même sujet peut induire une certaine lassitude avec le temps
- la planification et le suivi sont loin d’être optimaux
- il est difficile d’avoir une vision claire de l’ensemble du projet et des délais
À ce stade, notre CTO, enfin arrivé parmi nous décide qu’il faut évoluer. En effet l’équipe n’arrête pas de grandir et le fonctionnement montre de plus en plus ses limites.
Nous avons donc encore changé 😅
La phase 3 : le SCRUM
Sans reprendre toute la définition du SCRUM, cette organisation est très différente de notre organisation précédente, car elle modifie sensiblement la répartition des équipes.
Comme on le voit, les équipes Produit et Engineering sont désormais clairement séparées.
Le rôle du produit est de définir en amont les user stories, d’en estimer le temps de développement et de les programmer dans les sprints.
Les sprints sont des périodes de 15 jours durant lesquelles une équipe de développeurs complète (5 ou 6 personnes) doit produire l’ensemble des entrées définies en amont avec le produit.
En aval, le produit reprend la main pour tester les features, les documenter dans notre FAQ et les faire connaître aussi bien de nos équipes que de nos clients en lien avec le marketing.
Cette organisation nous a permis d’être beaucoup plus précis sur les délais de développement et l’avancement de notre roadmap.
La création d’une équipe dédiée bug et support nous permet également de réagir beaucoup plus vite, notamment lorsqu’un client rencontre un point bloquant.
Typiquement si l’on prend notre roadmap des six prochains mois, nous sommes sûrs à 90% que ce sera bien produit.
