Article original : How to become your own technical co-founder — and why it’s worth your time
Note : ce blog est inspiré par mon récent entretien de podcast avec Quincy Larson de freeCodeCamp, où nous parlons de cela dans les 15 dernières minutes environ.
Vous cherchez un co-fondateur technique ? Moi aussi. Pendant de nombreuses années. Ce fut un voyage difficile, car la "sagesse" dominante est que vous devez sortir et trouver un co-fondateur technique parce que toutes les startups réussies en avaient un (ce qui n'est pas vrai, soit dit en passant). Mais que se passe-t-il lorsque vous êtes au bout de votre course, et que votre choix est d'apprendre à coder, ou d'abandonner ?
Les co-fondateurs techniques sont censés vous apporter la stabilité, le complément des compétences essentielles et la responsabilité qui ne sont pas possibles en tant que fondateur solo. Bien sûr, personne ne suit les innombrables exemples où avoir un co-fondateur médiocre a rendu votre voyage incroyablement plus difficile, ou a entravé votre capacité à progresser. Mais bien sûr, ce qu'ils veulent dire, c'est que vous n'avez pas besoin d'un simple co-fondateur technique, vous avez besoin du bon co-fondateur technique, évidemment !
Eh bien, évidemment.
Aucun de ces conseils n'est particulièrement utile. C'est comme dire que vous devez être éveillé pour avoir de bonnes idées (ce qui semble évident et intuitif, mais pas toujours vrai).
Mon expérience en tant que fondateur non technique (solo)
Voici ce que j'ai personnellement vécu au cours des nombreuses années où j'ai cherché des co-fondateurs techniques :
J'ai passé beaucoup de temps à parcourir des forums, LinkedIn et des listes de contacts à la recherche de personnes qui répondaient aux critères minimaux
J'ai passé beaucoup de temps à ne pas pouvoir valider grand-chose, tester grand-chose, progresser grand-chose parce que je n'avais rien à valider, tester ou progresser autre qu'un pitch bien rodé
J'ai rencontré beaucoup de gens, et la plupart n'étaient pas intéressés par l'entrepreneuriat, ou n'avaient pas l'éthique de travail nécessaire (aka la streak masochiste)
J'ai rencontré beaucoup de gens qui étaient intéressés mais pour toutes les mauvaises motivations (devenir riche rapidement, gloire, célébrité…)
J'ai rencontré quelques personnes qui avaient les bonnes motivations et (autant que je pouvais en juger) les bonnes compétences, mais qui n'avaient pas la mentalité pour supporter la brutalité du démarrage
J'ai rencontré très peu de personnes qui avaient l'expérience du démarrage et les compétences, mais aucune d'entre elles n'était enthousiasmée par mes concepts (inévitabilité statistique)
Je ne savais rien à propos du logiciel, bien que je voulais créer une entreprise technologique. Donc, voici mes erreurs de l'époque :
Je n'avais aucune idée des aspects fondamentaux, les plus basiques du logiciel et de sa conception
J'ai gravement sous-estimé la complexité impliquée (je ne savais pas combien je ne savais pas)
J'ai gravement sous-estimé le temps impliqué
J'ai gravement surestimé les personnes que j'ai approchées pour être des co-fondateurs techniques
J'ai significativement (mais sans le savoir) surestimé mon rôle dans la période initiale — le "hustling" et le "business development" étaient mes compétences, et je n'ai pas apprécié que certaines des entreprises les plus réussies ont passé un tiers de leur temps sur ces choses, et la plupart de leur temps à construire le produit et à répondre aux besoins des clients
Pendant près de 4 ans, je me suis dit "Je n'ai pas besoin d'apprendre à coder. Mes talents sont mieux utilisés ailleurs ". Ça vous dit quelque chose ?
C'est seulement partiellement vrai. En tant que personne avec des ressources très limitées, mes talents devaient être utilisés sur ce qui me donnait la meilleure chance de réussir. J'avais un peu d'argent de côté que je pouvais dépenser pour des développeurs. J'avais un peu de temps que je pouvais passer à les gérer, et ce temps était principalement créé en réduisant mon activité sociale, mon sommeil et en me privant de week-ends. J'avais une expérience précieuse que je pouvais utiliser pour mettre en place un plan d'affaires. J'avais de solides compétences sociales et de communication que je pouvais utiliser pour pitcher des prospects, et aussi pour des co-fondateurs potentiels.
J'ai fait toutes ces choses, et j'ai progressé vers mes objectifs. Mais cela a pris beaucoup trop de temps. Bien sûr, le progrès est toujours lent, certainement plus lent que nous le souhaiterions. Mais nous ne faisons que nous ralentir davantage en ne regardant pas la situation objectivement. Même lorsque j'avais des co-fondateurs (qui ont finalement abandonné parce que c'était trop difficile ou que leurs circonstances de vie ont changé), j'ai constaté que la gestion de leur éthique de travail, de leurs attentes et de leurs humeurs prenait beaucoup de mon temps et de mon énergie. C'est bien — mais personne ne budgétise pour cela.
Vous voyez, en tant que fondateurs aspirants, notre plus grand ennemi est tout ce qui nous fait perdre du temps. Chaque semaine qui passe sans résultats augmente la probabilité que vous abandonniez. Et nous ne savons jamais vraiment quel est le coût de notre temps lorsque nous choisissons une ligne de conduite. Et nous ne savons jamais quand nous sommes victimes du sophisme des coûts irrécupérables.
En regardant en arrière, cela m'a coûté 4 ans et beaucoup d'argent. Et à la fin de cela, la seule façon de recommencer était de répéter cette dépense de temps, d'efforts et d'argent, en faisant la même chose — mettre en place un plan, puis chercher désespérément un co-fondateur technique.
Nous y voilà à nouveau…
Une simple équation de temps
En 2014, j'ai lu un blog de Sam Altman, le président de YCombinator. Dans cet article, Sam dit certaines des vérités les plus profondes que j'ai jamais ignorées. Voici le tweet que j'ai déterré pour le plaisir.
Les deux ou trois premières fois que j'ai lu son article, j'ai fait des arguments qui semblaient très sensés pour expliquer pourquoi cela ne s'appliquait pas à moi. J'avais tort et cela m'a coûté de l'argent, mais pire, cela m'a coûté beaucoup de temps (j'ai récupéré l'argent).
Il pose essentiellement que c'est plus rapide (beaucoup plus rapide) d'apprendre à programmer assez pour construire votre prototype que de trouver un co-fondateur fiable, sur qui on peut compter, qui est un bon choix, et qui ira jusqu'au bout. Non seulement plus rapide, mais les chances de progresser sont considérablement plus élevées.
C'est évident. Trouver un bon co-fondateur, technique ou non, est un coup de chance — comme trouver le bon partenaire pour la vie — et nécessite une certaine dose de chance. Apprendre à coder un peu est plus rapide, ne nécessite pas de chance et a donc un taux de réussite plus élevé.
En fait, vous pouvez arrêter de lire ce blog ici si vous le souhaitez. Lisez le sien. Il est meilleur. La seule raison pour laquelle j'écris le mien est de partager des expériences directes et personnelles qui confirment ce qu'il a dit. Il est révélateur qu'à ce jour, son blog n'a eu que ~8 500 vues — dont une douzaine sont les miennes. C'est beaucoup moins que le nombre de fondateurs non techniques aspirants qui existent.
Une analogie avec les rencontres
Au lycée, je me souviens qu'on m'a dit que si vous êtes désespéré pour les affections de quelqu'un, vous agirez de manière à vous compromettre — vos normes, vos valeurs et vos meilleurs intérêts. Vous vous contenterez de personnes, de comportements et de situations qui ne vous conviennent pas.
C'est exactement la même chose avec la recherche de co-fondateurs. Au fil du temps, alors que ma peur et mon désespoir augmentaient, je me suis surpris à faire des compromis — à réduire mes normes. À négocier contre moi-même. À faire des excuses pour les autres. À me contenter de moins.
Avec le temps, j'ai pris de mauvaises décisions et fait de mauvais compromis. Heureusement, aucune de ces mauvaises décisions n'a abouti à des relations de co-fondation réelles.
Mon point est que j'étais prêt à faire de mauvais compromis, juste pour progresser. Ce n'est pas un bon début pour quelque chose qui pourrait vous occuper les 10 à 20 prochaines années de votre vie.
Le côté technique ne s'arrête pas au lancement
Il est tentant d'être tactique et de dire que je dois juste arriver au lancement. Ce n'est pas un plan durable. Il y a une différence entre prévoir de "faire face quand j'arriverai à ce pont" et devoir le faire parce que la vie ne vous a laissé aucun choix.
J'ai appris à mes dépens que mon besoin d'aide technique a augmenté après le lancement. Je pensais que les moments difficiles étaient ceux pour arriver au lancement. Oh, comme je me trompais. Les choses se cassent. Des bugs apparaissent. Les fonctionnalités ne fonctionnent pas comme prévu. Les utilisateurs ont des opinions fortes sur les choses. L'itération est le moyen d'atteindre l'adéquation produit-marché. Et cela doit être rapide, bien coordonné et systématique. Les données aident, et beaucoup de données précieuses arrivent après le lancement !
C'est pourquoi payer des développeurs n'est pas durable à moins d'avoir beaucoup de financement. Et vous n'êtes pas susceptible d'obtenir beaucoup de financement avant même d'avoir un produit. C'est possible, mais pas pour la plupart des fondateurs.
Alors, que allez-vous faire lorsque, 4 semaines après le lancement, les choses se cassent, les utilisateurs signalent des bugs inattendus, et le serveur plante, ou l'app store a changé une politique ? Vous dépensez plus d'argent. Et vous suppliez les développeurs de se dépêcher. Pendant ce temps, vous faites de votre mieux pour trouver des utilisateurs, pitcher, vendre, etc.
Vous passez votre temps sur des choses, c'est sûr, et elles sont importantes. Mais, donné le choix entre corriger un bug / ajouter une fonctionnalité que vos utilisateurs réclament, et pitcher votre plan d'affaires à un potentiel investisseur en capital de démarrage, la meilleure utilisation de votre temps est le produit, pas le pitch. Et vous ne pouvez pas le faire parce que vous ne savez pas comment. Donc, vous vous exercez sur des choses de conséquence secondaire parce que vous ne pouvez pas vous exercer sur des choses d'importance primordiale.
Développer l'empathie technique
Comme je l'ai mentionné dans le podcast, j'étais (de manière mortifiante) l'une de ces personnes qui insistaient sur le fait que "c'est un prototype simple et rapide". Je manquais totalement, absolument, lamentablement, de toute notion de ce à quoi ressemble le processus de développement.
Quincy, le fondateur de freeCodeCamp et celui qui anime le podcast, l'a très bien résumé :
Cela vous donne de l'empathie pour l'expérience du développeur, et vous aide à faire des estimations de temps significatives, non seulement en termes de ce qui est possible, mais aussi de ce qui est simple et de ce qui est complexe. [paraphrasé]
Imaginez si quelqu'un qui n'a aucune idée de votre travail vient vous voir et insiste sur le fait que quelque chose qui prend une semaine devrait prendre 2 jours — n'auriez-vous pas envie de lui taper sur la tête et de simplement vous détourner avec dégoût ?
Je suis sérieusement embarrassé par toutes les fois où j'ai fait cela (insister sur le fait que c'est une application simple, ne pas taper sur la tête de quelqu'un).
Pire encore, pourquoi me prendraient-ils au sérieux ? Leur avais-je vraiment montré du respect et de l'engagement en essayant au moins d'apprendre un peu de leur métier ? De leur point de vue, je me cachais derrière mes compétences et l'excuse raisonnable que le codage n'est "pas la meilleure utilisation de mon temps ".
Voici un autre effet pervers de ne pas être suffisamment compétent sur le plan technique. Je ne pouvais jamais évaluer les compétences relatives des personnes à qui je parlais. Je devais me fier à la foi, à la confiance ou aux recommandations. Je n'avais aucun moyen d'évaluer leur aptitude à remplir précisément la fonction dont j'avais besoin.
En regardant en arrière, j'aurais pu me faire économiser beaucoup d'argent et des mois d'efforts, tout en développant une compétence qui prolonge ma course presque indéfiniment — si j'avais appris à coder plus tôt.
Comme le dit Sam Altman :
"Lorsque des personnes comme celle-ci disent 'Je ferai tout ce qu'il faut pour que cette entreprise réussisse' (ce qu'elles disent presque toujours), je réponds quelque chose comme 'Pourquoi ne pas apprendre à coder ?'"
Pourquoi pas, en effet. Faites tout ce qu'il faut. Surtout si cela aide votre startup à 'ne pas mourir'.
L'ingénierie n'est pas la panacée
Je ne pense pas un instant que le codage soit la réponse à tout. Si vous faites partie de ceux qui ont un co-fondateur technique intéressé et totalement fiable, un camarade de classe, un collègue, un frère ou une sœur, etc., alors oui, ce n'est pas la meilleure utilisation de votre temps — pourquoi ? Parce que vous avez une excellente ressource en cette autre personne. Alors, apprendre à coder est une duplication des compétences.
Mais lorsque vous n'avez pas cette compétence, en apprendre un peu est la meilleure utilisation de votre temps, si cela vous fait économiser beaucoup de temps à long terme. Voici le calcul que j'applique :
priorité = probabilité de résultat dans une unité de temps donnée
Donc :
Trouver un co-fondateur en 6 mois et commencer à construire dans le 7ème mois : probabilité de 50%
Apprendre suffisamment de code en 6 mois et commencer à construire dans le 7ème mois : 90%
Cet article entier serait totalement évident s'il disait que les codeurs doivent apprendre les compétences en marketing et en communication pour pitcher. Les codeurs doivent sortir du bâtiment et parler à leurs clients et ne pas seulement coder. Cela est maintenant considéré comme un conseil "évident".
Alors pourquoi l'inverse n'est-il pas tout aussi évident ?
Donnez-vous de la crédibilité
Les ingénieurs sont comme la très belle fille au bar. Ils se font "draguer" tout le temps. On les approche tout le temps. Je ne sais pas directement, mais je suppose que cela devient fatiguant rapidement, et que le cynisme est juste un autre "vous allez adorer mon idée de startup".
Vous savez ce qui est rafraîchissant pour quelqu'un que vous draguez au bar ? L'intérêt et la conscience de leur existence. Il en va de même pour les codeurs. Si vous êtes suffisamment conscient de leur monde et suffisamment intéressé par les détails de leurs compétences, ils répondront et, à tout le moins, aideront.
Cette partie, je la connais par expérience personnelle. Depuis que j'ai appris à coder, j'ai beaucoup plus d'ingénieurs heureux de me donner des conseils, de me guider, de me corriger et même de plonger dans mes idées avec moi. Ce n'est pas plus facile de trouver le bon co-fondateur, mais cela n'a rien à voir avec l'expertise, et plus avec leurs intérêts, leurs priorités et leurs circonstances de vie.
Et maintenant ?
Et maintenant, pour la première fois de ma vie, je suis dans une position où je peux expérimenter avec mes idées. Auparavant, cela me coûtait du temps et de l'argent. Maintenant, cela me coûte un peu de temps, et même alors moins de temps que de trouver des développeurs, négocier la portée, superviser le travail, examiner le travail, tester le travail. Et ce temps est un investissement car je continue à améliorer la compétence même si l'idée s'avère commercialement non viable.
Je ne suis pas un grand codeur. Je ne pense pas avoir besoin de l'être (peut-être que dans 5 ans je réviserai cette opinion). Mais je sais assez pour construire mes propres prototypes et comprendre ce qui est impliqué dans la construction d'un produit viable. Et je sais assez pour prendre une décision sur les parties à externaliser, comment décrire ce que je veux, ne pas me faire avoir, évaluer le résultat et m'associer avec d'autres hackers pour obtenir des résultats. Je ne serai peut-être jamais un développeur professionnel, et c'est bien. Ce n'est pas de cela qu'il s'agit.
Mais je suis devenu mon propre co-fondateur technique. Il peut venir un jour où la meilleure utilisation de mon temps sera vraiment le côté non technique. Mais ce jour viendra une fois que j'aurai construit quelque chose qui grandit. Je crois avoir augmenté mes chances de trouver cette chose simplement parce que je peux mener beaucoup plus d'expériences bon marché et peu stressantes qui ne nécessitent pas que je dépense de l'argent ou que je supplie les autres de m'aider.
Tout cela en moins de 12 mois. Réfléchissez-y. Peut-être que c'est vraiment la meilleure utilisation de votre temps si vous voulez être un fondateur.
Je crois vraiment, sincèrement, que vos ressources les plus précieuses sont votre temps, vos efforts et votre argent. Parmi celles-ci, la ressource la plus importante est le temps, car les deux autres peuvent être renouvelées et récupérées. Donc, si vous allez passer du temps sur quelque chose, assurez-vous que cela vous rapproche de cet objectif.
Si vous souhaitez en savoir plus sur mon parcours dans le code, consultez l'épisode 53 du podcast freeCodeCamp, où Quincy (fondateur de freeCodeCamp) et moi partageons nos expériences en tant que changers de carrière qui pourraient vous aider dans votre parcours. Vous pouvez également accéder au podcast sur iTunes, Stitcher, et Spotify.
Je tiendrai également quelques AMAs et webinaires dans les mois à venir. Si cela vous intéresse, faites-le moi savoir en allant ici. Et bien sûr, vous pouvez également me tweeter à @ZubinPratap.