Arpinum

Voilà deux fois que j’ai la chance de participer en tant que mentor technique à un google launchpad. Cela m’inspire du coup quelques réflexions en live sur l’évènement en question et le monde des startups.

Launchpad ?

Si vous n’êtes pas familié du concept, à la base le launchpad est un format qui n’a rien à voir avec Google. L’idée est de proposer une semaine assez (très) intense aux startups, pour leur faire rencontrer des mentors dans 4 catégories :

• Produit
• UX
• Marketing
• Technique

Voici la vidéo (très) promotionnelle de la version bordelaise :

Une note sur Google et le Launchpad

Pour répondre en vrac à vos éventuelles questions :

• Google ne nous rémunère pas en tant que mentor. À chacun de trouver sa motivation pour donner de son temps : rencontrer, partager, se faire connaître… je laisse votre degré de cynisme trancher à ma place :)
• Il n’y a aucune obligation à vendre du produit Google, mais vraiment aucune. Je n’ai reçu aucun message secret, aucun pigeon voyageur, menaçant ma famille si je ne plaçais pas du google dans mes sessions de mentoring
• Comment Google gagne de l’argent là dessus ? Le sujet est vaste, leur position officielle est “plus il y a de gens sur Internet, plus on fait d’argent. Donc plus il y a de startups qui ramènent du monde, mieux c’est pour nous.”

Le format

J’ai été assez séduit par le format : les thèmes abordés sont vitaux, ils sont bien choisis, et sont souvent bien introduits. Sur ma partie technique, j’apprécie l’orientation officielle : “le développement est le goulet d’étranglement, vous voulez vous optimiser pour la vitesse de développement, ça passe par un certain nombre de bonnes pratiques”. C’est un peu le message en substance. C’est pour ça que normalement, les startups ont une obligation d’amener leur CTO avec eux.

La technique sous estimée

Malgré le discours bien rodé et très vrai du launchpad sur l’importance de la technique, et le fait que quelques startups l’avaient déjà bien compris, j’ai tout de même eu droit à mon lot de questions / remarques pouvant ressembler à ça : 

• Comment je trouve un bon stagiaire pour développer mon produit ?
• L’architecture ? Beuh ça sert à rien
• L’architecture ? Ah oui on fait du MVC ?
• L’architecture ? On utilise MySQL
• …

Je ne veux pas paraître méchant, toutes les startups que j’ai vu mettent toute leur énergie, leurs connaissances, leur passion au service de leur vision. Ce qui m’interroge moi en tant que maintenant eXtreme Programmer de 13 ans d’âge affiné en fût de chêne, c’est : mais mon dieu, pourquoi en 2015 encore notre profession n’a pas réussi à :

• tordre le coup à cette vision du développement pisseur de code,
• tordre le coup à cette vision qu’un stagiaire en vaut bien un autre, c’est pas un souci la technique,
• enseigner au berceau l’importance du code propre, et les techniques pour y arriver. J’ai l’impression que nos cursus forment deux catégories : les wanabees chef de projets d’un côté, les cowboys coders fans de bricoler des lignes au hasard à 2h du mat de l’autre.

Le CTO

La vraie question fondamentale derrière, c’est de savoir à quoi peut bien servir un CTO dans une startup ?  Mon point de vue je pense ne s’applique bien sûr qu’aux startups un minimum technologiques. C’est à dire, sans forcément parler d’inventer un nouvel algorithme ou service complètement révolutionnaire, votre valeur est entièrement basée sur une solution faite maison. Étant donné que c’est votre moteur de revenu, le confier au premier stagiaire venu paraît donc, au mieux risqué.

Compétences techniques

À vos débuts, vous n’avez probablement pas les moyens de vous payer une grande équipe de développement. Cela veut donc sûrement dire que le CTO va devoir coder. Si vous tombez sur un CTO architecte, qui ne veut pas écrire une ligne de code, ce n’est pas la bonne personne.

C’est un difficile jeu d’équilibriste qu’être CTO au début d’une startup : il faut avoir une connaissance assez encyclopédique de technologies pour pouvoir les proposer (et pas seulement systèmatiqumenet dégainer Rails/Grails whatever), mais en même temps avoir la sagesse de piocher celles qui sont utiles pour le produit. Le cliché du monde des startups est de croire que vous avez déniché le meilleur CTO du monde car il vous a proposé de tout faire en Node/Ruby/Elixir : choisissez une technologie à la mode.

Vision

Une constante dans le développement est que vos développeurs doivent s’imprégner et vivre votre vision, sinon ils seront bien en peine de créer un produit y répondant. Comment espérer avoir un bon résultat si les personnes fabriquant la solution ne comprennent pas le problème ?  Cela implique que le CTO doit effectivement maîtriser pas mal sa technique, mais toujours garder en tête qu’il est là pour fabriquer un produit, pas se faire plaisir avec des technos à la mode, ou pisser des lignes jusqu’à 4h du mat. Le meilleur code qu’il puisse produire est celui qu’il n’a pas à écrire.

Il s’agit en fait de créativité et d’inventivité : étant donné tous les outils et technologies que je connais, comment trouver la manière la plus simple (et non pas simpliste) de mettre en œuvre cette vision ? 

Culture

Mais fondamentalenment, le rôle critique du CTO au début, c’est la création de votre culture technique. Je vous conseille la lecture de Team Geek à ce sujet, mais je vais bien sûr tenter d’expliquer un peu ça. Le postulat numéro un est que la culture est auto répliquante, donc vos débuts sont primordiaux. Si vous avez un CTO qui aime la bricole, qui produit des solutions à l’arrache fonctionnant seulement les soirs de pleine lune, alors n’espérez pas «refaire au propre un jour». C’est dans votre ADN de fonctionner comme ça, vous n’attirerez donc que des développeurs et développeuses en accord avec ça.

Vous vous doutez que au contraire, si vous avez un CTO par exemple fan d’eXtreme Programming, alors vous avez toutes les chances d’attirer par la suite d’autres pratiquants : c’est à dire des personnes cherchant à faire le plus simple qui fonctionne, pas le plus simpliste, sachant que le code de merde n’est non seulement pas une fatalité, mais quelque chose qui peut tuer votre boîte… bref, vous voyez l’idée.

Alors bien sûr, il est possible parfois d’échapper à ce côté très fataliste de la culture auto-réplicante, mais posez-vous la question: vous avez fait fabriquer à l’arrache une solution bancale pour démarrer. Maintenant, vous voulez grossir, en attirant les meilleurs développeurs et développeuses du coin. Vous leur vendez quoi ? «Bonjour, vous allez devoir maintenir une application pourrie codée avec les pieds. Vous nous remettez ça au propre vite fait ? Ah non on va pas repartir de 0 quand même, elle marche après tout cette application». La plupart des développeurs professionnels n’ont aucune envie de rattraper les erreurs de leurs prédecesseurs, et vous êtes en concurrence avec énormément de boîtes pouvant proposer un cadre de travail beaucoup plus attractif. Encore une fois, vous n’allez donc attirer que des développeurs ne voyant rien de choquant dans l’incroyable plat de spaghetti que vous leur servez.

Le mot de la fin

Je pourrais également vous parler du coût incroyable d’une technique mal maîtrisée, des startups que nous avons croisé ayant dépensé tout leur investissement initial dans un MVP ne fonctionnant pas, mais je vais vous épargner cela :)

En attendant, si vous voulez nous payer une bière pour en parler, nous sommes à votre disposition.