Criteo and beyond: lessons learned running tech in small and large startups

0:04 Bonjour, c'est Romain Niccoli, cofondateur et co-CEO de Pigment. Je vous retrouve tout de suite. La technologie n'est pas une fin, mais un moyen. Voilà comment Romain Nicoli, mon invité, décrit son métier. Romain Nicoli, vous êtes CTO, vous avez cofondé Criteo, qui est donc une start-up spécialiste dans le ciblage publicitaire, qui a connu l'une des plus grandes croissances en un taux record, si je ne me trompe pas. C'est exact. Lors de son introduction en bourse en 2013, vous avez levé près de 250 millions de dollars. Aujourd'hui, vous avez fait part de votre expérience à d'autres entreprises, vous n'êtes plus au sein de Criteo. Et c'est tous ces apprentissages que vous avez décidé de partager avec nous ce matin pour le Tech.Rocks Summit. Exactement, merci Elsa. Donc je vous laisse en très bonne compagnie. Bonjour à tous. Dans cette session, je vais vous expliquer comment adapter l'organisation d'une équipe engineering à la maturité de l'entreprise.

1:09 Par organisation, je ne veux pas vraiment dire organisation chart ou reporting des équipes, mais plutôt toutes les pratiques qui font la façon de travailler d'une équipe produit, d'une équipe de développement logiciel. Je vais revenir juste une seconde sur mon parcours, parce que je pense que c'est pertinent pour le propos qui va suivre. J'ai passé cinq ans au début de ma carrière chez... de Microsoft dans le développement de Windows parmi des équipes de plusieurs milliers de développeurs. Je suis ensuite revenu à Paris pour être cofondateur de Criteo, donc ça a duré 12 ans entre 2005 et fin 2016. Puis j'ai démarré une autre entreprise qui s'appelle Less, qui a duré un an et demi, qui a été réintégrée à Blablacar au bout d'un an et demi. C'était un service de transport basé sur du covoiturage instantané. Puis, depuis 18 mois, je suis cofondateur et co-CEO de Pigment, qui est un logiciel B2B de business planning pour définir son plan stratégique et suivre l'exécution. À travers ces différentes expériences, et notamment dans le cadre de Criteo, qui a vécu plusieurs phases du tout démarrage avec quelques personnes, puis la croissance, puis la maturité, je me suis forgé une conviction.

2:17 Et cette conviction, c'est qu'une organisation engineering a une date de péremption. En d'autres termes, toute organisation finit par moisir. C'est un petit peu comme de la nourriture ou le pain qu'on voit sur l'image. Il est bon au début et le même pain, la même organisation finit par ne plus être adaptée. Et il faut reconnaître quand il est temps d'en changer. Si je reviens un petit peu sur les expériences dont je parlais, je les ai classées un peu en trois catégories. Et c'est là-dessus que je vais me concentrer pour la suite. La phase de démarrage, qu'on appelle« early stage startup». La phase de croissance, puis la phase que j'appelle diversification, qui vient un peu après. Et donc, les expériences que j'ai pu avoir se classent dans ces trois catégories. Et c'est à partir de ces expériences-là que j'en ai tiré des enseignements que je vais partir. À travers toutes ces expériences-là, il faudrait toujours regarder l'efficacité de l'équipe engineering sous un angle donné, qui est l'angle de l'énergie utile, ce que j'appelle l'énergie utile, qui est en fait la proportion de l'énergie des équipes, de la puissance de travail des équipes. D'ailleurs, ça s'applique à l'équipe engineering, mais ça pourrait s'appliquer aussi à d'autres équipes commerciales et autres.

3:20 Donc, le pourcentage de cette énergie qui est vraiment aligné avec les intérêts stratégiques de l'entreprise. Donc, à chaque fois que l'énergie utile baisse, l'efficacité de l'équipe et de l'entreprise diminue. Donc tout mon propos va être de reconnaître comment maximiser l'énergie utile à différents stades de développement de l'entreprise. Je vais commencer par le premier stade que j'appelle Early Stage Startup. En fait, j'aurais pu l'appeler Startup tout court. Pour moi, une startup, c'est le stade de l'entreprise pendant lequel le modèle économique n'est pas encore établi. C'est une phase par nature d'itération. C'est une phase où on cherche le product market fit. Et en fait, ce qui est important à cette étape-là, c'est d'optimiser la vitesse d'itération. C'est-à-dire que l'équipe engineering doit être capable de délivrer très rapidement des choses, d'itérer sur le produit et de faire toutes les étapes qui permettent le plus vite possible de sortir de l'incertitude et d'arriver à ce stade où ça y est, on a un produit qui correspond à un marché, qui fonctionne et on est prêt ensuite à devenir une entreprise« normale». C'est-à-dire qu'on n'est plus vraiment une startup à ce stade-là, même si on est encore petit en termes de taille, qui va permettre de grandir.

4:22 Et donc, en termes de taille indicative de l'équipe engineering, alors il ne faut pas s'attacher tellement aux chiffres parce que ça peut varier beaucoup. Ça ne dépend pas vraiment du chiffre. Mais à titre indicatif, je considère que c'est jusqu'à une vingtaine de personnes dans l'équipe engineering. On peut fonctionner sur ce mode-là jusqu'à ce taille-là. Mais c'est surtout lié à l'état business de l'entreprise, c'est-à-dire est-ce qu'on a trouvé ce product market fit ou pas. Donc le risque ici, les façons de perdre de l'énergie utile dans ce mode-là, ça va être surtout de passer trop de temps sur les sujets, c'est-à-dire de vouloir over-engineer un produit, d'aller trop loin avant d'avoir les preuves commerciales, les preuves de clients que ça fonctionne et que c'est le bon produit. Ou c'est même le bon marché. En fait, à Criteo, on a passé trois ans finalement au départ, entre 2005 et 2008, à itérer sur le produit, sur le modèle économique, même sur le marché. Il n'y a que la technologie de départ qui n'a pas changé, mais tout ça, on a itéré pendant trois années. On peut considérer que Criteo, finalement, c'était vraiment une startup pendant trois années. Donc les pièges ici, c'est de passer trop de temps sur chaque sujet, comme je disais, de ne pas aller assez vite sur les itérations.

5:26 Il n'y a pas tellement de problèmes d'organisation à cette taille-là. Il faut voir que l'équipe est petite. Et donc le challenge, ce n'est pas tellement comment on s'organise, on communique. Ça se fait assez naturellement parce que l'entreprise est petite. D'ailleurs, c'est un avantage d'être petit. Il ne faut pas chercher à grandir trop vite. C'est beaucoup plus facile à 5 personnes qu'à 15 et qu'à 20. Même dans ce range-là, c'est plus facile quand on est petit. Il faut savoir que rajouter des personnes dans l'équipe à ce moment-là, ça a un coût assez important qui fait que tout devient plus compliqué. Donc c'est quand même assez bien d'être petit. Par ailleurs, il n'y a pas tellement de problèmes d'organisation, donc ça veut dire qu'il n'y a pas besoin d'organisation compliquée en termes de management. Donc je pense qu'à ce stade-là, l'idée c'est de rester très très flat. Donc pas tellement de managers, tout le monde se parle, tout le monde travaille ensemble. Et c'est mieux d'avoir quelques ingénieurs qui sont tous très bons, très autonomes sur leur sujet, plutôt que d'en avoir beaucoup. C'est particulièrement important à ce stade, je pense. Parmi les autres recettes que je peux partager sur cette phase 1 de la startup, l'idée c'est de faire des itérations courtes. Moi j'aime bien dire qu'on se donne des grandes releases qui sont toutes les mois, les deux mois ou les trois mois, peu importe ce qui va marcher pour vous.

6:33 Et à l'intérieur de ces releases-là, où on a un objectif produit, un objectif business assez clair, se poser la question, qu'est-ce qu'on va prouver avec cette release-là? Pourquoi on l'a fait? Quelle est la question à laquelle on cherche à répondre en la sortant? On n'est pas tellement au stade où les clients vont nous demander des features, on est plutôt au stade où on va valider que le concept tout court a du sens et va fonctionner sur le marché. On ne veut pas tellement d'overhead, donc pas tellement de pratiques compliquées, de process, d'engineering. Il y a un site assez rigolo que je vous conseille de regarder. Désolé pour le terme un peu grossier, mais qui s'appelle Programming Motherfucker. Vous trouverez ça sur Google tout seul. C'est à moitié ironique, à moitié sérieux. Ça prend un peu le contre-pied des méthodes agiles habituelles, du Scrum, du Kanban. En fait, ça fait surtout le contre-pied de l'agile poussé à l'extrême dans les process, alors que le but, c'est surtout d'être efficace et de revenir au basique. Je vous conseille d'aller regarder. Dans les recettes que j'aime bien appliquer aussi, c'est un channel Slack ou n'importe quel autre outil par sujet pour que tout le monde ait l'information. Je pense que ce qui est important d'optimiser à ce moment-là, c'est la circulation de l'information et l'alignement entre toutes les personnes de l'entreprise, entre le business, le produit, le dev, pour être sûr que tout le monde travaille sur les bons sujets le plus vite possible sans en faire trop.

7:44 Et pour être sûr qu'on n'en fait pas trop, on aime bien à chaque fois qu'on démarre un projet, un sujet, donc ça va être pour un travail qui va durer une semaine, deux semaines, trois semaines, j'aime bien faire un kick-off, c'est-à-dire un lancement du projet dans lequel les ingés qui ont travaillé sur le sujet ont des bruits. et propose, avant de commencer à coder, un petit lancement sur lequel ils vont partager tous les points importants, ce qu'il faut améliorer, les choix techniques, les dépendances, et dans lequel tout le monde a l'opportunité de contribuer. C'est le moment où on utilise le cerveau collectif. Et la clé dans ce meeting-là, c'est de simplifier, c'est-à-dire de réduire les fonctionnalités produits, de réduire les designs techniques pour aller toujours faire une itération plus rapide que ce qu'on avait en tête. C'est ça qui permet d'aller très très vite. Et bien sûr, faire circuler l'information dans l'équipe, donc des revues de code, des jeux de tests, pas trop surdimensionnés, mais juste ce qu'il faut pour ne pas perdre du temps à chaque fois parce que tout est cassé en permanence. Et puis une coordination avec les équipes business, donc les EOLENS toutes les semaines, où on explique où on en est, ce qu'on va faire et pourquoi on le fait, pour que tout le monde soit sur la même longueur d'onde.

8:44 Je pense que c'est particulièrement important. Et donc dans ce mode-là, on a vu Gavus. Finalement, l'image que j'ai en tête, c'est un petit bonhomme de jeux vidéo avec sa lampe torche qui éclaire le terrain, qui est tout noir au début. Puis au fur et à mesure qu'on avance, le terrain s'éclaire et on comprend où on est et ce qui va marcher et quel est le produit qui va fonctionner. Donc ça, c'est le stade 1. On sort de ce stade quand on a trouvé un produit qui fonctionne, on a des preuves commerciales que ça marche et on est capable après de grandir. Dans le cas de Criteo, c'est quelque chose qui a commencé en 2008 avec le produit publicitaire. Et là, les règles du jeu changent. Ce qui est important pour l'entreprise, ce n'est plus la même chose. Dans cette phase-là, je situe en termes d'équipe engineering entre 20 et 100 personnes à peu près, le besoin principal, ce n'est plus d'itérer rapidement et de sortir des nouvelles choses pour... lever les incertitudes, c'est de grandir. C'est la capacité à faire travailler plus de personnes en même temps sur le même sujet et de maximiser l'opportunité qu'on a trouvée. D'ailleurs, on n'est plus en train d'en chercher d'autres, on est en train d'essayer de maximiser l'opportunité et de grandir le plus vite possible. Et donc, ce que l'équipe engineering doit optimiser, les caractéristiques d'une bonne organisation, c'est la capacité à faire travailler efficacement plus de monde en même temps sur un sujet donné.

9:51 Donc ça, c'est une phase de croissance qui peut durer très très longtemps. Et la perte d'énergie utile, pour revenir à ce concept, les sources possibles. de perte d'énergie utile dans ce cas-là, ça va être des raisons intrinsèques à l'organisation de l'équipe engineering, d'efficacité de l'équipe et de ne pas arriver à faire travailler plus de monde en même temps. En fait, ce qui se passe, c'est quand on fait travailler plus d'ingénieurs en même temps sur un sujet, des problèmes de communication, d'organisation surgissent qu'on n'avait pas quand on était au stade 1 de la startup. Tout devient plus compliqué, les gens ne sont plus sur la même longueur d'onde, ne sont pas au courant des projets des autres. On voit survenir tous ces problèmes qui sont des problèmes de croissance. Et donc, quelles sont les recettes pour essayer de naviguer dans cette phase-là? J'en partage quelques-unes, mais en fait, ça commence par le recrutement. Et pour moi, c'est un peu la clé de tout le reste. C'est-à-dire de recruter des ingénieurs qui soient d'un niveau excellent et de monter la barre de recrutement au fur et à mesure de la croissance de l'entreprise. C'est peut-être contre-intuitif, on pourrait dire qu'au fur et à mesure, on peut recruter des gens peut-être un peu moins bons. En fait, c'est le contraire. Il faut recruter des gens qui soient de plus en plus doués sur leur sujet.

10:52 Et pourquoi? Donc ça, c'est un concept qui a été introduit par Netflix depuis assez longtemps. Il y a une fameuse présentation que vous devez connaître tous sur la culture d'entreprise qui s'appelait« Responsabilité et liberté». Et en fait, ils expliquent bien que quand le nombre de personnes augmente dans l'entreprise, la courbe de complexité augmente, puisque c'est plus difficile de faire travailler des gens ensemble. Et donc, si on ne fait pas quelque chose, le chaos apparaît. Finalement, on n'arrive plus à fonctionner. Et donc, il y a deux façons de résoudre ce problème. La première, c'est d'être tenté par rajouter des process. Et de se dire, il y a des gens qui font des erreurs, il y a des choses qui n'étaient pas réglées, donc je vais codifier tout ça, je vais mettre des règles, les gens vont les appliquer. Tout ira bien. Et le pire, c'est que ça marche. C'est-à-dire que ça marche, mais ça marche temporairement. Et ce qui se passe, c'est que les niveaux de liberté, d'autonomie des gens baissent, puisque tout est codifié. Et donc les gens les plus talentueux finissent par partir. Ceux qui étaient juste après en termes de niveau finissent par partir aussi, puisque leur motivation c'était de travailler avec les plus talentueux. Et on finit avec une entreprise qui sait très bien exécuter une chose, mais qui sera incapable de s'adapter par la suite. Et donc ce n'est pas la solution.

11:52 La solution, c'est plutôt de monter cette barre de recrutement et de faire confiance à l'intelligence des gens qu'on a recrutés. Et en fait, de tolérer les erreurs. C'est-à-dire finalement, ce n'est pas grave, il y aura des erreurs, mais finalement, quand on embauche des gens brillants, c'est plus facile de corriger les erreurs que d'éviter leur apparition. Et en fait, ça coûte moins cher. Et de faire confiance au talent des gens pour régler ces problèmes-là de croissance. Donc ça, c'est la clé. Donc ce qui va avec, c'est donner, une fois qu'on a embauché ces personnes-là, de leur donner l'autonomie. Donc un grand principe que je pousse, moi, de ce stade de croissance-là, c'est l'autonomie des équipes, ou le terme de empowerment qu'on utilise en anglais, qui est toujours très difficile à traduire en français, qui est un mélange de liberté, d'autonomie et de responsabilité. Et donc pour avoir ça, pour moi la clé c'est deux choses. C'est le contexte, c'est-à-dire expliquer pourquoi on fait les choses, et expliquer où on veut arriver, mais ne surtout pas expliquer aux gens comment faire les choses. Ça c'est leur travail, et si on embauche les bonnes personnes, ils arriveront à le faire tout seuls. Donc il y a différentes recettes pour ça. Un outil qu'on aime bien utiliser, qui résout aussi le problème de communication, c'est ce qu'on appelle les OKR, Objectives and Key Results, qui consistent...

13:00 périodiquement, donc tous les trimestres par exemple, à définir des grands objectifs et des mesures de succès, c'est-à-dire comment on sait qu'on a réussi. Et chaque équipe définit ses objectifs et les publie, ce qui permet à chacun de savoir ce que fait tout le monde. Pour voir qu'au stade 2, on ne peut plus communiquer autant qu'on faisait au stade 1 sur tout et n'importe quoi. Autant dans le stade 1, on pouvait être aligné sur tout et tout le monde a une connaissance totale de tout ce qui se passe dans l'entreprise, autant au stade 2, ça devient contre-productif parce qu'il y a une surabondance d'informations et ce n'est plus possible de traiter toute cette information. Il faut choisir ses batailles. Et donc le ZKR, c'est un bon moyen de savoir un peu ce qui se fait à différentes parties de l'entreprise et de choisir dans quel sujet on veut s'impliquer plus. Donc c'est un point d'entrée, c'est un pointeur. Ce qui est important aussi, c'est de réduire la complexité. En fait, ce qu'elle est un produit, c'est mieux que dans ce qu'elle est trois ou quatre en même temps. Ça, ça a été dit aussi par des grands incubateurs américains. Quand on est dans cette phase-là où on a trouvé une opportunité, c'est mieux de l'exploiter jusqu'au bout et de se concentrer sur une chose plutôt que d'essayer de se diversifier trop tôt. Donc la phase de diversification, il ne faut pas qu'elle vienne trop tôt. En fait, il y a beaucoup d'entreprises qui peuvent rester en cette phase 2 de croissance pendant très très longtemps.

14:04 Et on a toujours beaucoup plus de facilité à croître quand on reste sur un marché et qu'on l'exploite complètement, quand on devient le leader d'un domaine, plutôt que d'essayer de faire trop de choses en même temps et d'être moyen sur tout. Donc c'est important à chaque fois qu'on développe un feature, qu'on s'attaque à quelque chose, de simplifier encore pour aller à l'essentiel, d'enlever tout ce qui n'est pas stratégique. Tous les features qui n'ont pas très bien marché, qu'on a introduits, il faut savoir les découper au fur et à mesure. Il faut savoir aussi que grandir a un coût. C'est-à-dire que ça, Simplement le fait d'avoir plus de clients, parfois, ça demande beaucoup de ressources engineering. Donc on n'est même pas tellement en train de parler de rajouter des fonctionnalités, mais on est en train de réécrire celles qu'on a déjà faites pour que ça puisse s'adapter à plus de clients, à des clients plus grands, à des problématiques nouvelles. Donc ça, c'est important de le savoir, parce qu'on peut s'enfermer dans beaucoup de features et puis avoir une dette technique colossale qui fait qu'on n'arrive plus à grandir. En termes d'organisation de l'équipe, le concept pour quoi un clé, c'est de baser sur l'autonomie des gens, c'est d'avoir des cellules qui soient autonomes sur des sujets. C'est divisé pour mieux régner, donc sur un sujet fonctionnel, d'arriver à avoir tous les talents réunis pour travailler ensemble et avancer comme si c'était une mini-entreprise sur un sujet pour essayer de réduire cette complexité globale.

15:12 Et puis, un truc important, c'est d'encourager le changement. Je disais, toute organisation en Moisy, alors c'est peut-être parce qu'elle n'est pas adaptée au stade de l'entreprise, mais en soi, si les gens ne changent pas et travaillent toujours sur les mêmes choses, c'est un problème qui fait que les gens vont partir. Et donc, quand quelqu'un vient vous voir en tant que CTO, vous dit, bon, ça m'est arrivé plusieurs fois, Romain, c'était super, qui était, oh, j'ai fait plein de trucs, mais là, je commence à m'ennuyer un peu, donc je vais partir dans telle ou telle entreprise. Alors, on se dit, ah, mais attends, c'est dommage, il y a plein d'autres choses que tu aurais pu faire, regarde toutes ces autres équipes, et en fait, la personne me dit, ah, c'est vrai, t'as raison, mais oui, c'est dommage qu'on n'avait pas parlé avant, parce que là, maintenant, c'est trop tard. Et donc, en fait, encourager la mobilité entre les équipes, ça résout plein de problèmes. Ça permet de garder les gens plus longtemps, de les garder intéressés, ça permet de les développer, ça permet d'éviter les querelles entre équipes et les querelles de clochers. Et donc là-dedans, il y a plusieurs recettes, c'est-à-dire déjà ne pas bloquer la mobilité, c'est-à-dire quand quelqu'un veut changer d'équipe, ça doit toujours être autorisé. C'est un peu paradoxal que dans beaucoup d'entreprises, il faut l'autorisation de son manager avant de pouvoir changer de job, alors que quand on quitte l'entreprise, on n'a pas besoin de l'autorisation de son manager. Donc ne pas mettre de bâton dans les roues, je dirais que ça ne va pas assez loin, il faut aller plus loin que ça, et il faut être capable d'encourager l'échange et de baisser la barre pour que les gens puissent changer de job dans l'entreprise.

16:20 Et notamment, une recette qu'on a appliquée à Criteo, ce qu'on appelait le voyageur, qui est en fait un espèce de stage interne qu'on propose entre les équipes et qui permet d'aller essayer une autre équipe pendant quelques semaines. avant de savoir si finalement on veut changer ou pas. Et dans tous les cas, c'est un peu un vie-ma-vie et qui permet de mieux comprendre les autres. Et puis par ailleurs, pour finir sur les recettes du stade 2, c'est les outils, tout un outillage de haut niveau. C'est important d'investir sur tout ce qui est intégration continue, outils de test, outils de test après mise en prod, etc. Puisque le temps perdu à ne pas avoir ces outils est colossal et supplante largement le temps qu'on aura mis à les mettre en place. Donc ça, c'est les recettes du stade 2, la phase de croissance. Et puis, il y a un moment où on sort un petit peu de ce stade 2. Et là, les signaux de ça, c'est des signaux business à nouveau. C'est en taille d'équipe, engineering indicative, je considère que c'est au-delà de 100 personnes à peu près. Mais à nouveau, ce n'est pas le chiffre qui est important, c'est plutôt l'état de l'entreprise. Où on sent que le produit sur lequel on a maximisé l'opportunité, la croissance commence à se tarir, on est un petit peu au bout du chemin, il y a encore de la croissance mais il n'y en a plus autant qu'avant,

17:24 il y a besoin de nouveaux produits, et peut-être qu'il y a besoin de nouveaux produits aussi parce que l'écosystème a changé, vous pouvez lire le dilemme de l'innovateur pour comprendre aussi pourquoi, et donc il y a besoin de changer les produits sur lesquels on travaille. Et là ce qui se passe c'est qu'il faut changer de mode. Les symptômes aussi c'est que vous allez entendre des gens qui vont dire c'était mieux avant, on a perdu l'agilité de la start-up, donc ça c'est un peu tous les signaux qu'on en est à ce niveau là donc là les raisons pour lesquelles l'énergie utile peut baisser sont un peu trois natures alors évidemment la première c'est que le stade 2 a déjà foiré c'est à dire qu'on n'a pas bien géré la croissance au stade 2 on n'a pas mis en place les bonnes recettes pour bien faire grandir la taille de l'équipe on a des problèmes d'organisation intrinsèques donc ça n'aidera pas pour la phase de diversification, ça c'est clair. Mais au-delà de ça, l'organisation du stade 2 n'est plus adaptée à ce stade 3 de diversification. Pourquoi? Parce que quand on développe ces nouveaux produits, on est à nouveau dans une phase d'itération où on cherche un product market fit sur des nouveaux produits. Donc il faut revenir sur un mode où on itère très vite, et ce n'est pas la capacité à faire bosser beaucoup de travail, beaucoup de personnes sur le même sujet qui compte, c'est la capacité à itérer très vite sur des nouveaux sujets, et potentiellement plusieurs nouveaux sujets en parallèle.

18:25 Donc il faut revenir finalement sur une organisation de stade 1 pour certains sujets. Le stade 3, finalement, c'est la superposition du stade 2 et du stade 1 en même temps. Et une autre source importante pour moi de perte d'énergie utile, c'est le fait que trop de personnes travaillent sur des sujets qui sont devenus non essentiels. Et ça, je pense que c'est un énorme problème dans plein d'entreprises qui ont grandi. C'est qu'on a créé des équipes sur différents sujets qui étaient utiles pendant la phase de croissance. Et l'utilité de ces équipes-là et de ce travail-là a vécu. C'est-à-dire qu'il y a beaucoup de choses qui sont devenues good enough. On n'en a plus spécialement besoin pour grandir, mais on continue à travailler dessus un peu par habitude, parce qu'on continue sur la lancée sur laquelle on était. Et on ne dévoue pas assez d'énergie à ces nouveaux projets, à ces itérations courtes. Et donc ça, c'était une des motivations pour moi de démarrer Pigment, qui est ma nouvelle entreprise, qui développe ce logiciel de planning. C'était finalement comment trouver la technologie ou les outils qui permettent de mieux gérer l'alignement stratégique entre les besoins à business de l'entreprise et l'énergie de tout le monde dans l'entreprise.

19:26 C'est un outil de planification et de suivi d'exécution. Cette motivation date de cette époque. qui est post-introduction en bourse, écrit Théo, à partir de 2013, où on avait besoin de sortir des nouveaux sujets. On s'est aperçu que c'était assez difficile et qu'il fallait faire des choses pour y arriver. Donc les recettes qui permettent dans cette phase 3 pour moi d'y arriver, c'est rajouter quelque chose à l'élément indispensable du stade 2 qui était l'empowerment. Et cet ingrédient supplémentaire, c'est la transparence. C'est-à-dire que c'est très bien de faire confiance aux gens et de faire confiance à leur intelligence pour définir les sujets sur lesquels ils vont travailler. et comment ils vont le faire, et définir l'agenda. Mais il y a un besoin de transparence, que chacun sache sur quoi travaille chacun, pour être capable de réajuster et de s'apercevoir qu'un projet qui était utile à un moment donné n'est plus utile. Dans d'autres termes, la perte d'énergie, ce n'est pas tellement qu'on fait mal des choses, qui était le risque du stade 2, c'est qu'on travaille sur les mauvais sujets. La transparence permet de corriger ce manque d'alignement, et pour moi, c'est le truc le plus important. Et donc, être capable de mettre des organisations différentes en parallèle sur la même entreprise, avec des gens qui travaillent sur la continuité de la croissance

20:32 du produit principal, qui continuent à appliquer les mêmes recettes, et faire des équipes un peu dédiées, qui sont des start-up dans l'entreprise, qui permettent d'itérer très rapidement sur les nouveaux sujets. C'est quelque chose qui est assez difficile et je pense que ça demande beaucoup de courage du CTO ou des tech leaders à ce stade-là, parce qu'il y aura énormément de résistance dans l'entreprise. On a construit une culture, on a construit une façon de travailler, et il faut reconnaître qu'elle n'est plus adaptée et qu'il faut changer. Donc c'est quelque chose qui est assez dur, il faut vaincre le changement, et là ça va être un peu l'objectif principal du tech leader, la résistance au changement, ça va être l'objectif principal à ce stade-là. Voilà. Donc ça, c'était pour la phase 3. Donc en conclusion, les takeaways pour moi, c'est d'une part, j'ai essayé de vous montrer dans cette présentation que maximiser le pourcentage d'énergie utile, c'est-à-dire l'alignement de la capacité de travail de l'équipe aux objectifs de l'entreprise, c'était quelque chose d'important et que ça dépendait, la façon de le faire dépendait du stade de maturité de l'entreprise, entre la startup early stage, la phase de croissance, la phase de croissance. de diversification. Et je voudrais conclure par un appel à tous les tech leaders qui regardent cette présentation.

21:36 Et cet appel, c'est soyez Shiva. Alors Shiva, il est sur le slide. Pourquoi? Parce que c'est ce dieu indien de la destruction, mais de la destruction positive, c'est-à-dire de la déconstruction pour reconstruire. Et ça, c'est quelque chose d'important, je pense, dans les équipes engineering. Donc pour être un peu provocateur, je dirais ne soyez pas des constructeurs, soyez des déconstructeurs pour mieux reconstruire quelque chose qui vous permettra de rester agile. Merci à tous. Merci beaucoup Romain, on va essayer de ne pas être des constructeurs complètement non plus ce matin. Ce qui est important, on l'a compris avec votre présentation, c'est cette histoire de l'ego, donc de séquencer aussi les différentes phases pour être adaptable dans l'entreprise. Alors j'aimerais qu'on sorte un peu de ce rôle-là de CTO et qu'on parle un peu plus de vous sous l'angle d'investisseur, parce que vous êtes aussi investisseur aujourd'hui. Est-ce que la technologie, quand vous regardez des dossiers de start-up qui arrivent vers vous, c'est un élément clé? Est-ce que c'est ce vers quoi vous allez aller? Ou est-ce que vous allez aller plus vers un entrepreneur qui va avoir un peu le même discours que celui que vous avez, une sorte de vista des différentes phases de développement de son entreprise? Alors effectivement, je suis business angel depuis quelques années. J'ai eu à faire une quinzaine à vingtaine d'investissements dans des startups.

22:40 Je ne tiens pas le compte exact, à vrai dire. Ce n'est pas une activité professionnelle pour moi. Je la fais en mode amateur sur des projets sur lesquels j'ai des coups de cœur ou des gens qui viennent me solliciter. La technologie, là-dedans, il y a plusieurs réponses. C'est-à-dire que j'aime bien investir dans des choses que je connais un petit peu. C'est-à-dire que si c'est un domaine sur lequel je n'y connais absolument rien, je n'aurai pas beaucoup de valeur. Il faut voir qu'un business angel, il faut voir qu'un business angel, C'est quelqu'un qui met de l'argent, mais surtout quelqu'un qui s'implique personnellement, qui va aider, qui va suivre. C'est pour ça que je le fais, d'ailleurs. C'est pour ça que j'aime bien rendre un peu à l'écosystème et faire partager mon expérience, et puis rencontrer des gens passionnants, brillants, qui me challengent aussi moi-même sur ce que je fais dans mon entreprise. Et donc, naturellement, ça va être des sociétés technologiques, puisque c'est ce que je connais. Comme on disait au départ, pour moi, la technologie, ce n'est pas une fin en soi. Et quand ça devient une fin en soi et que les ingénieurs font des choses pour le plaisir ou pour publier sur un blog technique et que ça devient une fin en soi, ça devient toxique. Je pense que c'est toujours au service d'un produit, au service d'une aventure entrepreneuriale et d'un business. Et donc, même en essayant de faire simple et en essayant de simplifier au maximum, on finit toujours par avoir des choses compliquées à faire d'un point de vue technologique.

23:43 Donc je regarde effectivement des sociétés technologiques, mais à chaque fois au service d'un objectif qui n'est pas purement technologique. Alors je crois que vous avez compris, si vous avez des dossiers de start-up à envoyer, vous voyez à peu près comment il faut les dimensionner pour les faire passer à Romain. Et j'en profite pour vous rappeler que vous avez tout de suite une session de questions-réponses avec Romain justement. A bientôt Romain! Merci Elsa, à bientôt!