S01E02 · Hypercroissance, feature teams et exigence de recrutement

0:03 Parole de Tech Leaders, le podcast Tech.Rocks qui donne la parole aux Tech Leaders. Tech.Rocks, la communauté qui rassemble, connecte et valorise les tech leaders d'aujourd'hui et de demain. Bonjour, je suis Hervé Lourdin, CTO et co-directeur de VideDressing, et j'ai l'honneur aujourd'hui de recevoir Nicolas Denayer, VP of Engineering de Doctolib, pour cette interview de Parole de Tech Leader. Bonjour Nicolas. Bonjour Hervé. Et donc, bien sûr, Nicolas Donneher, VP of Engineering à Doctolib, depuis 4 ans maintenant. Je te propose de commencer par les formalités d'usage. On va retracer un petit peu ton parcours. L'idée, c'est que tu nous racontes les différentes étapes qui t'ont amené progressivement au job de VP of Engineering chez Doctolib. Raconte-nous ça un petit peu. Ok, du coup ingénieur avant tout, j'ai commencé par ça en Bretagne et je suis arrivé par les pages jaunes en 2009 sur Paris. Là-bas j'y ai surtout découvert Octo Technologies, une société que tu connais je crois.

1:07 Et donc je travaillais en tant que tech lead chez les pages jaunes et là-bas il y avait Octo Technologies qui faisait du conseil. Donc du coup c'est là en fait j'ai vraiment pris des G sur la partie un peu agile j'ai fait des belles rencontres et en sortie de cette mission j'ai eu le choix d'intégrer les pas jaunes ou un peu de faire un reset dans ma carrière et d'aller chez Octo Technologies c'est ce que j'ai choisi Je pense que c'était un très bon choix. J'y suis resté trois ans, j'ai fait plein de missions, plein de rencontres, j'ai appris énormément de choses sur tout ce qui va être méthode, management et aussi tech. Et donc, là-bas, j'y étais architecte J2E, coach agile, tech lead. De ça, la dernière mission que j'ai faite, c'était d'aller chez Viadeo. Donc là, c'était de faire une transformation à grande échelle de Viadeo avec un certain Hervé Lourdin. C'est une mission qui s'est très bien passée. Il y avait une centaine de personnes à l'IT et c'était vraiment transformer les équipes, les mettre en feature team, ce genre de choses qui étaient assez neuves à l'époque. Et de ça, Viadeo m'a débauché pour aller reprendre le bureau qui était à San Francisco, qui est un bureau très technique, mais un petit peu les irrésistibles gaulois.

2:17 Et donc du coup, eux, ils étaient un peu moins organisés en feature team, moins avec les mêmes pratiques. Et ma mission là-bas, c'était de casser un peu ce modèle purement technique pour aller vers quelque chose d'un peu plus fonctionnel et user-centric. Je rebondis justement sur ces expériences que tu nous décris Nicolas, je pense qu'il y a un moment un peu intéressant dans ton parcours, dans les étapes de ton parcours. Qu'est-ce qui fait que tu as basculé du conseil vers un job de leader technique dans les entreprises, notamment après Viadeo finalement? Je pense que c'est un point d'appui intéressant dans ton histoire, tu peux nous raconter un peu ça? Oui, clairement, le côté conseil, je pense que c'est une super école. On passe du coq à l'âne tous les jours. trois mois, on a des missions qui s'enchaînent, on voit plein de contextes différents, des technos différents, des personnes différentes, des directions différentes. Donc ça, c'est vraiment génial, c'est une très bonne école. Par contre, déjà, et d'une, c'est usant. On arrive, on doit être impactant en quelques jours, etc. Donc il y a le côté un peu épuisant et puis le côté vraiment frustrant c'est qu'on arrive, on essaie d'induire de gros changements et on sent que ça a à peine pris, qu'on doit déjà aller sur une autre mission et on n'a pas le temps de s'assurer que ce soit vraiment en place et rentrer dans l'ADN.

3:33 Donc c'est la volonté de pouvoir un peu s'assurer que le changement prenne bien jusqu'à la moelle dans les autres entreprises. Alors du coup, après Viadeo à San Francisco? Donc en gros, à San Francisco, j'étais quand même pas mal. Il y avait le surf et le soleil. Mais en fait, c'est un peu Yvan et Jessie qui m'ont recontacté. Mafia Octo Technologies, toujours. Et ils avaient un projet qui était connu, mais pas encore très connu à l'époque, qui était Doctolib. Le problème de ça, c'était de revenir un peu sous la grisaille parisienne. Mais pour connaître un petit peu Yvan et Jessie, j'avais vraiment envie d'aller travailler avec eux. Je savais que c'était des personnes qui pouvaient être très impactantes. Et surtout, je savais que j'étais assez complémentaire. J'ai eu un petit peu peur, puisque clairement, c'était arrivé dans un contexte où il y avait une startup qui était déjà assez établie. Mais surtout, il y avait déjà deux CTO. Donc, ça veut dire quoi d'arriver VP Engineering dans un environnement où il y a déjà deux CTO? Ce qui m'a rassuré, c'est que je... connaissais un petit peu ces personnes-là et je savais que j'étais complémentaire.

4:34 Cool. On va du coup creuser un petit peu plus en détail ton rôle de tech lead au sein de Doctolib. Avant de rentrer dans le détail du job de VP of Engineering, est-ce que tu peux nous donner un petit peu de cadre sur l'entreprise, les équipes, la taille de la boîte, la stack que vous utilisez et plutôt les grandes lignes culturelles de l'entreprise? Je pense que ce qui est assez rigolo, c'est qu'il y a... Du coup, je suis arrivé il y a 4 ans. Et en fait, il y a 4 ans... L'entreprise, c'était 100 personnes au complet. Et à la tech, il y avait trois personnes. Yvan, Jesse, un stagiaire et il y avait peut-être un freelance front à l'époque. Donc clairement, il y avait déjà très très peu de devs. Par rapport à une boîte qui était très commerciale. Aujourd'hui, 4 ans après, on est 850 dans l'entreprise, et à la tech et au produit, au sens large, on est 150 personnes. Donc vraiment, il y a eu un changement plus que conséquent. C'est une boîte qui accélère très très vite. On double tous les chiffres tous les ans. Et on a une croissance du trafic de plus de 10% tous les mois.

5:38 Donc ça, c'est vraiment hyper croissance, une boîte qui se porte à merveille côté business. Et l'essentiel enjeu pour nous, c'est de tenir, technique, c'est d'arriver à tenir la charge de la plateforme. Niveau de la stack, je fais un peu de pub, on a fait une présentation avec un engineering manager, The Boring Architecture, on l'a faite à Devox et à The Duck Conf, et clairement elle explique un peu tout, c'est The Boring Architecture. C'est vraiment la philosophie d'Ivan et Jesse à la base, les fondateurs techniques. c'est vraiment d'avoir la stack la plus simple possible pour pouvoir se concentrer non pas sur de la complexité technique, mais sur des produits pour les utilisateurs finaux. D'accord, donc ça c'est pour la partie archi. Donc tu as dit entre les lignes que vous faisiez du Rails. Pour les gens qui n'ont pas sous leurs yeux débaillis les slides de The... The Boring Architectural, tu peux nous dire un petit peu ce que vous utilisez, votre stack technique au moins dans les grandes lignes ? Oui, donc très simple comme je le disais, en effet on a du coup le côté une single page application en React, on a un petit peu de RxJS, mais vraiment un petit peu,

6:49 et donc derrière on a un monolithe Rails qui va utiliser du Redis, et après on a un petit peu d'Elasticsearch et essentiellement du Postgres. Le cœur du réacteur pour nous c'est vraiment PostgresQL et voilà, ça s'arrête là. Donc c'est vraiment un monolithe qui est déployé en effet sur plusieurs frontos. Et voilà, on vient de faire un move très récent sur AWS, et ça s'arrête vraiment à peu près là, en termes de stack technique. En termes d'équipe, tu disais que maintenant à l'engineering vous étiez 150, du coup vous êtes organisé comment? Feature team? Il y en a combien? Pour avoir un petit peu des ordres de grandeur et s'imaginer ce que ça peut vouloir dire d'avoir 150 personnes qui font du soft. Donc à date je pense qu'on est sur quelque chose autour de 50 développeurs purement développeurs, après on va avoir une dizaine de personnes en engineering management qui sont des anciens développeurs, après on a quasiment une vingtaine de product managers ou de product directors et après on va avoir les devops, business analyst

7:58 UX, UI et tout le monde. profil un petit peu complémentaire et donc aujourd'hui on est clairement organisé en feature team donc le modèle c'est notre modèle et jusqu'à il ya quelques semaines on avait simplement ce niveau de feature team donc on est tout simplement la feature team docteur la feature team patient etc etc une feature team était en effet purement axé pour un utilisateur final et un scope fonctionnel, jamais un scope technique. Et dans cette feature team, on avait tous les profils nécessaires pour mener à bien la mission. Les développeurs full stack, on ne renie pas du tout le côté expertise. On a des personnes qui nous rejoignent qui étaient expert front ou expert back. Mais par contre, quand on rejoint Doctolib, on a envie d'être autonome sur toute la chaîne de production. Donc bien sûr, quand on n'est pas dans nos zones de confort, si on est plutôt expert front et qu'on doit aller sur le back, on va aller demander à quelqu'un qui s'y connaît mieux et inversement. Donc ça, c'est vraiment la croyance des feature teams complètement autonomes, tous les développeurs full stack. Ce qui a changé très récemment. Donc là maintenant, on est passé de une feature team il y a 4 ans à 12 feature teams aujourd'hui.

9:03 Et ce qu'on a introduit comme niveau très récemment, c'est des domaines. Donc en fait, la feature team docteur est devenue practice pour les petits cabinets de ville et le domaine hospital. Et dans chacun de ces domaines, on a différents types de populations. Bien sûr, les docteurs dans les hôpitaux, ils n'ont pas la même utilisation de notre agenda que les docteurs dans un cabinet de ville. Et même dans ces fameux domaines, on a maintenant des feature teams au sein de ce domaine. Donc par exemple, dans le domaine practice, on a 4 feature teams. Cool, merci pour ça. Ça va faire un petit peu la jonction naturelle sur la description de ton job. C'est-à-dire, du coup, toi, en tant que VP of Engineering, qu'est-ce que c'est un petit peu ton rôle au sein de ce que tu viens de nous décrire finalement? Qu'est-ce que tu fais dans ton quotidien avec ces équipes? Ce qui est sûr, c'est qu'il a énormément changé. Je pense que j'ai changé de casquette et de priorité 50 fois depuis que je suis arrivé. Au tout début, c'était 50% de recrutement. Clairement, il y a 4 ans, c'était 50% de mon boulot, c'était du sourcing. On n'avait même pas de recruteur tech, etc.

10:05 C'était le recrutement, la priorité absolue. Et en parallèle de ça, c'était aider à faire une première bascule de deux data centers. Donc, il y avait vraiment du coaching infra. Ensuite, ça a été plutôt se reconcentrer sur les développeurs, donc du coaching à propos des tests d'intégration, d'aligner les développeurs avec la philosophie d'Yvan et Jesse et le côté pragmatisme. Donc, on est un peu plus passé sur le code. Puis après, il y a eu toute l'époque, on va dire, un peu plus produit. On n'avait pas encore de product owner, donc il a fallu recruter ces product owners, les former, les aligner avec notre façon de faire. Et puis, en vrai, ça change et ça continue de changer tous les quarters. Et le plus important, si je pouvais le résumer vraiment une fois, pour moi, c'est l'huile dans le moteur. Il y a plein de gens, enfin, les problèmes sont pour moi 90% du temps humains et non pas techniques. Et donc, c'est de voir là où ça grince. Une équipe qui commence à s'énerver contre une autre équipe, juste parce qu'ils ne se comprennent pas, c'est trouver les bons moyens pour arriver à les rapprocher et à faire qu'ils se reparlent à nouveau.

11:09 L'huile dans le moteur de tout le moteur qui est l'équipe tech et produit de Doctolib. Et du coup, comment tu décrirais la complémentarité entre le rôle de CTO et le rôle de VP Eng chez vous? Clairement, au moment où j'ai pris cette position, j'ai essayé de regarder un petit peu sur le net comment on définissait un VP of Engineering. rapport à un CTO. Et ce que j'ai compris, c'est qu'il n'y a pas de définition qui puisse vraiment tenir la route. Ça dépend des contextes. Et donc, clairement, ce qui était assez original à Doctolib quand je suis arrivé, c'est ce côté qu'il y avait deux CTO, qui en plus agissaient un petit peu comme un vieux couple. Ils ne m'en voudront pas, mais ils travaillent ensemble depuis qu'ils sont à l'école. C'est ce qui fait leur force. Eux aussi, ils sont complémentaires. Et à eux deux, ils ont une expertise absolue sur le produit et la tech. Et un pragmatisme, ils sont capables d'apporter de la valeur de manière très, très efficace. Je pense que Stan, le CEO, a vraiment trouvé la paire incroyable. Et donc, du coup, ils avaient déjà pas mal de casques qui cochaient à eux deux. Donc, le VP of Engineering, il arrive et il doit essayer de composer avec déjà leurs forces et leurs faiblesses et essayer de boucher les trous.

12:14 C'est ça qui a été intéressant. Et je savais en plus que ça correspondait bien avec mes forces. Après, clairement, sur des débats d'architecture, etc., j'étais avec eux, on en discutait. Et sur des débats de méthodologie, de management et de recrutement, bien sûr, ils étaient avec moi, ils me challengeaient aussi. Par contre, c'est sûr qu'il y avait un peu le côté accountable de certaines parties qui étaient plutôt attribuées à l'un ou à l'autre. Ce qui a un peu changé dans le temps aussi, c'est qu'au début, je pense qu'à nous trois, ça marchait très très bien. Et d'ailleurs, ça marche toujours très bien. Mais c'est sûr qu'avec la croissance de Doctolib, en deux ans, on est passé de nous trois et deux, trois personnes, on est passé à quasiment 75 personnes dans la tech et le produit. Donc ça fait un changement très radical dans tous nos rôles et responsabilités. Et à ce moment-là, on s'est tous les trois posé la question, on s'est dit, ok, mais ce rôle de CTO, est-ce que c'est vraiment encore ce que vous voulez faire et ce que vous faites, Yvan et Jessie? Et on était clairement d'accord que non.

13:16 Pour une boîte, la boîte était arrivée à 300, 400 personnes, c'était clairement... Pas un rôle de CTO avec une boîte de cette envergure qu'ils avaient. Donc tous les trois, on s'est mis d'accord qu'on voulait encore élever la barre, changer de braquet et essayer d'aller chercher quelqu'un d'une autre envergure. La chance qu'on avait avec la visibilité, avec les fonds d'investissement qu'on a, on avait accès à un réseau assez puissant. Et donc, on a trouvé Philippe Vimar. Donc Philippe Vimar, c'est maintenant aujourd'hui le CTO et le CEO, et d'ailleurs le directeur adjoint de Doctolib, mais en tout cas, il nous a rejoint en tant que CTO. Et là, on avait vraiment trouvé un top gun. Il est québécois à l'origine. Il est arrivé en Europe depuis une dizaine d'années et il a eu des expériences vraiment incroyables. Par exemple, il a été CTO et CEO de eDreams à Barcelone. Et donc, en fait, il avait managé des équipes de 400, 500 ingénieurs, mais avec la même philosophie et mentalité que nous, on avait. Donc, on a vraiment trouvé le candidat parfait. Il était capable de nous changer de braquet et nous amener encore plus loin.

14:19 Et en plus, avec les mêmes valeurs qu'on avait. Donc, maintenant, ça fait un peu plus d'un an et demi qu'il est arrivé. Et quand il est arrivé, il a pris ce rôle de CTO. Et Yvan et Jessie... se sont reconcentrés sur quelque chose qui était un peu plus de leur goût, et le côté solution architecte. Bien sûr, ils sont encore au board, ils sont encore très impliqués dans la stratégie d'Octolib, mais après, au quotidien, ils sont plutôt à mettre les mains dans le cambouis avec les devs et les guider sur l'architecture et ce genre de choses. Ce qui leur va très bien. Et à vrai dire, même moi, il y a des gens qui m'ont posé la question, mais du coup, pourquoi ce n'est pas toi qui es devenu CTO, ce genre de choses. À vrai dire, je pense que c'est ce qui nous caractérise pas mal à la tech. On a le côté assez humble. Moi, de passer de 4 à 75, c'était déjà un énorme challenge. J'ai déjà appris énormément. Et de devoir encore tripler et quadrupler cette équipe sur les quelques années à venir, je l'aurais fait avec plaisir, mais je pensais que c'était encore plus intéressant d'avoir quelqu'un qui soit capable de nous mentorer.

15:20 Et clairement, de jouer la carte Philippe, ça a été vraiment une très très bonne chose. Il apporte énormément de maturité, de sérénité à la tech, et à vrai dire, aujourd'hui, bien plus qu'à la tech. Il est arrivé, lui et moi, on s'est forcément pas mal challengé au début. En fait, on se respecte énormément maintenant, et il me délègue pas mal de choses, et ça lui donne l'occasion d'aller se concentrer sur plein d'autres secteurs de la boîte. C'est pour ça qu'il est aussi si haut au groupe, donc il s'occupe des opérations, mais aussi de coacher un petit peu le comité de direction carrément. Et voilà, donc moi je suis content, j'ai gardé mon autonomie, mais surtout j'ai quelque part quelqu'un qui est capable de me rattraper quand je pars dans la mauvaise direction ou de me rassurer quand je vais dans la bonne. Merci pour ça, petite transition un peu naturelle. On se connaît bien, tu ne gardes pas les mains dans le dos généralement et tu as souvent été, quelles que soient tes positions en tant que coach ou tech lead, les mains dans le code.

16:22 Aujourd'hui, tu y arrives encore ou pas? Est-ce que tu codes encore? Est-ce que tu as encore envie de le faire? Est-ce que tu devrais le faire? Est-ce que tu ne devrais pas le faire? Alors, est-ce que j'ai envie de le faire? De faire, c'est oui. Est-ce que je le fais encore? Je dirais non. Et est-ce que je devrais le faire? Clairement non. C'est d'ailleurs un peu la déception en arrivant à Doctolib. J'avais juste fait trois mois de raise rapidement. Auprès d'Yvan et de Jessie, j'étais content d'aller apprendre ce genre de choses-là. Clairement, j'ai pu m'y mettre un petit peu au début, mais c'était jamais, mais vraiment jamais dans ma top 3 des priorités. Donc, c'était vraiment à la marge. Je suis content, j'ai réussi à acquérir un certain niveau et qui m'a permis de pouvoir discuter aisément avec les développeurs, etc. Mais en fait, je pense qu'il ne faut pas se faire d'illusions. Si on choisit la track de people management et la track de manager, c'est une mauvaise chose que de se mettre sur le chemin critique de réalisation des features. Il faut avoir le minimum syndical pour pouvoir parler aux développeurs, pour acquérir une certaine confiance.

17:27 Et après, surtout, là où il faut être... Impactant et presque le meilleur, c'est le côté coaching quand on dessine au tableau blanc, quand on parle d'architecture, etc. Ça, il n'y a pas de sujet, ça ne se perd pas trop et c'est un petit peu agnostique au langage de programmation. Par contre, un manager qui a en haut de sa to-do list le fait de délivrer une feature, je pense qu'il va mal faire son boulot puisqu'il ne va pas pouvoir prendre le temps nécessaire pour regarder est-ce que l'équipe va bien, faire ce pas de recul pour s'assurer si tout roule bien. Du coup, entre les lignes, je comprends que chez Doctolib, les managers ne codent pas. Non, je pense que c'est graduel. Je pense qu'un manager junior, il va encore clairement pour nous, et c'est un peu d'ailleurs ce qu'on a mis sur notre carrière pass, on a un petit peu une matrice qui nous dit en fonction de notre niveau de séniorité, qu'est-ce qu'on doit faire, qu'est-ce qu'on doit cocher. Un manager junior qui vient de changer de track, il va coder certainement encore 70% de son temps. Et plus on va grandir, plus on aura de personnes à manager ou plus de responsabilités sur les sujets transverses, moins on va coder. Et clairement, quand on arrive senior engineering manager, oui, on va coder 3% de son temps pour quand ça nous amuse et pour fixer un bug de temps en temps pour garder la main.

18:38 Bon, on va continuer à tirer un peu le fil de ton quotidien. Donc, tu n'arrives plus à coder et tu penses que finalement, c'est plutôt une bonne chose que tu n'aies pas les mains sur le clavier. Est-ce qu'il y a quelque chose qui tomberait dans ton top 3 ou dans ton top 5, mais que tu n'arrives pas à faire faute de temps? Clairement, là, c'est en ce moment le côté lignification de la boîte. Vaste sujet. Mais avec la croissance... Lignification, donc tu parles de lean management, c'est ça? Exactement. En fait, c'est lignification, agilification. Je sais que c'est des mots un peu valises. Surtout aujourd'hui, on met un peu tout et n'importe quoi derrière ça. Mais le côté, on va dire, lignification, essayer d'avoir un meilleur process pour être plus efficace dans la boîte. Tout ce qu'on voit, mine de rien, les équipes techniques en général sont très matures sur ce genre de sujet. Et il y a d'autres équipes, surtout quand elles sont assez juniors à Doctolib, la moyenne d'âge est autour de 30 ans. Et on a toutes... les équipes qui doublent à peu près tous les ans. Donc on a des managers talentueux, très bons, très motivés, mais c'est sûr, souvent assez peu expérimentés. Et donc du coup, je pense qu'il y a énormément de bonnes pratiques de la tech qu'on peut aller déployer dans d'autres...

19:42 d'autres pans de l'organisation. Et ça, c'est vraiment justement d'ailleurs quelque chose qu'on avait discuté avec Philippe dès qu'il est arrivé. C'est quelque chose qui m'intéresse énormément, d'aller faire des rétrospectives avec des équipes de commerciaux, d'aller faire des can-bans visuels, du management visuel avec des équipes de finance ou ce genre de choses. Je pense que ça, ça m'intéresse énormément. Mais aujourd'hui, je n'arrive pas à dégager le temps du quotidien et de l'opération de la tech pour aller faire ce genre de choses. Bon, on a tous nos problèmes à gérer au quotidien. D'ailleurs, j'ai l'impression que notre quotidien, c'est de gérer des problèmes. Mais il y en a toujours un ou deux qui sont plus méchants que d'autres. Est-ce qu'il y en a un en ce moment qui t'empêche de dormir? Celui que tu n'arrives pas à résoudre et qui te fait mal dormir? Oui, clairement, je pense que... Que tu peux partager, toi. Non, je pense que c'est un challenge en plus pour en avoir discuté avec quelques CTO et VP autour de Paris, c'est assez commun. On a ouvert, enfin Doctolib est lancé en Allemagne depuis quelques années maintenant, et on a décidé aussi d'ouvrir un Dev Center en Allemagne. Donc on a bootstrappé une équipe de développement là-bas, et clairement, ça c'est toujours un challenge.

20:49 Comment on arrive à avoir la même culture tech, managériale et produit dans deux Dev Centers, surtout quand on n'est pas dans le même pays? La philosophie, elle est très simple. On a des feature teams en France, on a des feature teams en Allemagne. On veut qu'elles soient exactement le même typologie de feature teams. Il y a des feature teams qui ne sont pas sur le même étage. Et bien là, c'est juste qu'elles ne sont pas dans le même pays. Donc voilà, la target, elle est là. Mais bien sûr, c'est toujours un peu plus compliqué. Comment on s'assure que les personnes en Allemagne mettent la barre de recrutement au même niveau? Comment on s'assure que la culture, ils vont aller regarder les mêmes choses? Et surtout après, comment on s'aligne sur les mêmes manières de coder, etc. Super sujet, je pense même que ça vaudrait un retour d'expérience sur un Tech.Rocks. Summit, c'est un de ces quatre parce que je pense que c'est un gros sujet pour les grosses boîtes. Alors, une petite dernière question qu'on a pratiquée tous les deux quand on avait notre casquette de consultant. Alors, si tu avais une baguette magique, Nicolas, tu changerais quoi en premier? Il n'y en a qu'un qui est facile, c'est l'accès au talent, pouvoir recruter qui on veut quand on veut.

21:52 C'est comme ça que j'utiliserais ma baguette magique. Mais il n'y a pas vraiment de surprise, je pense. Je ne peux pas, je l'ai déjà pris ce vœu à ta place. Non, mais clairement, pour avoir des personnes qui viennent et qui me demandent des conseils sur le recrutement, je pense que c'est un problème que tout le monde a. Et d'ailleurs, c'est aussi la question que je pose à tout le monde. Comment tu fais pour recruter? Il y a vraiment un marché qui est tendu en ce moment et que c'est le problème pour tout le monde. On va maintenant plutôt essayer d'ouvrir la conversation à tes petits conseils, les tips and tricks ou lectures ou autres conseils que tu pourrais donner aux membres de la communauté Tech.Rocks. Du coup, si demain, quelqu'un prend un job de VPN ou de CTO, tu lui donnerais quoi comme trois conseils? Si tu as trois conseils à lui donner, tu lui proposerais quoi? Peut-être pour faire une transition avec le sujet qu'on vient d'aborder sur le recrutement, c'est pour moi le plus important, le nerf de la guerre, c'est tout est là, c'est sur les personnes que tu vas recruter.

22:54 Peu importe les process, peu importe la méthodologie, peu importe le secteur, peu importe la tech, tout vient. des personnes. Et le but du jeu, c'est de ne jamais baisser la barre. Mais ce n'est pas seulement une barre technique, c'est vraiment une barre en termes d'attitude, bien savoir quel type de profil, quelle culture tu veux avoir. Est-ce que tu veux avoir des personnes plutôt full stack, pas full stack, plutôt user-centric, plutôt tech-savvy, etc. Peu importe, définis ta barre et ne la baisse jamais. On a tous une pression de« il faut recruter plus vite puisque le marché est tendu». Et il y a toujours un moment où on a un peu de désespoir puisqu'on n'arrive pas à recruter. Ça fait six mois qu'on cherche ce profil-là. Et du coup, on se dit« très bien, cette personne, elle fera peut-être le taf, même si je n'en suis pas convaincu». Ben non, ne jamais, jamais, jamais, jamais céder à ça. Et ce n'est pas facile, surtout quand on est en croissance, que par exemple, on va essayer de recruter des managers, qu'on a recruté déjà pas mal de développeurs, qu'on manage maintenant, je ne sais pas, et je l'entends en plus régulièrement, 15, 20 personnes en direct. Clairement, on fait du mauvais management. Du coup, on se dit, ce n'est pas grave, je vais prendre ce manager-là.

23:55 Il va m'aider même s'il n'est pas parfait. Eh bien non, ça reste quand même une erreur. Il ne faut jamais céder et toujours trouver le profil impeccable où on est convaincu qu'il fera magiquement le travail. Super conseil, je ne peux qu'être d'accord avec toi. C'est certainement toi qui me l'as donné un jour. Le côté, quelque chose qui est assez rigolo, moi, bienveillance et transparence. Ça, pour le coup, je l'ai appris auprès de personnes comme toi et auprès de plein de personnes à Doctolib, du management avec bienveillance et transparence. Moi, je le résume à ça. Il suffit d'être transparent. Un manager, je pense qu'il peut à peu près tout le temps tout dire, et même des choses difficiles, si on les dit avec bienveillance, c'est dans le but d'aider. Donc bienveillance et transparence, c'était un petit peu deux choses que je n'avais peut-être pas matérialisées dans ma tête jusque-là, mais c'était un peu dans ma nature, en tout cas c'est ça que je voulais faire. Je ne voulais pas faire du management pour être le chef et dire ce qu'il fallait faire, c'était vraiment ce côté faire agrandir les gens. Par la bienveillance et la transparence.

24:55 Et en fait, un moment arrivait avec les enjeux de croissance de Doctolib, et quand... On est arrivé à une équipe de 75 personnes. À certains moments, j'avais le sentiment que peut-être que c'était un peu utopique et qu'à un certain niveau de management, il fallait changer un peu son fusil d'épaule et faire les choses de manière un peu différente. Et en vrai, pour le coup, c'est là où Philippe, je pense, m'a beaucoup rassuré. Je pense qu'on n'en a même jamais parlé, mais lui, je l'ai vu et je l'ai ressenti, et je pense que toute l'entreprise l'a senti. Il a un aura incroyable. Aujourd'hui, il manage quasiment 400 personnes à Doctolib. Et pourtant, tout le monde va le dire, on sent vraiment, ça transparaît, la bienveillance et la transparence. Il y a peut-être un côté canadien là-dedans, je ne sais pas. Mais en tout cas, ça se voit que c'est sincère. Attention, ça ne veut pas dire qu'il va être challengeant. C'est un exécutif et on sent bien la pression, on sent bien qu'il y a beaucoup d'attentes. Par contre, c'est fait avec ces deux valeurs-là. Et ça, ça m'a énormément rassuré sur le futur de ma carrière.

26:00 Un dernier conseil, c'est d'aller voir The Boring Architecture. Et en vrai, c'est ce côté« keep the stack simple». Ça, c'est quelque chose que j'ai énormément appris auprès d'Ivan et Jesse. Je savais déjà qu'ils étaient un petit peu comme ça, mais je voulais le voir pour le croire et surtout à quel point. Je pense qu'il n'y a aucun développeur qui va se dire« Ah oui, oui, moi je ne fais pas de la tech pour la tech» ou bien sûr« Je suis pragmatique». Mais en vrai, dans les faits, on est tous geeks et on est tous happés par le côté... outils ou solutions avant de penser vraiment quel problème on essaye de résoudre. Yvan et Jesse ont vraiment une rigueur incroyable sur ce sujet-là. Et je pense que c'est ça qui fait qu'ils ont eu autant de succès dans leur carrière à être entrepreneurs et à pouvoir aller très vite quand ils ont une mission. Attention, ça ne veut pas dire qu'il y a des valeurs qualité et non négociable. Le code qu'on produit, on en est toujours content. On a mis des tests depuis le premier jour à Doctolib. Par contre, on a toujours choisi la solution la plus simple pour un problème donné.

27:01 Je fais plus un. Et en même temps, ça demande beaucoup de courage. On est quand même des gros geeks et on est toujours content de voir un dernier framework à la mode qui nous fait des promesses incroyables et vraies. Et il faut beaucoup de courage pour refuser ça. Dans ton quotidien, est-ce que toi, tu as des outils ou des routines qui font que tu réussis à faire ton job avec un peu plus de sérénité ou d'efficacité que tu pourrais partager? Il y en a pas mal et c'est vrai que je pense que c'est quand même assez personnel. Chacun doit utiliser sa propre recette. Mais clairement, je pense que plus on veut avoir de responsabilités, c'est le côté accuracy qui est très important. Être très rigoureux dans sa manière de travailler. Donc en fait, c'est pour moi aujourd'hui, les outils sont très managériales, mais c'est un agenda vraiment au cordeau. Je me suis... Ça m'a fait mal, je ne suis pas quelqu'un qui adore les réunions, et pourtant, plus la boîte grandit, plus je passe mon temps en meeting. Et donc du coup, du coup, c'est de faire une rétro-analyse sur mon agenda, sur le quarter précédent, et d'essayer de voir quelle est ma work distribution.

28:06 Où est-ce que je passe du temps? Et du coup, se dire, est-ce que je passe assez de temps avec cette équipe ou pas? Prendre du recul là-dessus. Donc vraiment, s'assurer qu'on passe du temps au bon endroit. Et après, préparer son agenda, que celui-ci soit vraiment très bien organisé. Si une réunion est dure trop longtemps, on la coupe, on la clôt et on est à l'heure à la prochaine. Être à zéro inbox tous les soirs, traiter tous les emails. Ça, chacun sa recette. C'est un enjeu tous les jours, mais pour moi, c'est quelque chose d'important. Et toujours être on top de ses actions. J'ai une checklist, une seule, qui est toujours à jour et j'essaie de ne pas être en retard ou de mettre à jour. Donc voilà, l'organisation. Si on veut traiter beaucoup de sujets, et c'est ce qui arrive malgré soi, c'est vraiment l'organisation. On a toujours un peu besoin d'aller chercher des inspirations à l'extérieur parce que nos problèmes sont de plus en plus inédits et que parfois autour de toi on n'a pas les réponses. Est-ce qu'il y a des lectures, des présentations particulières qui ont marqué ta carrière et qui t'accompagnent encore aujourd'hui?

29:07 Plus dans mon rôle aujourd'hui, et je pense que c'est pour ça qu'on fait le podcast, les dernières lectures qui m'ont vraiment marqué, c'est The Five Dysfunctions of a Team, qui est un bouquin vraiment intéressant et qui parle pour n'importe quelle équipe. Ça, c'est vraiment pour moi un must-read. Et est-ce que tu as un deuxième ouvrage éventuellement? Clairement, The Heart Thing About The Heart Thing, je l'ai découvert très récemment. Et là, c'est un CEO qui est passé par tous les problèmes de sa position. Et je pense que là, c'est vraiment au niveau d'une Bible. Et ce qui est le plus enrichissant, c'est vraiment la première partie du bouquin où en gros, tout simplement, il raconte, c'est un retour d'expérience sur ces différentes entreprises et par tous les moments de grande solitude par lesquels il passe. Et moi, c'est quelque chose qui m'a vraiment... choqué au moment où je suis arrivé à cette position, c'est qu'il y a des moments où c'est « it's lonely at the top », c'est qu'en fait on n'a vraiment plus personne vers qui se tourner pour tout simplement aller faire un peu de thérapie et raconter ses problèmes ou de trouver des solutions.

30:13 Et d'ailleurs je pense que c'est pour ça que c'est vraiment super que sur la scène parisienne en ce moment il y a des choses comme Tech.Rocks qui apparaissent. Puisque vraiment c'est très important d'aller partager ces problèmes avec quelqu'un, et donc tout simplement de raconter à quelqu'un qui est dans la même position qu'on a ce problème-là, et puis on peut échanger sur des solutions, et comme d'habitude essentiellement sur les erreurs et ce qui n'a pas marché. Donc vraiment ce bouquin... Il sert un peu à ça aussi. Et je pense que la deuxième partie du bouquin, c'est que des solutions très pragmatiques à plein de situations bien précises. Je pense que je vais essayer de me les noter. Et à chaque fois que j'aurai un problème, d'essayer d'aller creuser pour voir s'il n'y a pas déjà une réponse dans ce bouquin-là. Merci. On va clore un peu cet échange sur une citation. Souvent, on a un peu des mantras, des choses qu'on garde en tête, des phrases qui nous ont un peu marquées et qu'on se répète. Est-ce que toi, tu en as une? Je pense que je l'utilise un petit peu moins en ce moment, et c'est bien dommage, mais pour le coup, elle a quand même fait ma carrière avec moi jusque-là, c'est on améliore que ce que l'on mesure,

31:21 et je pense que tu la connais toi aussi, mais vraiment, j'essaie de me la rappeler, on va dire, tous les six mois, parce qu'on ne le fait jamais assez. Merci Nicolas, c'était vraiment chouette comme discussion. J'espère que tu as pris plaisir autant que moi en tout cas à échanger autour du job de Tech Leaders et de VP Engineering. Il y a plein d'enseignements que tu nous as partagés aujourd'hui qui sont riches. Moi, j'ai trouvé ça très intéressant. Je te remercie pour tout ça et j'espère qu'on se retrouvera bientôt, notamment le 4 décembre 2019 pour la nouvelle édition du Tech.Rocks Summit, où il y aura pas mal de taux qu'intéressants et on aura une nouvelle occasion de partager ensemble nos expériences.