Qu'est ce qu'il se passe dans la tête d'un CTO ?

Bonjour à tous,

Cela fait un bail que je n'ai pas écrit un article sur mon blog. Et je vous propose d'aborder le monde des startups et spécifiquement de la relation entre le porteur de projet (CEO) et le futur CTO, dans le cadre d’une collaboration passionnante.

Je voudrais au travers de cet article aider les futures CTO et CEO, à mieux se comprendre, se préparer à leur rencontre sous un angle que je maitrise bien :

Qu'est ce qu'il se passe dans la tête d'un CTO ?

Le future CTO se situe dans le bon côté, c'est à dire là où les très nombreux porteurs de projet se battent pour s’accaparer les peu de ressources techniques disponibles. Le rapport de force est tellement fort que certains CEO se forment à la programmation pour palier à la dure loi de la concurrence.

Avant de commencer, il faut préciser que le focus se porte sur les CEO qui n’ont pas encore levé de l’argent. En effet,   la levée de fond est plus contraignante que la recherche d’un CTO. Et avec une levé de fond, il est plus simple de trouver son CTO, si on ne l’a pas déjà …

Je vais donc traiter de différents aspects qui sont :

1-      Montage d’un dossier

2-      L’affinité entre un projet et le CTO

3-      La sagesse et l’honnêteté

4-      Le produit en lui-même

5-      Le temps, la contrainte principale

6-      Les startups sur un nuage

LE DOSSIER

L'analogie entre la recherche d’un CTO avec celle d'un appartement pour un jeune au milieu de Paris est intéressante et pertinente.  Donc, le future CEO se doit de préparer un dossier en béton, sans faille ! Et quand on parle de dossier, cela suppose le dossier papier. En effet, la qualité de ce dernier démontre le travail fournit par le porteur de projet. Lorsqu’on m’a sollicité pour une projet, on ne m’a jamais présenté un dossier, et cela me laisse vraiment perplexe quant au sérieux de le personne…

Voici ci-dessous les principaux points sur lesquels il faut répondre :

1-      Constitution de la société

L’étape de la cherche du CTO suppose que la société soit déjà créée, avec le compte bancaire et KBis associés. Ainsi, le future CEO est déjà prêt pour faire la répartition des parts, et s’est débarrassé de la paperasse. Il est étrange de s’apercevoir que beaucoup de porteur de projet n’ont pas encore créé leur startup au sens juridique.

2-      Le business plan

C'est l'un des documents principaux pour le CTO. S'il est cohérent et bien ficelé, alors il donnera de la visibilité pour le CTO, et l'aidera à mesurer les risques, par rapport au travail fournir pour la livraison du produit. Beaucoup d’ateliers ou de tutoriels existent pour rédiger ce genre de document.

3-      Le cahier des charges

Il est impossible de faire une description du produit final car il évolue en fonction du feelback des utilisateurs et il est en général enrichi. Cependant pour la V1, il est tout à fait possible de réunir un ensemble de fonctionnalités qui ensemble créée le killer feature et qui rend le produit et le positionnement de la startup intéressant. Enfin, si le CTO est bon, le CEO obtiendra le produit qui a aura été définit dans le CDC.

Sous le terme cahier des charges 3 aspects sont très importants :

a-      le design : faire un PSD, c'est 3-5 jours de travail pour un graphiste. C'est un peu d'argent, mais c'est rien par rapport à la phase du développement. Un CTO, n'est pas un graphiste et ce n'est pas son métier. Si le PSD est prêt, le CTO n'a plus qu'à l’intégrer, et cela fait gagner du temps.

b-       Définissez au mieux l'environnement du business. En effet, ce point permet simplement de déterminer l'architecture technique et logiciel ainsi que les contraintes sous-jacentes. Par exemple, dans le case study de 'mon produit va révolutionner les réseaux sociaux en Chine... ', on peut en déduire l'environnement dans lequel le produit fonctionnera :

a.       la gestion du million d'utilisateurs.

b.      sur performer la recherche de l'information de notre réseau.

c.       le contenu éditorial est faible.

d.      l'information disponible appartient aux utilisateurs...

e.      Il faut que cela fonctionne sur IE7-IE8 ...

A partir de ces points, l’architecture est définie dans les termes suivants :

f.        Il doit être scalable (plusieurs serveurs derrière un loadbalancer),

g.       une redondance des données,

h.      probablement une DB noSQL,

i.         l'impossibilité de mettre en place un proxy cache ...

Bref, un joli bordel pour le future CTO...

c-       Faire un cahier des charges fonctionnel. Si le CEO est capable de rédiger un CDC, alors cela montre parfaitement que le produit a été réfléchit (même si elle ne correspondra pas au produit final), point par point, bouton par bouton ... c’est-à-dire de manière très précis. Par conséquent, le CTO n'a plus qu'à définir le CDCT (cahier des charges techniques) et réaliser le produit. De mon point de vu, méthodes Agiles sont des méthodologies inappropriées dans le développement informatique en général. La rédaction d'un CDC possède 2 vertus importantes :

a-      se poser le temps nécessaire pour définir un bon produit, le meilleur produit

b-      quantifier la masse de travail à fournir et déterminer une deadline raisonnable (et cela est primordial pour une startup qui vie à crédit ...)

4-      Toutes informations du future CEO (Diplôme, certificat, CV , Bulletin de paie ...). De la même manière, le CTO doit avoir la même démarche, pour plus de transparence. Au premier abord, cela peut vraiment paraitre exagéré, mais il faut savoir que monter une boite avec un inconnu (même s’il y a un très bon feeling), est extrêmement risqué. Une startup, c'est 99% de galères, vaut mieux donc s'assurer que son partenaire ait les reins solides et idem pour le CTO. Avoir une personne qui a fait ses preuves dans son domaine est réellement rassurant. De plus, il faut savoir que le parcourt du porteur de projet permet d'évaluer la pertinence du projet. Une personne qui a travaillé 15 ans dans la communication, a plus de crédits si son projet concerne son domaine, que moi même qui veut ouvrir une chaine de clubs de Yoga.  Deux types de profiles CEO intéressants se semblent être pertinents parmi la tendance générales. Il y a les jeunes d’Hec, et ceux qui connaissent leur domaines d’activité depuis longtemps.

5-      Toutes informations attestant la participation (financière ou autre) d'acteurs dans le projet. Cela peut être des comptes rendu, des échanges de mails, des attestations, des documents administratifs ... Je reviendrai ultérieurement sur ce point.

L'affinité du projet avec le CTO.

Minimiser le risque et la pertinence d'un dossier ne doit pas être le seul facteur pour choisir le projet. Le CEO et CTO vont collaborer durant plusieurs années pour accoucher dans la douleur un produit, et si le produit (ou le domaine d’activité) n'intéresse pas (ou peu) le CTO, il y a alors un réel risque d'abandon de projet de la part du CTO. Malheureusement, les abandons sont très fréquents.

Le domaine d’activité ou le produit en lui-même doit permettre de susciter la curiosité du CTO en dehors des aspects purement techniques et financiers, voir même l’envie d’apprendre un nouveau métier, de rencontrer les acteurs économiques...

Etre humble et honnête face à son partenaire.

Il y a quelques mois, j'ai rencontré un porteur de projet qui voulait améliorer la notoriété de grands groupes en vendant une prestation au département communication. Même si théoriquement l'opération est viable et intéressante, je me suis permis de lui dire que les départements de communication sont les plus mal lotis, est qu'ils n'ont pas de budget pour ce genre d'opération (en gros pour être cash, il ne trouvera jamais de client).

A vrai dire, je ne sais pas si j'ai raison ou pas, mais je sais que dans une précédente expérience, un gérant d'une startup, n'a jamais trouvé de clients pour mettre en place ce type d'opération (peut être qu'il manquait d'expérience malgré son âge). Mais dans ce cas là, il faut avoir un réseau très qualifié, et que ce n'est pas à la portée de tous. Bref, au fil de la discussion, j'ai été considéré comme un simple développeur qui ne connait rien au business.

Au travers de cet exemple, 2 points sont intéressants à analyser :

a-      L'expérience de 2 personnes qui provient de mondes différents ne peut pas créer une réelle synergie par le respect des champs d'action de chacun. En effet, son collaborateur peut apporter un éclairage pertinent sur certains points dans la compréhension et sa vision de certaines problématiques. Les exemples se situent dans la reformulation du problème par son partenaire, qui n'hésite pas à titiller les faiblesses de raisonnement.

b-      Un projet ne peut se construire que si chacun fait l'effort écouter l'autre. Ce qui veut dire in fine que le projet appartient au CEO et au CTO ! Ce sont par des exemples/contre exemples et arguments/ contre arguments que le produit et le business model s'affinent. Dans le domaine technique, les développeurs/ lead développeurs / architectes qui me sollicitent pour mettre en place de nouvelles technos/ nouveaux langages, nouveaux processus de développement. Ce type de démarche est une très bonne chose car il est possible de remettre en cause des arbitrages qui aujourd’hui ne sont plus forcément pertinentes. Cependant rares sont les propositions qui sont finalement acceptées et mise en place. Pourquoi ? La réponse est simple, il faut démontrer par A+B, que la technologie est meilleure que ce qui est mise en place. Et pour qualifié la notion de 'meilleur', il faut prendre en compte (la performance, la robustesse, la maintenabilité, l'affinité du langage auprès des développeurs en interne et externe ...) Bref, il faut écrire un livre blanc, et produire un énorme travail de fond, pour qualifier la réelle pertinence d'une technologie et éventuellement l’adoptée. Dans cette situation, le fait d’être l'avocat du diable permet de sélectionner les meilleurs choix pour le projet.

L'honnêteté n’a pas encore été abordée et pourtant, elle est une qualité essentielle pour le CTO et CEO. On a tous droit à l'erreur, voir la succession d'erreurs en cascade. Par contre, la malhonnêteté même si elle se porte sur un aspect insignifiant, possède le vers destructeur de casser la confiance à jamais.

Le produit n'est pas un jouet ...

Au fil de discussion sur une possible collaboration, le CTO peut avoir l'impression que le porteur de projet n'attend qu'une chose : le produit. D'un côté c'est normal, car il doit le vendre ou le viabiliser, le monétiser... Cependant, le CTO ressent une étrange impression, cette impression que le porteur ne sera pas quoi en faire. Je rencontre quelques CTO dans les meetup, qui me font part de leur exaspérations de voir leur CEO, ne pas faire les efforts nécessaires dans son domaine. Et en général, les CEO se plaignent de la mauvaise qualité du produit, et évoque cette raison pour justifier la déroute du projet. Bref, c'est le début d'un divorce ...

De mon point de vue, ce sentiment étrange provient du manque de lucidité de la part du CEO. En effet, ces derniers sont doués pour vendre un concept, mais peu sont capable d'expliquer une stratégie commercial/marketing pour viabiliser le projet à court terme. Car finalement, si le CTO livre une version du produit et s'occupe des problématiques techniques, le CEO se doit de réussir le projet au niveau financier et commercial.

La course contre la montre, tic-tac ...

Dans un projet, il faut partir du principe que l'on peut compter uniquement que sur soi même. Qui dit soi même veut dire uniquement les associés de la startup.

Si un investisseur possède des parts dans la startup, alors, on peut compter sur lui, même s'il a décidé de ne plus mettre un rond, son aide peut se matérialiser par l'ouverture de son réseau par exemple ou sur d’autre forme.

Donc en considérant que les CEO ont en général un capital limité (un fond propre), ces derniers doivent faire le nécessaire pour commercialiser le produit avec les moyens du bord, ou maintenir une croissance constante et élevée.

Côté CTO, ce dernier doit tout mettre en œuvre pour que les coûts de développement soit les plus faibles, tout en restant robuste.

Par conséquent, les marges de manœuvres sont généralement faibles pour pondre un produit rapidement et le rendre rapidement commercial. De ce que j'observe, le meilleur couple (CEO/CTO) est composé de personnes matures, c’est-à-dire que la maturité d’une personne n'est pas proportionnelle avec son âge, mais plutôt avec sa capacité à connaitre et maitriser les moyens dont il dispose pour arriver à ses fins.

Ainsi, un développeur connaitra sera capable de déterminer la meilleur infra et architecture logiciel ainsi que les technos associées pour développer le produit. Idem pour le CEO au niveau marketing.

Au vu du contexte exposé, le temps est compté pour réussir et les marges de manœuvres sont faibles. Cependant, le succès tient en un déclic, et pour être plus précis à une succession d’améliorations minimes, permettant un décollage de l’activité. En réalité, c’est une décision (en générale anodine) qui viabilise d’un coup l’activité de la startup. Cette décision sur le business peut autant provenir d'une idée du CEO que du celle CTO, mais le succès provient du travail acharné de chacun !

Le rêve n'est pas la réalité.

Dans la section I.5, je parlais de la nécessiter de présenter, si c'est possible des documents attestant la participation d'acteurs, ou de partenaires. Alors pourquoi ? Parce que malheureusement un CEO, pour draguer un CTO, il lui vend du rêve et que un CTO a une approche pragmatique du fait de la nature de son travail. Finalement, le mieux est de lui présenter des éléments tangibles.

De nombreuses personnes se prennent pour Steeve ou Markus, et s’exclament qu’ils connaissent le directeur machin de mac do ou que mon oncle est le directeur truc d’Orange ... De plus il faut savoir qu'une rencontre débouche en générale sur pas grand chose, et surtout qu'une rencontre sur 500 mène éventuellement sur une quelque chose de concret. Accompagner ses associés pour vendre un projet à un partenaire/future associé, participer à une levée de fond sont des tâches difficiles à réaliser, et il faut être acharné pour obtenir de résultats intéressants. Il y a nulle besoin d’ajouter de la fioriture pour être crédible aux yeux des autres.

Conclusion

Si t’es donc un CTO, alors tu dois pouvoir :

-          Lire un bon gros dossier bien fournit

-          Choisir un CEO d’expérience et qui a fait ses preuves.

-          Avoir un bon feeling avec le CEO

-          Aimer le projet et le domaine d’activité.

-          Etre respectueux en vers l’autre.

-          Ne pas être considéré uniquement comme un développeur

-          Ne pas écouter les bobards

-          Se donner à 200% pour trouver le déclic