Return to site

"Paroles de Tech Leaders"

épisode #2 Nicolas DE NAYER - DOCTOLIB (VP of Engineering)

Le Podcast Tech Rocks qui donne la parole aux Tech Leaders

"Paroles 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 (HL), CTO et co-directeur de Videdressing et j’ai l’honneur aujourd’hui de recevoir Nicolas De Nayer (NDN), VP of Engineering de Doctolib, pour cette interview de Paroles de Tech Leaders.

Bonjour Hervé ! Je suis Nicolas de Nayer, VP of Engineering de Doctolib depuis 4 ans maintenant.

Qui es-tu ?

HL : “je te propose de commencer par les formalités d’usage, nous pouvons retracer ton parcours. L’idée, c’est que tu nous racontes les grandes étapes qui t’ont amené progressivement à la responsabilité de VP of Engineering chez Doctolib : dis-nous tout !”

NDN : “alors, je suis ingénieur avant tout. J’ai commencé par cela en Bretagne puis je suis arrivé par les Pages Jaunes en 2009 à Paris. Là-bas, j’y ai surtout découvert OCTO Technology, une société que tu connais, il me semble. Je travaillais en tant que Tech Lead chez les Pages Jaunes, avec OCTO Technology qui faisait du conseil.

C’est là que j’ai beaucoup appris sur la partie agile, j’ai fait de belles rencontres et en fin de mission j’ai eu le choix entre intégrer les pages jaunes ou de faire un reset dans ma carrière et d’aller chez OCTO Technology. C’est ce que j’ai choisi et je pense que cela a été un très bon choix. J’y suis resté 3 ans, j’ai pu faire beaucoup de missions, de rencontres. J’ai beaucoup appris sur la méthodologie, le management, la Tech… Là-bas, j’y étais architecte J2E, coach agile, Tech Lead. Là, ma dernière mission s’est déroulée chez Viadeo, l’objectif était de faire une transformation à grande échelle de l’entreprise, 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 il s’agissait de transformer les équipes, les mettre en Feature Team… développer ce type de réflexions qui étaient assez novatrices à l’époque. Viadeo m’a ensuite débauché pour reprendre leur bureau de San Francisco. C’était un bureau très technique, mais qui donnait l’impression d’être d’irrésistibles gaulois. Ils étaient moins organisés en Feature Team, avec des pratiques différentes. Ma mission a été de casser ce modèle purement technique, pour aller vers une organisation plus fonctionnelle et user centric.”

HL : “je rebondis sur ces expériences que tu décris. Il y a une étape intéressante dans ton parcours : pourquoi basculer du conseil vers des fonctions de leader technique dans les entreprises, notamment après Viadeo. Je pense que c’est un point d’appui intéressant dans ton parcours, peux-tu nous en dire plus ?”

NDN : “le côté-conseil est une superbe école, l’on découvre de nouvelles thématiques tous les trois mois, avec des missions qui s'enchaînent, des techniques, des personnes, des directions, des contextes toujours différents. Par contre, c’est usant, voire épuisant : l’on veut et doit être impactant en quelques jours. Ce qui peut être frustrant avec le changement régulier de missions, c’est que l’on n’a souvent pas le temps de voir les effets réels des changements que l’on a tenté d’induire, ou de s’assurer qu’ils soient vraiment en place et intégrés à l’ADN de l’entreprise. [Mon changement de voie], c’est la volonté de pouvoir s’assurer que les changements soient bien appliqués jusqu’au bout, dans les autres entreprises.”

HL : “après ton expérience Viadeo à San Francisco que s’est-il passé ?”

NDN : “à San Francisco j’étais bien, il y avait le surf et le soleil. Mais c’est Yvan (Schneider) et Jessy (Bermal) (cofondateurs de Doctolib) qui m’ont recontacté, « mafia » OCTO Technology toujours, pour un projet encore assez peu connu à l’époque, Doctolib. Le problème, c’était de revenir sous la grisaille parisienne, mais pour connaître Yvan et Jessy, j’avais vraiment envie d’aller travailler avec eux. Je savais qu’ils pouvaient être très impactant, et surtout j’étais assez complémentaire de leur besoin.

J’ai eu mes craintes, il s’agissait d’arriver dans un contexte de startup déjà relativement établie, mais surtout déjà pourvue de deux CTO, l’enjeu était d’arriver en tant que VP of Engineering dans un environnement déjà occupé. Ce qui m’a rassuré, c’est que je les connaissais un peu, et je savais que nous étions complémentaires.”

Ton rôle de Tech lead chez Doctolib

HL : “parfait. Je propose de rentrer dans le détail de ton rôle de Tech Lead chez Doctolib. Mais avant d’évoquer le rôle du VP of Engineering, est-ce que tu peux nous donner un peu de cadres sur l’entreprise, les équipes, la taille de l’organisation, la stack utilisée, les grandes lignes culturelles…

NDN : “ce qui est amusant, c’est que je suis arrivé il y a 4 ans, et à ce moment-là, l’entreprise était composée de 100 personnes au total, avec 3 personnes à la Tech : Yvan, Jessy, un stagiaire “rails” et un freelance front. Clairement il y avait peu de Dev pour une boite très commerciale.

Aujourd’hui, nous sommes 850 dans l’entreprise, et à la Tech et produits (au sens large) désormais 150 personnes. Il y a eu un changement immense, c’est une entreprise qui accélère très vite, l’on double tous les chiffres tous les ans avec une croissance de trafic de plus de 10% tous les mois. L’on est face à une hyper croissance, une entreprise qui fonctionne très bien côté business. L’enjeu essentiel, niveau technique, est d’arriver à tenir la charge de la plateforme.

Au niveau de la Stack, nous nous appuyons sur la Boring Architecture (je fais de la publicité, nous avons fait une présentation avec un Engine Manager, à Devoxx notamment). La philosophie initiale d’Yvan et Jessy (les fondateurs techniques) c’est 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.”

HL : “merci de tes précisions pour la partie architecture. Tu évoques entre les lignes le rails : pour ceux qui ne connaissent pas, tu peux nous parler de la stack technique, dans ses grandes lignes ?”

NDN : “bien sûr. C’est très simple, l’on s’appuie sur du single page application en react. Un peu de RIJS, et derrière un monolithe rails qui utilise du Rdis, en parallèle d’un peu de RX Search et essentiellement, du PostgreSQL. Le cœur du réacteur c’est vraiment Post gray SQL, monolithe déployé sur plusieurs frontaux. En précision, très récemment, l’on est allés également sur AWS. Voilà pour les grandes lignes de notre Stack technique.”

HL : “en termes d’équipes, à l’Engineering vous êtes donc 150 : comment est-ce que vous vous structurez, en feature team ? Peux-tu nous donner des ordres de grandeur, pour nous permettre de nous rendre compte de ce que cela représente d’avoir autant de développeurs qui font du soft.”

NDN : “nous comptons une cinquantaine de développeurs purs, une dizaine de personnes en engineering management (anciens développeurs), une vingtaine de Product managers et Directors. Viennent ensuite les Dev Ops, Business Analyst… et les profils complémentaires.

Aujourd’hui l’organisation est basée sur un modèle en Feature Team (FT), et jusque récemment, nous avions cet unique niveau : une FT Docteur, une FT Patient… Une FT était purement axée vers un utilisateur final et un scope fonctionnel, jamais un scope technique. Dans la FT nous disposions de tous les profils nécessaires pour mener à bien la mission. Nos développeurs sont full stack, sans renier le côté expertise, puisque certains collaborateurs étaient expert front ou expert back. Par contre chez Doctolib l’on souhaite être autonomes sur toute la chaîne de production.

Évidemment, hors de nos zones de confort (sur un projet), en fonction de nos savoir-faire Front ou Back) l’on peut solliciter un expert qui s’y connait mieux. Pour le reste, notre croyance est vraiment de former des Feature Team totalement autonomes et d’avoir tous nos développeurs en full stack.

Ce qui a changé très récemment : c’est que nous sommes passés d’une Feature Team il y a 4 ans à 12 aujourd’hui, et nous avons souhaité introduire des Domaines. Par exemple, la FT Docteur est devenue le domaine Practice, pour les petits cabinets de ville, face au domaine Hospital.

Dans chacun de ces domaines, l’on retrouve différents types de populations : les médecins dans les hôpitaux n’ont pas la même utilisation de notre agenda que les médecins de ville. Ensuite dans ces fameux domaines, nous avons défini des FT spécifiques ; par exemple, dans le domaine Practice, l’on a déployé quatre Feature Team.”

HL : “merci de ces explications ! Elles permettent de faire la jonction vers la description de ton rôle. Toi, en tant que VP of Engineering, quel est ta responsabilité dans ce modèle que tu viens de nous exposer ? Quel est ton quotidien avec ces équipes ?”

NDN : “il a énormément changé : j’ai dû avoir une cinquantaine de « casquettes » et de priorités depuis mon arrivée. Au départ (il y a 4 ans), je consacrais 50% de mon temps au recrutement. Je passais par du sourcing, nous n’avions pas de recruteur Tech. Ce recrutement constituait la priorité absolue avec, en parallèle, l’appui à une première bascule de deux Datacenter, avec du coaching infra.

Ensuite, je me suis reconcentré sur les développeurs, en faisant du coaching, notamment pour les tests d’intégrations. J’alignais les collaborateurs sur la philosophie d’Yvan et Jessy et le pragmatisme du développement (donc en se concentrant plutôt sur le code). Puis est arrivée l’époque des produits, nous n’avions pas encore de Product Owners, il a fallu les recruter, les former, les aligner avec notre façon de faire.

Et, en réalité, cela continue de changer très souvent. Mais le plus important, au final, dans mon rôle, est de mettre de « l’huile dans le moteur ». Selon moi, les problèmes sont à 90% plus liés au facteur humain que technique. Mon rôle est de voir où sont les difficultés. Par exemple, si une équipe s’énerve à propos d’une autre, ce peut être seulement lié à des problèmes de compréhension : mon rôle sera de trouver les bons moyens pour les rapprocher, et permettre de renouer la communication. Fluidifier donc, le fonctionnement de l’équipe Tech de Doctolib.”

HL : “comment décrire la complémentarité entre le rôle de CTO et le rôle de VP Engineering chez Doctolib ?”

NDN : “au moment où j’ai pris cette position, j’ai essayé de comprendre comment l’on définissait un VP of Engineering par rapport à un CTO, et ce que j’ai compris, c’est qu’il n’y a pas de définition absolue. Cela dépend vraiment du contexte : l’originalité à Doctolib à mon arrivée était la présence de deux CTO qui agissait d’ailleurs comme un « vieux couple » (ils ne m’en voudront pas !). Ils travaillent ensemble depuis l’époque de l’école, c’est ce qui fait leur force (eux aussi sont complémentaires). À eux deux, ils ont une expertise absolue sur le produit et la Tech, avec un pragmatisme important, qui leur permet d’apporter efficacement de la valeur. Je pense que Stan (Stanislas Niox-Château), le CEO, a trouvé une parfaite paire.

Ils avaient déjà beaucoup de cases cochées ensemble, donc le VP of Engineering doit essayer de composer avec leurs forces et leurs faiblesses et essayer de combler les manques. C’est ce qui a été particulièrement intéressant, et je savais que cela correspondait bien à mes forces. Pour le reste, sur des débats d’architecture, nous étions ensemble, nous en discutions, et sur la méthodologie, le management et le recrutement, ils m’accompagnaient à leur tour et me challengeaient également. Cela n’enlevait pas la responsabilité de chacun sur les thématiques qui lui étaient effectivement attribuées.

Ce qui a changé dans le temps, c’est qu’avec la croissance de Doctolib, en 2 ans, nous sommes passés d’une toute petite équipe (nous trois, qui fonctionne encore très bien) à quasiment 75 personnes dans la Tech et le produit. Le changement était radical pour nos rôles et responsabilités. Il a fallu s’interroger : Yvan et Jessy souhaitaient-ils encore être CTO d’une structure d’une telle ampleur ? La réponse était claire, ce n’était plus leur objectif. L’entreprise en était à 400 personnes et ils n’avaient clairement pas le rôle d’un CTO d’organisation de cette taille. Nous avons tous les trois décidé de changer de braquet, d’élever la barre et d’aller chercher quelqu’un d’une autre envergure. Notre chance, grâce à notre visibilité et nos fonds d’investissement, était d’avoir avoir à un réseau relativement puissant.

Nous avons trouvé Phillipe Vimard, qui est désormais CTO, COO et directeur de Doctolib. Lorsqu’il nous a rejoints en tant que CTO, nous avons trouvé un « Top gun ». Québécois d’origine, il est arrivé en Europe depuis une dizaine d’années et a développé des expériences incroyables. Il a notamment été CTO et COO de eDreams à Barcelone, et il a pu manager des équipes de 400 à 500 ingénieurs avec la même philosophie et mentalité que nous. C’était le candidat parfait, capable de nous emmener encore plus loin, en conservant nos valeurs. Cela fait 1 an et demi qu’il est arrivé : il a pris ce rôle de CTO, et Yvan et Jessy se sont reconcentrés sur ce qui leur plaisait plus : le côté solution architect. Ils sont évidemment encore au board, impliqués dans la stratégie Doctolib, mais au quotidien ils continuent de guider les développeurs dans l’architecture, ce qui leur convient très bien !

Parfois l’on m’interroge : dans ce cas, pourquoi ne pas être devenu CTO ? C’est, je pense, ce qui nous caractérise dans la Tech : l’on est assez humble. Moi, de passer de 4 à 75 c’était déjà un challenge immense, j’ai énormément appris. De devoir encore tripler, voire quadrupler cette équipe en quelques années, aurait été un plaisir, mais cela me paraissait plus intéressant encore d’avoir quelqu’un capable de nous mentorer. De jouer cette carte a été une très bonne idée : Philippe apporte beaucoup de maturité et de sérénité à la Tech, et bien au-delà.

Nous nous sommes évidemment beaucoup challengés au départ, mais nous nous respectons beaucoup aujourd’hui, et il me délègue de nombreuses tâches pour pouvoir se consacrer à d’autres secteurs de développement de l’entreprise. Il est notamment COO groupe, il s’occupe des opérations et coache également le Comité de Direction. Pour moi c’est parfait, j’ai gardé mon autonomie, mais j’ai surtout trouvé quelqu’un capable de me rattraper quand je pars dans la mauvaise direction, ou de me rassurer quand je vais dans la bonne dans la bonne.”

HL : “nous nous connaissons bien, tu es très actif, dans toutes ses responsabilités de de coach ou de Tech Lead. Mais parviens-tu encore à coder, en ressens-tu le besoin, penses-tu qu’il serait judicieux de le faire ?”

NDN : “j’ai envie de le faire oui, mais je ne n’en ai plus la possibilité. Et d’ailleurs, ce ne serait pas une bonne idée. C’est, peut-être, ma déception en arrivant à Doctolib : j’avais seulement fait 3 mois de Rails, j’étais heureux de l’apprendre auprès d’Yvan et Jessy. J’ai pu l’approcher un peu, mais cela n’a jamais fait partie de mes priorités dans l’entreprise, cela est toujours resté à la marge. J’ai tout de même acquis un certain niveau, ce qui m’a permis d'échanger aisément avec les développeurs, mais il ne faut pas se faire d’illusion.

Si l’on choisit la track de people management ou de manager, c’est une mauvaise idée que de se mettre sur le chemin critique de réalisation des feature : il faut pouvoir parler aux développeurs et acquérir une certaine confiance. Mais là où il faut être impactant, voire le meilleur, c’est lors du coaching, dans le projet, au moment de dessiner sur les tableaux blancs et d’évoquer l’architecture. Sur cette problématique, les habitudes ne se perdent pas, c’est plutôt une démarche agnostique, pour reprendre un langage de programmation.

Mais un manager qui a en haut de sa to-do-list le fait de délivrer une feature ne va pas bien faire son travail. Il n’aura pas le temps de vérifier le fonctionnement de l’équipe, de faire le pas de recul pour s’assurer du bon déroulé du projet.”

HL : “entre les lignes, l’on comprend que chez Doctolib les managers ne codent pas ?”

NDN : “c’est plutôt graduel. Pour nous, un manager junior peut encore coder. C’est l’idée de notre plan de carrière, avec une matrice qui permet de définir, en fonction du niveau de séniorité, les tâches à réaliser en propre ou à déléguer.

Un junior qui vient de changer de track peut certainement coder 70% de son temps. Mais plus l’on monte en responsabilité sur les sujets transverses ou le management, moins l’on code. Clairement, en arrivant senior engineering manager, l’on code 3% de son temps, pour le plaisir ou fixer un bug de temps en temps pour garder la main.”

Ce qui tu voudrais avoir le temps de réaliser

HL : “en tirant le fil de ton quotidien : tu ne peux plus réellement coder, mais tu penses que c’est plutôt normal. Que penses-tu pouvoir intégrer à ton top 3 ou top 5, mais que tu ne parviens pas à réaliser faute de temps ?”

NDN : “en ce moment, je n’ai pas le temps pour la leanification (lean management) de l’entreprise. C’est un mot un peu valise, qui peut englober beaucoup d’idées, mais dont la démarche peut permettre d’améliorer les process et d’être plus efficace dans l’organisation.

Chez Doctolib, l’on se rend compte que les équipes techniques notamment sont très matures sur ces sujets. Les équipes juniors (toutes nos équipes doublent tous les deux ans, la moyenne d’âge est de 30 ans) ont des managers très bons et motivés, mais souvent peu expérimentés. De fait, beaucoup de bonnes pratiques de la Tech peuvent être déployées dans d’autres pans de l’organisation (vers ces équipes).

Nous l’avions évoqué avec Philippe (Vimard) à son arrivée : cela m’intéresse beaucoup. Faire des rétrospectives avec des équipes de commerciaux, du management visuel avec les équipes de finances… la difficulté, c’est que je ne parviens pas, aujourd’hui, à dégager du temps au quotidien et dans les opérations de la Tech pour développer ce type de démarches.”

HL : “le quotidien génère en permanence des problèmes et difficultés : y en a-t-il un, en ce moment, qui t’empêche de dormir ?”

NDN : “c’est un challenge partagé à priori, par beaucoup de CTO et VP autour de Paris. Doctolib est lancé en Allemagne depuis quelque temps déjà, et nous avons ouvert un Dev Center là-bas, avec une équipe de développement. C’est un vrai challenge : comment arriver à avoir la même culture Tech, managériale et produit dans deux Dev Center différents, surtout lorsqu’ils sont situés dans deux pays différents.

La philosophie est simple : nous avons des Feature Team en France et en Allemagne : elles doivent avoir la même typologie, être organisées de la même façon. Au siège, les FT sont sur des étages différents ; ici c’est le même enjeu, mais transnational. Voilà la target, avec évidemment plus de complexité. Comment s’assurer que la barre de recrutement en Allemagne soit du même niveau qu’en France, comment vérifier l’homogénéité des critères, comment s’aligner sur les mêmes pratiques de codage…”

HL : “je pense même que cela vaudrait un retour d’expérience, pourquoi pas lors d’un Tech Rock Summit, puisque je pense que c’est un sujet majeur pour les grandes entreprises. Dernière question, pour le consultant que tu étais : si tu avais une baguette magique, que changerais-tu en premier ?”

NDN : “je pense à l’accès aux talents ! pouvoir recruter qui l’on veut, quand on veut. Quand j’échange autour du recrutement et que l’on me demande des conseils, je me rends compte que c’est un problème que nous rencontrons tous, et une question que je me pose également. Nous sommes face à un marché tendu en ce moment.”

Tes 3 conseils de VP of Engineering

HL : “très bien ! Parlons maintenant de tes avis, des tricks et autres suggestions que tu pourrais apporter aux membres de la communauté Tech Rocks. Si demain quelqu’un devenait VP of Engineering, que lui donnerais-tu comme conseils ?”

NDN : “cela permet de faire la transition avec le sujet que l’on vient d’aborder, à savoir le recrutement. Selon moi tout commence là, c’est en quelques sortes le « nerf de la guerre ». Peu importent les processus, la méthodologie, le secteur ou la Tech, tout vient des personnes. L’objectif, c’est de ne jamais baisser la barre : pas seulement technique, mais aussi comportementale. Il faut être au clair avec les profils et la culture que l’on recherche : préfère-t-on des personnes « full stack » ou non, plutôt user centric… l’important est de définir ses objectifs et de s’y conformer. L’on est tous face à la pression du recrutement, à la nécessité d’embaucher rapidement, dans un contexte de marché tendu.

Effectivement, l’on rencontre toujours ce temps durant lequel l’on peut être « désespéré » de ne pas parvenir à recruter. Cela peut faire plusieurs mois que l’on recherche un profil particulier sans succès, et l’on peut être tenté de recruter une autre personne, qui semble pouvoir prendre le poste, mais qui ne donnerait pas entière satisfaction.

Là, justement, il ne faut pas céder, et ce n’est pas évident, surtout lorsque l’on est en croissance, notamment, lorsque l’on a déjà embauché beaucoup de développeurs et que l’on doit désormais recruter des managers. Par exemple, lorsque l’on manage régulièrement 15 à 20 personnes en direct, l’on sait que l’on n’est pas efficient et l’on peut être tenté de se convaincre que la solution est de prendre un candidat qui n’est pas parfait, mais qui pourra aider. Cela reste une erreur, il ne faut jamais céder et toujours trouver le meilleur profil, qui convainc qu’il fera magiquement le travail.”

HL : Très bon conseil, je ne peux qu’être d’accord.

NDN : “c’est certainement toi qui me l’as donné un jour ! Autre conseil que je pourrais dispenser, qui peut sembler amusant, cultiver la bienveillance et la transparence. Cela, je l’ai appris auprès de beaucoup de personnes, comme toi ou auprès d’autres à Doctolib : être dans ce management avec bienveillance et transparence. Je le résume à cela : il suffit d’être transparent donc : un manager peut tout le temps tout dire, même des choses difficiles, si cela est fait dans le but d’aider.

Ces deux valeurs, c’est quelque chose que je n’ai pas nécessairement matérialisé dans ma tête jusqu’ici, mais c’est un peu dans ma nature et c’est ce que je voulais faire. Je ne voulais pas être manager pour être le chef et imposer le travail, c’était vraiment dans l’idée de faire grandir les gens par la bienveillance et la transparence.

En réalité, à un moment, le fait d’arriver aux enjeux de croissance de Doctolib et au management d’une équipe de 75 personnes m’a donné le sentiment que peut être que cela était utopique. J’ai pensé qu’à un certain niveau de management il fallait changer son fusil d’épaule et faire les choses de façon différente.

En réalité, c’est là où Philippe (Vimard) m’a beaucoup rassuré, même si l’on n’en a jamais parlé. Je l’ai vu, je l’ai observé, toute l’équipe l’a senti, il a une aura incroyable et aujourd’hui il manage quasiment 400 personnes à Doctolib et pourtant, tout le monde va le dire, on le sent réellement, cela ressort, sa bienveillance et sa transparence. C’est peut-être une influence canadienne, mais cela est sincère. Évidemment, cela ne signifie pas qu’il ne va pas être challengeant, c’est un exécutif et l’on sent bien la pression, qu’il y a beaucoup d’attentes. Mais c’est fait avec ces deux valeurs, et cela m’a énormément rassuré sur le futur de ma carrière.

Un dernier conseil : aller voir the Boring Architecture. Ce côté keep the stack simple, je l’ai beaucoup appris auprès d’Yvan et Jessy. Je savais déjà que c’était leur philosophie, mais je voulais voir jusqu’à quel point. Je pense qu’aucun développeur ne va se dire qu’il n’est pas pragmatique, qu’il « ne fait de la Tech que pour la Tech », mais dans les faits nous sommes tous « geek » et happés par les aspects outils et solutions avant de penser aux problèmes que l’on cherche à résoudre.

Yvan et Jessy eux ont une rigueur incroyable sur ces sujets, et c’est ce qui fait qu’ils ont eu autant de succès dans leur carrière d’entrepreneurs et à pouvoir aller très vite quand ils ont une mission. Cela n’empêche pas de respecter les valeurs de qualité, non négociables : le code produit est satisfaisant, on est en test depuis le premier jour à Doctolib, mais l’on choisit toujours la solution la plus simple pour un problème donné.”

Tes outils, tes routines

HL : “je valide ! Mais c’est vrai que cela demande beaucoup de courage de ne pas céder ! L’on est tous un peu geeks et évidemment séduits par le dernier framework à la mode, qui promet monts et merveilles. Dans ton quotidien, quels sont les outils ou les routines qui te permettent de réaliser ton travail avec efficacité ?”

NDN : “il y en a plusieurs : c’est assez personnel, chacun doit utiliser sa propre recette ! Mais lorsque l’on souhaite monter en responsabilité, l’aspect accuracy est très important. Il s’agit d’être rigoureux dans sa manière de travailler.

Pour moi, aujourd’hui, les outils sont très managériaux, mais par exemple ce peut être un agenda très formel. Je ne suis pas friand des réunions, pourtant plus la structure grandit, plus je passe de temps en meeting. Donc ce qui est intéressant, c’est de pouvoir faire une rétro analyse de mon agenda, sur le quarter précédent, et d’analyser ma work distribution, vérifier où je passe du temps et confirmer que j’alloue assez de présence à telle ou telle équipe.

En réalité, il faut prendre du recul sur son organisation, s’assurer que l’on passe du temps au bon endroit et préparer correctement l’agenda, en l’organisant bien et en le respectant : si une réunion dure trop longtemps, on la coupe on est à l’heure à la suivante. C’est aussi être à 0 Inbox tous les soirs, traiter tous les Emails… Il faut toujours être on top de ses actions : j’ai une check-list unique qui est toujours à jour, j’essaie de ne pas être en retard et de la respecter.

Bien sûr, chacun s’organise, c’est un enjeu quotidien, mais pour moi c’est important. Le maître mot, c’est l’organisation : si l’on veut traiter beaucoup de sujets, et c’est ce qui arrive malgré soi, c’est l’unique solution.”

Conseils de lecture

HL : “l’on a toujours besoin d’aller chercher des inspirations à l’extérieur parce que nos problèmes sont de plus en plus inédits et que l’on ne dispose pas nécessairement de la réponse autour de soi : est ce qu’il y a des lectures, des présentations particulières qui ont marqué ta carrière et qui t’accompagnent encore ?”

NDN : “dans mon rôle actuel [de VP], la dernière lecture à m’avoir marqué est « The five dysfunctions of the team » qui est un livre réellement intéressant et qui fait sens pour tout type d’équipe. C’est un must read !”

HL : “et un second ouvrage à recommander ?”

NDN : “« The arting about the arting ». Je l’ai découvert récemment, il évoque l’histoire d’un COO qui est passé par toutes les difficultés de sa position. C’est une véritable Bible, notamment la première partie du livre qui est un retour d’expérience de ses passages dans différentes entreprises et sur tous les moments de solitude par lesquels il passe. Cela m’a choqué, au moment d’arriver à ma position : le fait d’être lonely at the top, sans plus personne vers qui se tourner pour faire un peu de thérapie et raconter ses problèmes ou trouver des solutions.

C’est pour cela que la scène parisienne est vraiment dynamique en ce moment, avec des initiatives comme Tech Rocks qui apparaissent, puisque c’est très important de partager ses problèmes avec quelqu’un et de simplement raconter à un pair ses difficultés. Cela permet d’échanger sur des solutions, sur les erreurs et ce qui n’a pas fonctionné. Ce livre, il sert aussi à cela, et je pense que la seconde partie (des solutions très pragmatiques à beaucoup de situations précises) me sera utile à chaque fois que j’aurai un problème, pour retrouver une éventuelle réponse dans le livre.”

HL : “pour clore l’interview, est-ce que tu as une phrase, une citation, un mantra que tu te répètes ?”

NDN : “je pense que je l’utilise un peu moins en ce moment et c’est dommage, mais elle m’a accompagné dans ma carrière jusqu’ici : c’est la phrase « on améliore que ce que l’on mesure ». Je pense que tu la connais également ! J’essaie de me la rappeler tous les 6 mois, parce qu’on ne le fait jamais assez.”

HL : “merci Nicolas de cette discussion, j’espère que tu as pris autant de plaisir que moi à échanger autour des enjeux de Tech Leader et de VP of Engineering. Il y a beaucoup d’enseignements que tu nous as partagé aujourd’hui qui sont riches.

J’ai trouvé cela très intéressant, je te remercie pour tout cela et espère te retrouver bientôt, notamment le 4 décembre 2019 pour la nouvelle édition du Tech Rocks Summit, avec beaucoup de Talks intéressants et une nouvelle occasion de partager ensemble nos expériences !”

NDN : “merci, cela a été un plaisir, comme toujours. Bien sûr, j’y serai, le 4 décembre !”

Venez rencontrer Nicolas et Hervé le 4 décembre : http://bit.ly/2x72cgi

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK