Le plus difficile quand on est un fondateur non technique n'est pas de trouver quelqu'un qui sait coder. C'est d'évaluer si la personne trouvée est réellement bonne, alors que vous ne pouvez structurellement pas vérifier son travail.
Voici un cadre pour le faire quand même.
La réponse courte
| Ce que vous ne pouvez pas faire | Ce que vous pouvez faire à la place |
|---|---|
| Relire le code | Les regarder l'expliquer en direct, en langage clair |
| Juger l'architecture | Demander ce qu'ils changeraient avec 30 % de budget en moins |
| Vérifier le calendrier | Demander une démo fonctionnelle chaque semaine, pas un rapport |
| Évaluer directement la compétence | Évaluer s'ils contestent vos idées |
| Savoir si c'est un signal d'alerte | Obtenir un second avis technique avant toute signature importante |
Rien de tout cela n'exige d'apprendre à coder. Cela exige de savoir quoi demander à la place.
L'erreur que ce guide cherche à éviter
Les fondateurs non techniques n'échouent généralement pas parce qu'ils ont choisi quelqu'un d'incompétent. Ils échouent parce qu'ils ont traité le côté technique comme un prestataire exécutant un cahier des charges, plutôt qu'un partenaire censé les contredire.
Un partenaire technique qui met en œuvre tout ce que vous demandez, sans objection, ne vous aide pas - il retient la seule chose que vous ne pouvez pas fournir vous-même : le jugement sur ce qui est techniquement sensé. Si personne dans l'équipe ne peut vous dire non, vous n'avez pas de partenaire. Vous avez de la saisie de texte très chère.
Quatre façons d'obtenir de l'aide technique et celle dont vous avez besoin
Un cofondateur technique - vraie part, vraie propriété, réellement impliqué dans l'entreprise, pas seulement dans la construction. Pertinent quand l'avantage réel de votre produit est technique : un algorithme inédit, un avantage d'infrastructure, quelque chose où l'ingénierie est le rempart. Le plus coûteux en capital, le plus profond en alignement.
Un partenaire technique ou studio rémunéré, potentiellement en cash-plus-capital, fonctionnant comme un partenaire pensant produit sans statut complet de cofondateur. Nous avons écrit sur la comparaison de ce modèle avec une agence ou des freelances - en résumé, les partenaires liés au capital ont une raison structurelle de contester vos décisions de périmètre, et c'est exactement ce dont un fondateur non technique a besoin sans pouvoir le fournir lui-même.
Un CTO à temps partagé ou conseiller - un profil senior qui revoit les décisions et évalue d'autres recrutements techniques, sans écrire le code au quotidien. Bon choix une fois que vous avez des ingénieurs mais personne pour les tenir responsables ; mauvais choix si aucun jugement technique n'existe encore dans le processus de construction.
Des freelances gérés en direct - le moins cher, le plus flexible, et cela exige que vous fournissiez personnellement le jugement produit et architectural manquant. Fonctionne si vous avez déjà ce jugement d'ailleurs. Fonctionne rarement bien comme premier recrutement pour un fondateur sans bagage technique, car personne ne fournit la couche que vous ne pouvez pas fournir.
La plupart des fondateurs non techniques choisissent par défaut la quatrième option parce qu'elle paraît la moins chère. C'est souvent la plus coûteuse, car l'écart de jugement ne disparaît pas - il reste simplement non comblé jusqu'à ce que quelque chose casse.
Comment évaluer quelqu'un que vous ne pouvez pas évaluer techniquement
Quatre choses qui n'exigent pas de lire une ligne de code.
Peuvent-ils expliquer une décision technique de façon à ce que vous compreniez réellement ? Pas simplifiée - traduite. Quelqu'un qui comprend une chose en profondeur peut généralement expliquer en langage clair pourquoi elle compte. Quelqu'un qui ne le peut pas ne la comprend peut-être pas aussi bien que son vocabulaire le laisse croire.
Sont-ils en désaccord avec vous à un moment donné avant toute signature ? Un partenaire sans aucune objection à votre périmètre, votre calendrier ou votre approche n'a soit pas sérieusement examiné votre idée, soit vous dit ce qui fait signer plutôt que ce qui est vrai. Ni l'un ni l'autre n'est ce que vous attendez de la seule personne capable d'intercepter une mauvaise décision technique.
Pouvez-vous les regarder travailler en direct, plutôt que lire sur leur travail ? Une revue franche d'un projet passé - écran partagé, questions bienvenues - en dit plus à un fondateur non technique en quinze minutes qu'une étude de cas soignée en une heure. L'aisance sous questions en direct est un signal réel et non technique.
Que s'est-il passé la dernière fois qu'un projet a mal tourné pour eux ? Tout le monde a un projet qui ne s'est pas parfaitement déroulé. Quelqu'un capable de décrire le sien précisément et de dire ce qui a changé ensuite est plus fiable que quelqu'un revendiquant un parcours sans faute - notre guide pour vérifier un partenaire de développement traite cette question plus en détail, car c'est l'une des plus révélatrices accessibles à quiconque, technique ou non.
Des points de contrôle hebdomadaires sans compétence technique
Vous n'avez pas besoin de comprendre le code pour savoir si le projet avance. Vous avez besoin de quelque chose que vous pouvez observer directement.
Une démo fonctionnelle, pas un rapport d'avancement. « Nous sommes à 70 % sur la couche API » ne vous dit rien de vérifiable. Cliquer dans une vraie fonctionnalité, même brute, vous dit tout - soit elle fait le travail, soit non.
Une réponse en langage clair à « que couperiez-vous avec moins de budget ». Immédiate et précise signifie qu'ils comprennent les priorités du produit. Un long silence ou « tout est important » signifie que ce n'est pas encore le cas, et qu'ils ne pourront pas vous protéger des problèmes de périmètre plus tard.
La cohérence entre ce qu'ils disent et ce que vous pouvez voir. Si la version racontée de l'avancement sonne toujours mieux que ce que vous pouvez cliquer vous-même, c'est cet écart le signal - pas le récit lui-même.
Le capital, si vous partez sur cette voie
Ne pas être technique ne change pas la mécanique d'un accord de capital, mais augmente la valeur d'un second avis indépendant avant signature. Les protections de base sont les mêmes quel que soit votre bagage : un vesting lié à de vrais jalons de livraison plutôt qu'attribué d'emblée, un pourcentage proportionnel au cash que vous ne payez pas, et des actions ordinaires uniquement - pas de siège au conseil, pas de droit de veto. Nous couvrons toute la mécanique, y compris à quoi ressemble un échange cash-contre-capital équitable, dans notre guide sur le capital pour un partenaire technique.
Si la demande de capital d'un partenaire potentiel ne correspond pas proprement au cash qu'il consent à abandonner, cela mérite un second avis, quelle que soit son assurance en l'expliquant.
La question la plus importante
Demandez à chaque candidat : « À quoi vous opposeriez-vous si je vous le demandais ? »
Un vrai partenaire technique a une réponse immédiatement, parce qu'il s'est déjà forgé des opinions sur votre idée. Celui qui répond « je construirai ce que vous voulez » ne fait pas preuve de souplesse - il vous dit, aussi clairement que possible, que vous prendrez chaque décision technique seul. En tant que fondateur non technique, c'est précisément la seule tâche que vous ne pouvez pas assumer vous-même.
Vous ne savez pas s'il vous faut un cofondateur, un partenaire ou un conseiller ? Décrivez où vous en êtes et nous vous dirons honnêtement quel modèle convient - y compris quand ce n'est pas nous. Nos tarifs et conditions de capital sont publiés ouvertement.
Questions fréquentes
Écrit par
Shakhbozbek Usmonov
Founder & CEO, Steppe Venture Builders
