Apprendre aux ingénieurs à penser comme des fondateurs

Chaque année à Harbour.Space University à Barcelone, je me tiens devant une salle d'étudiants en développement et data science et je leur dis quelque chose qu'ils ne veulent pas entendre : être un excellent codeur ne suffit pas. Pas si tu veux construire des choses qui comptent. Pas si tu veux diriger.

J'ai créé le module "Developer to CTO" pour combler le fossé entre ce que les formations en ingénierie enseignent et ce que l'industrie exige réellement. Le module se déroule en format intensif quotidien. On couvre la gestion de projet, le design de systèmes, la stratégie business et la construction de ventures. Les étudiants forment des équipes et construisent de vrais projets de zéro pendant le cours.

Voici ce que j'ai appris en l'enseignant.

La première surprise : personne ne t'apprend à dire non

Le premier exercice que je donne aux étudiants est simple. Je leur remets un brief produit avec quinze fonctionnalités et je leur dis qu'ils ont le budget pour en construire trois. Ils doivent choisir lesquelles et expliquer pourquoi.

Presque toutes les équipes galèrent avec ça. Ils ont passé des années dans des environnements où l'objectif est de résoudre chaque problème, réussir chaque test, implémenter chaque exigence. L'idée de délibérément laisser des fonctionnalités de côté leur semble fausse.

Mais c'est la compétence la plus importante pour un leader technique. Chez Cantoo, on a atteint la rentabilité précisément parce qu'on a dit non aux fonctionnalités qui ne généraient pas directement de revenus. On aurait pu construire un beau dashboard. On aurait pu ajouter de l'analytics. On aurait pu supporter plus de protocoles. Au lieu de ça, on a construit un moteur de routage voix, un système de facturation et une API. C'était tout. Et c'était suffisant.

Les étudiants sont choqués quand je leur dis que dire non à une bonne idée est plus difficile et plus précieux que dire oui. À la fin du module, ils comprennent.

Les business models avant le code

Je commence le module par les business models, pas par les diagrammes d'architecture. Ça déroute les étudiants au départ. Ils se sont inscrits pour un cours technique. Pourquoi on parle d'unit economics ?

Parce que chaque décision d'architecture est in fine une décision business. Le choix entre un monolithe et des microservices n'est pas seulement technique. Il détermine à quelle vitesse tu peux livrer, combien d'ingénieurs tu as besoin et combien coûte ton infrastructure. Si tu ne comprends pas le contexte business, tu vas optimiser pour la mauvaise chose.

Je leur fais parcourir des exemples réels. Chez OneRagtime, on a construit trois produits séparés (Platform, Core, Deepdive) parce que le business VC avait trois groupes d'utilisateurs distincts avec des besoins et des patterns d'usage différents. Un seul monolithe aurait été plus simple à construire mais impossible à faire évoluer indépendamment. L'architecture suivait le business, pas l'inverse.

Chez Cantoo, on a choisi une approche monolithique au départ parce qu'on était deux et qu'on devait livrer vite. Le contexte business exigeait la vitesse plutôt que l'élégance. On a refactorisé plus tard quand le business a grandi.

Les étudiants qui comprennent ça deviennent de meilleurs architectes. Ils ne choisissent pas les technologies parce qu'elles sont intéressantes. Ils les choisissent parce qu'elles servent le business.

La simulation d'équipe

La partie la plus transformatrice du module est le projet de venture. Les étudiants forment des équipes de quatre ou cinq et doivent construire quelque chose de réel. Pas un prototype. Pas une maquette. Un produit fonctionnel avec un business model, un marché cible et un plan de pérennité.

J'ai regardé des codeurs individuels brillants s'effondrer complètement dans cet exercice. Ils veulent écrire tout le code eux-mêmes. Ils résistent à la délégation. Ils passent trois jours à perfectionner une fonctionnalité que personne n'a demandée pendant que le produit principal reste inachevé.

C'est exactement ce qui arrive aux managers d'ingénierie débutants dans le monde réel. La transition de contributeur individuel à leader est douloureuse parce qu'elle exige de lâcher ce qui faisait ton succès.

Je dis à mes étudiants : ton job n'est plus d'écrire le meilleur code. Ton job est de t'assurer que le meilleur code est écrit. C'est une compétence fondamentalement différente.

Ce qui surprend le plus les étudiants

Trois choses surprennent systématiquement les étudiants.

La conscience des coûts. La plupart des étudiants n'ont jamais pensé à combien coûtent leurs décisions techniques. Quand je leur montre la facture AWS d'une vraie startup et que j'explique comment les choix d'architecture impactent directement le burn rate, quelque chose se déclenche. D'un coup, ce microservice supplémentaire ou cette fonctionnalité temps réel n'est plus seulement une décision technique. C'est une décision financière.

Le fossé de communication. Les étudiants découvrent qu'expliquer une décision technique à un interlocuteur non-technique est réellement difficile. Je les fais présenter leurs choix d'architecture comme si j'étais un investisseur. Aucun jargon autorisé. Si tu ne peux pas expliquer pourquoi tu as choisi PostgreSQL plutôt que MongoDB en termes qu'un business comprend, tu n'as probablement pas suffisamment réfléchi au sujet.

Livrer bat la perfection. Je donne des délais serrés volontairement. Les équipes qui passent trop de temps sur l'architecture ne terminent jamais. Les équipes qui livrent quelque chose d'imparfait et itèrent produisent toujours de meilleurs résultats. Ça reflète ce que j'ai vu dans chaque startup que j'ai construite ou conseillée. Les équipes qui gagnent sont celles qui mettent quelque chose entre les mains des utilisateurs le plus vite, puis l'améliorent sur la base de vrais retours.

L'état d'esprit fondateur

Le module s'appelle "Developer to CTO", mais ce que j'enseigne vraiment, c'est l'état d'esprit fondateur. Tout le monde ne créera pas une entreprise. Mais tout le monde gagne à penser comme quelqu'un qui doit livrer un produit, servir des clients, gérer les coûts et faire grandir une équipe.

Chez Kamina.io, mon studio de consulting, je travaille avec plus de 40 équipes à travers l'Europe. Les ingénieurs qui se démarquent ne sont jamais ceux avec les connaissances techniques les plus profondes. Ce sont ceux qui comprennent pourquoi ils construisent ce qu'ils construisent. Ils posent des questions sur l'utilisateur. Ils poussent contre les exigences qui n'ont pas de sens. Ils pensent à la maintenabilité parce qu'ils savent que quelqu'un, peut-être eux, devra vivre avec ce code pendant des années.

C'est ce que j'essaie d'inculquer à mes étudiants. La compétence technique est le socle. C'est ce qui te fait entrer dans la pièce. Ce qui détermine ta trajectoire ensuite, c'est ta capacité à penser au-delà du code.

La leçon la plus dure

La leçon la plus dure que j'enseigne concerne les compromis. Pas les compromis techniques, ceux-là sont relativement simples, mais les compromis humains.

En tant que CTO, tu prendras des décisions qui frustrent ton équipe. Tu choisiras la solution ennuyeuse et fiable plutôt que la nouvelle excitante. Tu donneras la priorité au remboursement de la dette technique plutôt qu'à la fonctionnalité que ton meilleur ingénieur veut passionnément construire. Tu diras non à quelqu'un que tu respectes parce que le business a besoin d'autre chose maintenant.

J'étais CTO chez OneRagtime, gérant une équipe à Barcelone pendant que le business opérait à travers l'Europe. Je devais décider ce qu'on construisait, ce qu'on reportait et ce qu'on tuait complètement. Ces décisions n'étaient jamais purement techniques. Elles impliquaient des personnes, des attentes et des relations.

Les étudiants s'attendent à ce que le rôle de CTO soit de prendre les grandes décisions techniques. C'est le cas, en partie. Mais c'est surtout prendre les décisions que personne d'autre ne veut prendre, et les prendre d'une manière qui garde l'équipe motivée et alignée.

Pourquoi je continue d'enseigner

Je continue d'enseigner parce que ça me rend meilleur dans mon travail quotidien. Chaque cohorte d'étudiants me force à réexaminer mes hypothèses. Ils posent des questions que je n'avais pas envisagées. Ils remettent en cause des schémas que je tenais pour acquis.

Chez Consentio, je dirige une équipe de dix ingénieurs. Les cadres que j'utilise pour expliquer des concepts aux étudiants sont les mêmes que j'utilise pour aligner mon équipe sur la direction technique. Si j'arrive à faire comprendre à un étudiant de 22 ans à Barcelone pourquoi on architecture les systèmes d'une certaine façon, je peux le faire comprendre à n'importe qui.

Enseigner est la meilleure boucle de feedback que j'ai trouvée. Ça force la clarté. Et la clarté est la compétence la plus sous-estimée dans le leadership engineering.