Bruno:
Quand j'étais petit, je croyais que les super-héros portaient des caps. En grandissant, j'ai compris que certains portent en fait des claviers. Un distinguished engineer, c'est un peu ça. C'est pas là pour sauver le monde à coups de punchline, mais pour tenir la structure technique d'une boîte à bout de bras, dans l'ombre, mais avec une influence de géant. Mais alors, qu'est-ce qui déferencie un expert d'un leader technique ? Comment passer du clavier au mentorat sans tomber dans le piège du micromanagement, Et surtout, comment construire de l'autorité sans jamais l'imposer ? Pour répondre à ces questions de haut vol, je ne reçois pas Bruce Wayne, mais il s'y connaît en double vie entre code et influence. Emmanuel, bonjour.
Emmanuel:
Bonjour. Je pensais que tu allais dire Chuck Norris, tu vois.
Bruno:
C'est vrai que ça aurait été une bonne rêve aussi. Est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Emmanuel:
Oui, du coup, moi, je fais Emmanuel Bernard. je travaille chez Red Hat dans l'open source depuis, je crois que j'ai passé les 20 ans en 1er mai je vais faire 20 ans entre la boîte qu'il y avait avant qui s'est fait racheter donc ça fait un bail mais la plupart de mon boulot en open source est dans la communauté Java de manière générale dans ce qu'on appelle le middleware donc j'ai bossé sur, Hibernet qui est un outil de mapping objets relationnels, donc on parlait de Clivan alors dans les années 2005-2007, c'était des débats intéressants. Ensuite, j'ai aidé un certain nombre d'autres projets et puis le gros en date dernièrement, c'est Quarkus, qui est une stack applicative Java orientée développement plus moderne, microservices, mais pas que, avec une expérience à la PHP, c'est-à-dire, on change quelque chose et on rafraîchit la page du navigateur et on voit tout de suite le résultat, ce qui pour les développeurs Java est un peu alien enfin ceux qui avaient fait du play à l'époque le connaissaient mais donc on a complètement pompé ça, voilà donc j'ai fait ça j'ai fait un Kafka as a service, pour Red Hat aussi au niveau, géré par les équipes Red Hat mais pour les clients et puis je suis podcaster aussi du coup à mes temps libres un truc qui s'appelle Les Cascodeurs qui est un vieux podcast Effectivement.
Bruno:
Que tu fais sans interruption depuis presque dix ans je crois, non, quelque chose comme ça ?
Emmanuel:
Jusque dix ans, oui. On a fait le dix ans il y a quelques années maintenant. Donc je serais pu te dire... 2008-2009, je crois. L'histoire, elle est rigolote. C'est que je travaillais aux Etats-Unis et puis je voulais rentrer. Et puis j'avais l'impression d'être trop orienté. La boîte dans laquelle je travaillais, ça s'appelle J-Boss. Et je me disais, je connais les technos J-Boss, mais j'ai l'impression d'être juste dans mon microcosme. J'aimerais bien faire de la veille technologique. D'ailleurs, c'est marrant, en anglais, il n'y a pas de mot équivalent. Donc il faut le chérir, ça. Et la veille techno, je me suis dit, je vais la partager. ça doit pas être bien compliqué, et du coup les podcasts c'était vraiment les débuts des podcasts les premiers ils devaient être peut-être deux ans avant ou quelque chose comme ça c'était vraiment nouveau et du coup j'ai appelé des gens que je connaissais donc Antonio Goncalves, Guillaume Laforge et un certain nombre d'autres et j'ai dit bah je veux lancer ça ça vous dit de venir avec moi dans cette aventure et puis voilà alors il se trouve que c'est hyper long de faire un podcast là il y a plein d'outils ça s'est amélioré mais au début on faisait tout à l'huile de coude et du coup je crois que je passais 4 heures, enfin 4 fois le temps d'un épisode c'est à dire t'avais un épisode d'une heure, j'avais 4 heures de travail entre le mixage, mais en plus comme je suis un peu maniaque, il fallait que le son soit bien etc.
Bruno:
On connait donc effectivement t'as créé le podcast 10 ans que moi je crée le mien c'est ça mon référentiel des 10 ans j'ai commencé, vous aviez effectivement déjà vos 10 ans donc aujourd'hui tu as ce rôle de distinguished engineer chez Red Hat.
Emmanuel:
Ouais avant.
Bruno:
De voir comment est-ce que t'en es arrivé là est-ce que ça représente.
Emmanuel:
Ouais du.
Bruno:
Coup moi je suis curieux de savoir comment est-ce que t'as commencé comment t'es devenu développeur.
Emmanuel:
Comment je suis devenu développeur, bah c'est comme toujours je sais il faudrait que je demande à mes parents mais bon un jour un ordinateur est arrivé chez moi je devais avoir 11 ans 12 ans, et je sais que ma mère utilisait des ordinateurs parce qu'elle était dans la comptabilité et donc ce truc là arrive avec MS-DOS et puis pas grand chose et je suis assez fasciné par cet outil où on peut lui demander de faire des choses et il va le faire j'ai démarré là dessus j'ai fait mes premières bêtises là dessus en effaçant je crois le config 6 ou l'auto-exec en fait il y avait ce je faisais dire et puis il y avait point et point point et j'étais là c'est nul donc j'ai effacé point point parce que ça m'énervait bon bah il se trouve qu'à la racine il y avait des outils assez utiles et donc je vais voir mes parents je crois que j'ai cassé l'ordi ils disent t'as qu'à le réinstaller je me suis lancé là dedans. Accélère, toujours intéressé, toujours un mix entre les jeux, mais aller aussi comprendre, donc Basic, GW Basic pour ne pas le nommer, et puis Turbo Pascal, etc. Mais tout ça en deux mois même, pas via des cours ou des choses comme ça. Et puis après j'ai eu un peu de chance, j'ai fait une école d'ingénieur qui se trouve avoir une spécialité en informatique, mais c'est un peu tombé, les écoles d'ingénieur, en France on ne les choisit pas vraiment parce qu'il y a le concours. et après, voilà. Donc, c'est bien tombé. Et puis, j'ai rejoint Fnac.com pour monter le site Fnac.com. Alors, moi, en tant que junior, il y avait des cadors qui m'aidaient à le monter. Enfin, qui m'aidaient, non. Je les aidais à le monter. Et donc là, c'est du Visual Basic, c'est du SQL Server, c'est du ASP, donc pas .NET, les technos d'avant. C'est du Windows et des procédures stockées voilà et donc j'avance petit à petit voilà, Visual Basic, ce n'est pas objet, c'est très procédural. Après, on bouge, on explore .NET versus Java. On tombe sur Java. Ah tiens, il y a une autre histoire sympa. On tombe sur Java et puis on regarde JDBC. C'est bien, c'est mieux que zéro, mais c'est quand même hyper bas niveau. C'est un peu pénible de coder là-dedans. Il y a un outil pas mal qui s'appelle Toplink, qui est un outil de mapping objet relationnel qui était en corbat, je crois, avant, ou en C, et qu'ils ont porté en Java. Et ils sont super forts. On part vers ça pour le prototype et Toplink se fait racheter par Oracle. Il se trouve qu'au niveau de la stack, je crois qu'on avait décidé de prendre BEA en serveur d'application. On avait DB2 en base de données en dessous. Et donc, mon CTO dit, il y a zéro chance que je mette Oracle au milieu. Déjà ça va être le bordel à avoir géré BEA versus DB2, BEA était indépendant d'ailleurs et donc, on l'explore, on voit ce truc hibernate là un bêta quelque chose et on lui dit mais tu préfères qu'on ait pas de support et qu'on le fasse nous même que mettre Oracle au milieu, il dit oui, ok banco, du coup je me suis mis à lire en fait je me suis dit il faut que je supporte pour la boîte donc j'ai lu la doc, religieusement, je suis devenu machine à répondre sur le forum, petit à petit j'ai fait mon premier patch au sens .patch qu'on envoyait sur les mailing lists et donc le premier tu regardes et tu le relis des heures et des heures, ton premier patch public c'est toujours quelque chose, et voilà de fil en aiguille j'ai rejoint cette équipe j'ai rejoint une boîte, une start-up qui s'appelait JBoss et JBoss se fait racheter par Edat et voilà.
Bruno:
Donc dans le monde java depuis depuis.
Emmanuel:
Depuis depuis depuis depuis, 3-4, ouais.
Bruno:
Donc, aujourd'hui, sur ce rôle de Distinguished Engineer, donc ça correspond à une track plutôt technique, ça a été quoi ? T'as toujours eu cette ambition de, maîtriser cet art au sens le plus élevé du truc ? Est-ce que tu t'es essayé au management ?
Emmanuel:
J'avais pas d'ambition, mais par contre, j'ai essayé de curiosité. Donc, ouais, j'ai toujours eu. Et j'ai eu des phases de doutes à un moment, parce que tu travailles sur quelque chose et puis autant les projets, ça peut bouger, mais les produits, à un moment, il faut que quelqu'un continue à les gérer, même quand ça devient moins fun ou même juste on se fatigue 5 ans à être l'expert sur un objet de mapping or bio-relationnel, on a envie d'explorer d'autres choses. Et cette boîte elle est vraiment bien parce que en tout cas le VP, me protégeait et il laissait l'espace aux gens pour aller explorer d'autres choses donc j'ai pu lancer, explorer d'autres idées qui ont réussi et d'autres pas évidemment, et à un moment je me suis posé la question est-ce que je vais vers le manageriat ou est-ce que j'y vais pas et du coup je parle à cette personne là et il me dit. En fait c'est ça j'avais envie de démultiplier un peu mon impact, et donc il y a la voie managériale que je me disais je vois pas trop d'autres solutions et donc je lui dis je fais quoi je continue technique ou je vais manager il me dit tu pourras toujours venir manager si vraiment t'as envie et c'est ta passion de gérer l'humain mais reste en technique tu seras bien, et du coup j'ai fait confiance là dessus et j'ai avancé comme ça, par contre, pour avoir mon influence un peu plus large l'impact un peu plus large et ben il faut commencer à réfléchir à niveau derrière, la base de cote et du coup de voir un peu tiens il y a lui qui fait ça, lui qui fait ça est-ce que c'est pas dupliqué, est-ce que ça a de la valeur comment ça se connecte les uns les autres et du coup d'essayer de définir des, îlots de plus en plus large donc c'est un peu comme ça que j'ai, que ça s'est passé.
Bruno:
Est-ce que ça veut dire aussi du coup de prendre du recul vis-à-vis de la tech et d'essayer d'avoir cette vision globale sur qui fait quoi dans cet environnement technique mais du coup de moins mettre les mains dedans.
Emmanuel:
Alors il y a, de ne pas prendre du recul par rapport à la tech parce que pendant longtemps j'étais vraiment sur la tech à définir la stratégie mais au sens technique ou l'architecture au sens technique que je vais quand même appeler ça tech, par contre effectivement quand on se met à réfléchir à 2, 3, 5 produits et de voir un peu ce que tout se passe on peut moins être dans le cambouis, tous les jours sur quelque chose de moins en moins surtout parce qu'en fait on devient le point, bloquant de l'équipe parce que si on se dit tiens je prends ce sujet et puis que pendant deux mois il se passe rien en fait on gêne les autres, du coup c'est vraiment le paradoxe ou même tiens je vais revoir cette pull request on lance des commentaires et puis on s'en va donc j'ai une collègue qui nous dit faut pas lécher le cookie, ça c'est je lèche le cookie puis je me barre et du coup tout le monde est là, mince qu'est-ce qu'on fait de ces commentaires, donc Donc, il y a un travail de distance, même si c'est vraiment le cœur de ce qu'on aime faire. Que ce soit manager d'ailleurs, ou monter dans les strates techniques et avoir des choses plus larges, et tu dois avoir l'expérience aussi, c'est que la boucle de plaisir est très différente. La première, c'est... Alors moi, j'ai des phases de dépression dans mon code tant qu'il ne marche pas, et je suis là, il faut que je ne me sente pas bien avant de trouver le problème. Mais au final non ça va bien mais au milieu c'était la fin du monde mais t'as ce cycle avec la barre verte qui arrive et qui avance qui est un plaisir quasi immédiat quoi très rapide en tout cas, le plaisir si tu vois à l'extrême d'un CTO c'est qu'il a lancé des piches nettes qui un an deux ans cinq ans après font qu'on est au bon endroit versus le mauvais donc la boucle de plaisir c'est pas la même quoi voilà, Et ça, c'est une transition difficile.
Bruno:
Et tu penses avoir réussi à la mener ou tu as besoin parfois de revenir à ce plaisir d'aller se confronter à du code ?
Emmanuel:
En temps en temps, j'ai besoin de... Je t'avoue que ça m'est arrivé un peu moins là. Mais c'est pas tant... J'ai un besoin de faire. Ou de comprendre. Je sais pas, il y a un truc du... C'est pas vraiment du physique, parce que je me couperais si j'avais un cutter dans les mains, mais j'ai besoin de faire. Et ça, ça... Voilà. Quelqu'un me disait qu'il y avait des tâches qui te donnaient de l'énergie et d'autres qui t'en prenaient. Et donc, ça fait partie des tâches qui me donnent de l'énergie. Ma façon de le faire elle est, comme toi j'ai un peu pas mal scripté mon podcast alors c'est du bâche des mélanges de trucs et de machin j'ai le podcast qui me permet d'aller, d'avoir des super conversations avec des gens et de me forcer à rester, à la au niveau en tout cas à la pointe de la, pas de la connaissance mais de l'information on va dire pas pareil, information, connaissance. Voilà et par contre j'ai un doute, que je vais appeler saint mais bon après quand tu le ressens c'est pas forcément ça mais quand je rentre dans des conversations et que j'amène des hypothèses etc, je vais quand même des fois aller redemander aux gens ok t'as pensé quoi, est-ce que j'étais complètement, stratosphérique et il n'y a aucun rapport du coup j'essaie vraiment de valider que ce que j'amène c'est de la valeur même si je travaille à des couches de pensées un peu différentes de la personne qui va, concrètement implémenter telle feature je sais pas si c'est hyper clair.
Bruno:
Mais du coup ma question c'est est-ce que tu crois que c'est ça la secret sauce d'un expert.
Emmanuel:
De douter.
Bruno:
De savoir se remettre en cause en permanence.
Emmanuel:
Ouais alors c'est stressant, vraiment la vraie secret sauce c'est d'être curieux parce qu'en fait si t'es pas curieux tu te mets à rester sur tes acquis, et puis à ce moment là tu dis moi à mon époque on faisait l'architecture en trois étages, en trois tiers comme on disait et ça marchait très bien mais qu'est-ce qui se passe si tu mets un quatre tiers ah ouais c'est pas des tiers, c'est des tiers qui sont des étages, bref et du coup tu te mets à le vrai risque c'est que tu te mets à avoir des modèles mentaux, que tu vas essayer de réappliquer sur les nouvelles technos et à un moment, tout modèle est imparfait par rapport à la réalité y compris notre façon de penser mais si tu restes figé tu vas t'éloigner de plus en plus et tu vas croire que tu, es encore à la page alors que plus du tout du coup ça c'est le truc qui me fait vraiment peur et c'est pour ça que je creuse et je suis curieux et je veux comprendre en fait.
Bruno:
Mais en même temps, vu ton rôle, quand un développeur ou une développeuse junior vient te voir, c'est parce qu'ils savent, certes que tu as de l'expérience, mais que tu as aussi des convictions. Et comment tu doses cette notion entre la conviction et l'incertitude ?
Emmanuel:
Ouais, ça c'est un... Alors, déjà, comme je doute moi-même, je me mets dans les baskets de l'autre personne et de ses arguments. J'arrive vraiment à être à être limite convaincu de l'autre argument et après revenir à mon argument et de faire ça donc ça c'est important de pas dire c'est mon idée et du coup c'est la bonne donc il faut se séparer, ça c'est un travail de développement personnel mais on n'est pas son idée on n'est pas, on n'est pas son code ça c'est hyper important et ça vous permet de vivre super bien quand des choses évoluent donc ça c'est le premier truc et le deuxième c'est que je, vais essayer de demander aux gens, en fait tu prends ce choix là je vais pas forcément donner mon choix d'ailleurs initialement je vais attendre mais même si je le donne à un moment je dis voilà mes arguments mais toi quels sont tes arguments et du coup on va aller creuser, et souvent on va me dire ça fait peur. Et souvent on va tomber sur un truc et oui mais moi j'ai fait ça à cause de, de telle raison que je pense être importante et là on dit ah ok est-ce que je suis d'accord avec cette décision là ou est-ce que je suis pas d'accord si je suis pas d'accord c'est que je lui ai pas donné les conditions initiales, les objectifs initiaux qui sont super corrects donc je vais aller reculer d'un cran réfléchir au pourquoi ou quelle est ma condition vraiment importante est-ce que c'est la perf plutôt que la tiens on prenait l'exemple de Kafka as a service, c'était plutôt, c'est censé marcher oui mais quand ça marche pas qu'est-ce qu'on fait donc moi j'avais ce marteau là où je leur posais toujours les questions, oui mais qu'est-ce qui se passe si on débranche ceci et cela, du coup c'était, et après je leur expliquais voilà ça c'est mon objectif, après comment vous le résolvez, je suis prêt à on va négocier et ça va bien se passer donc il y a vraiment des, des, qu'on appelle ça des collines sur lesquelles tu décides de mourir et d'autres pas donc t'en as où c'est des choix stratégiques tu sens que t'as quand même souvent des silos dans des décisions ou dans des choix donc quand tu veux aller au-delà tu vas peut-être avoir une raison stratégique que tu peux décrire mais qui va pas forcément être comprise ou acceptée, elle peut être entendue tout en n'étant pas d'accord ça serait l'idéal en termes de décision s'il y a... Pas incohérence, mais s'il y a disagreement.
Bruno:
Désolé, j'ai le mot anglais qui vient. Mais ce qui est intéressant aussi dans l'axe que tu prends, c'est qu'au final, la fameuse colline sur laquelle tu décides de mourir ou pas, au final, c'est pas une colline technique. Toi, tu dis pas, ta colline, c'est pas de dire Java est de la meilleure techno. C'est que tu choisis de dire, moi, mon focus en ce moment, c'est que ça fonctionne, même quand on débranche tout, ou c'est de dire, je veux que mon code il fonctionne dans 10 ans.
Emmanuel:
Tu fais des choix.
Bruno:
Qui sont très stratégiques au final.
Emmanuel:
Ouais mais des fois ça peut être quand même un choix technique je vais te donner un exemple j'espère qu'il y a prescription maintenant mais, pour ceux qui font du Kubernetes et des opérateurs la plupart sont écrits en Go et Go c'est super bien tu peux décrire les structures qui représentent ton JSON ou ton YAML pardon. Nativement, et les gens qui écrivent en Go, du coup, ont moins fait l'effort d'avoir un SDK multilangage en fait. Il y en a, mais c'est toujours un peu à la traîne, etc. Et on sort Quarkus qui, en termes de consommation mémoire, de temps de démarrage, est comparable à une application en Go, on voyait beaucoup d'utilisateurs et de clients qui partaient de Java et qui allaient vers d'autres langages, soit du Node, soit du Go, etc. Donc Quarkus est là pour adresser ce problème-là, et puis on se dit, notre boîte, elle est basée sur Kubernetes, OpenShift en l'occurrence, on veut que Quarkus puisse écrire des opérateurs. Donc à un moment, je vais voir l'équipe et je leur dis, écoutez, il y a l'équipe Quarkus qui a écrit le SDK pour... Qui a écrit et intégré le SDK pour faire des opérateurs, ça serait bien d'écrire votre opérateur en Java, comme ça, ils apprennent de votre expérience, vous aider à faire monter la techno, et puis, comme stratégiquement, c'est ce qu'on veut pousser, ça serait bien. En même temps, c'est une décision qui n'a pas de sens techniquement, ça serait plus simple de juste prendre le go et de le faire en go, leur opérateur, ils ont Stack Overflow à gogo, et celui-là, c'est un de ceux où je suis le moins fier, qui a été vraiment compliqué pour moi, de faire ce choix. J'ai ce qu'on appelle. Le marteau du leader. Des fois, je dis décision arbitraire, désolé, je la fais. Celle-là, elle m'a retourné le ventre.
Bruno:
Et en même temps, j'ai peut-être pas bien compris l'histoire, mais tu décris quand même ce qui t'a amené à prendre cette décision-là. Ce n'était pas de dire Java est la meilleure techno à tout prix, c'est qu'il y avait une volonté de faire monter en compétence d'autres personnes et de mettre en avant-prix.
Emmanuel:
Il y avait une optimisation de ce qu'on appelait le portfolio, nous. C'est-à-dire de la stack globale Red Hat entière.
Bruno:
Donc, tu vois, tu es quand même sur un truc un peu stratégique de se dire, le choix n'est pas tant technique, c'est juste que, ça s'inscrit dans une stratégie globale, il y a un objectif qui est donné et en fait, on choisit le bon outil dans cette stratégie-là et si effectivement tu veux limiter les techno, même si les gens te disent que je n'arrivais pas la bonne techno oui mais en fait comme on ne veut pas en avoir 22 on reste sur du genre.
Emmanuel:
Il y a ça et il y a parce qu'en fait c'est un bon un bon point c'est que, pour justement ça peut s'appeler staff engineer d'ailleurs ou distinguished engineer le point c'est qu'il faut quand même bien comprendre le métier et comprendre ce qui empêche le CEO de dormir la nuit, de bien comprendre ça et d'essayer de voir comment techniquement on peut aider à à faire la différence, à faire de l'impact. Du coup, bien comprendre la stratégie, cela faire comprendre, aller questionner, aller les embêter si c'est flou, ce qui est souvent le cas initialement, c'est hyper important.
Bruno:
C'est quoi donc le rôle d'un Distinguished Engineer au quotidien ?
Emmanuel:
Quotidien, c'est beaucoup de parler aux gens. Parce qu'en fait, il y a non seulement d'aller... C'est beaucoup d'absorber ce qui se passe pour savoir où ça va, où chaque équipe va. Ensuite, il y a beaucoup de parler aux gens parce qu'il peut y avoir des gens qui ont des demandes sur toi. Alors ça peut être technique, mais ça peut être aussi, j'ai pas trop envie d'en parler aux managers, mais voilà ce que voilà. Du coup, il y a un mentorat très humain aussi là dedans. Et puis c'est il y en a qui peuvent rester en boucle comme ça un pour un, en conversation une à une tu vois le problème c'est que moi je préfère passer à l'échelle donc j'ai tendance à écouter comme ça mais en général retranscrire par un email à des gens plus larges en généralisant le problème c'est ma façon d'amorcer la pompe de la culture d'accord je vais pousser ça je demande aux gens d'arrêter de Slack en tout cas de résumer ça au moins dans un email, voire dans un document qui peut être lu un an après pour se rappeler de ce qui se passe, j'ai des opinions là-dessus. Et puis l'autre truc du Distinguish Engineer c'est qu'il n'y a pas vraiment grand monde qui peut lui dire quoi faire, t'as peut-être le CEO qui dit, moi j'ai tel problème ou le CTO qui dit, j'ai tel problème est-ce que tu peux aider mais à un moment, c'est à toi de trouver les points où tu penses qu'il y a un problème ou que quelque chose doit être amélioré et donc c'est souvent en regardant un petit peu les différentes équipes de voir qu'il y a des silos, qu'il y a peut-être des trous, justement des sujets qui ne sont pas pris parce que justement c'est entre deux silos, et d'aller pousser le sujet, avec ton sourire parce que tu n'as pas forcément d'équipe mais il va falloir convaincre les gens de bosser un peu à la marge ou pas à la marge d'ailleurs pour toi de convaincre d'investir là-dessus donc soit le product manager soit les équipes techniques soit voilà.
Bruno:
Est-ce que ça veut dire que tu passes beaucoup de temps en réunion ou au final c'est quand tu parles de discussion comme ça en one to one c'est de la réunion qui est programmée qui est récurrente ou c'est ça passe par beaucoup d'informel.
Emmanuel:
Je vois pas trop la différence en fait.
Bruno:
Pour moi l'informel c'est en gros tu te balades dans les bureaux et tu discutes avec les gens et t'échanges et tu découvres un peu sur quoi les gens font le one to one c'est on a chacun un créneau de notre agenda qui est prévu pour on a un ordre du jour un objectif.
Emmanuel:
Alors j'adorerais me balader dans les bureaux sauf que nous il y a des gens aux US des gens en Europe un peu partout donc je peux pas mais du coup, nous on était déjà en mode Covid avant le Covid de par la nature de la boîte et des équipes, donc ce que j'avais c'était déjà je me gardais un jardin secret. C'est-à-dire que à un moment, tu peux faire tes 10 heures de réunion par jour, et moi, j'ai besoin de temps d'absorber, d'écrire, de penser à d'autres choses. Du coup, j'essayais de limiter. Mes matinées en Europe étaient plutôt protégées. Les après-midi, c'est le bordel parce que t'as l'Europe et les Etats-Unis en même temps. Donc juste, petit conseil, ne faites jamais un Européen qui gère des équipes en Asie et aux Etats-Unis parce qu'en fait, il n'a plus de vie après. Donc il y a des burn-out qui arrivent. Donc je me protégeais quand même du temps. Mais sinon, j'avais du 1 à 1 avec un certain nombre de gens que je limitais à peut-être 10 personnes max. Parce qu'en fait, 10 personnes max, une demi-heure et toutes les semaines. Je crois que c'est les outils du manager. Il y a un podcast sur les trucs managériels. Je ne sais pas s'il le continue, mais il y a des trucs intéressants sur le one-on-one qui dit qu'il vaut mieux le faire de manière fréquente pour éviter des interruptions en dehors des moments où on se réunit. Du coup, on écrit les points dont on veut échanger et puis on y va. Donc, il y a CA1 qui ne sont pas formels, qui sont plutôt, vas-y, dis-moi ce que tu as sur le cœur, moi, je te dis ce que j'ai comme sujet et puis on voit. Donc, ça, ce n'est pas du tout cadré. Ceux qui sont cadrés, c'est quand tu as des réunions à 3, 4, 10 personnes ou plus, parce que là tu te dis mince on perd vachement de temps potentiellement donc là j'ai tendance à animer donc le podcast ça aide mais j'ai tendance à animer les meetings en disant voilà l'agenda on peut le faire évoluer mais voilà en gros on va se donner, 12 minutes et 30 secondes sur celui-là, ensuite sur ça un parking lot et du coup là je suis assez rythmé et je, j'ai un don, j'arrive à écouter et écrire en même temps ce qui fait que pendant longtemps je prenais moi-même les notes maintenant il y a, on essaie de faire des rotations qu'il y ait des gens qui prennent ce lead là aussi mais du coup à la fin tu n'es pas obligé de réécouter l'enregistrement juste avec les notes tu as déjà beaucoup d'informations voilà.
Bruno:
Ce qui est intéressant aussi dans ce planning que tu donnes, c'est qu'à aucun moment tu as parlé d'écrire du code, tu as parlé d'aucun aspect de techno et pourtant tu es sur un niveau d'expertise technique qui fait que tu as quand même besoin aussi de t'enrichir techniquement parce que tu n'arrives pas à ce niveau-là, juste en discutant avec des gens de la pluie et du beau temps.
Emmanuel:
Oui, mais après, tu vois, une des grosses réunions, une des grosses trucs que j'ai fait, c'est de créer, animer une communauté d'architectes dans la boîte, notamment quand on faisait le Kafka Manager. Donc, cette communauté d'architectes En fait c'était ouvert à tout le monde en vrai, mais après j'avais besoin de gens avec qui j'étais sûr qu'ils allaient venir tout le temps. Et donc il y a une mailing liste. Idéal. Après, il y a une réunion toutes les semaines de trois quarts d'heure, une heure, où on met des sujets. Mais tout ce qu'on peut traiter dans la mailing list, c'est mieux parce que tout le monde peut le prendre au moment où il est réveillé et actif. Les réunions, c'est un peu plus problématique. Donc, c'est vraiment pour débloquer des choses. Mais ça peut être des sujets très techniques. Et moi, ce que je faisais, c'est que j'étais dans toutes les mailing lists possibles et imaginables. Alors les slacks c'est là où j'atteins ma limite c'est que tu peux pas suivre des conversations où il y a la pluie et le beau temps mélangé à une décision technique c'est le bordel et après j'étais là, ah ça c'est un super sujet je pense qu'il faut le faire remonter pour que les autres apprennent, et moi aussi ou alors quand je vois un truc où je me dis, mes spider sense ils commencent à avoir un peu des doutes c'est là où je vais venir je vais dire vas-y explique moi, comment ça se passe, quelle était la décision pourquoi vous êtes arrivés à ça et donc je joue, je joue le naïf ou l'idiot, non pas l'idiot mais la personne naïf curieuse et en fait ce qui va se passer, si t'arrives bien et si l'autre personne est ouverte c'est qu'elle va t'expliquer les raisons et après elle va peut-être se dire c'était peut-être pas forcément le bon choix ou alors toi tu vas être convaincu que le choix il est correct, parmi les contraintes que toi tu sais avoir voilà donc ça ça te permet d'aller quand même zoomer.
Bruno:
Techniquement sur les trucs tu joues le rôle du rubber duck pour tout le monde je.
Emmanuel:
Suis payé beaucoup plus cher qu'un rubber duck donc peut-être qu'il faudrait optimiser sauf que le rubber duck le.
Bruno:
Il ne te renvoie rien, le rubber doc ?
Emmanuel:
Alors, le rubber doc, déjà, il ne te renvoie rien. Et ensuite, il faut faire la démarche. C'est-à-dire qu'il faut se dire qu'on a un problème. D'accord ? Ce qui n'est pas forcément le cas. Donc là, il faut aussi peut-être amener les gens à se dire est-ce que tu es sûr que c'est la bonne décision ? Est-ce qu'on a un problème ou pas ? Et c'est là où avoir... On en parlait un petit peu, mais d'avoir une connaissance vraiment d'un peu de généralisme technique d'un peu toutes les couches. Alors, je ne saurais pas t'optimiser un switch, mais on en parlait là je sais faire la différence entre TCP et UDP et ce que ça veut dire, du coup peut-être que ça a aucun intérêt ou il se trouve que dans le Kafka as a service il y avait un proxy et qu'il y avait des conversations un peu autour de ça j'ai pas besoin de tout savoir mais j'ai une culture assez générale pour et assez sur les fondamentaux pour pouvoir me dire mais est-ce que ça a du sens, et du coup au moins de poser les bonnes questions pour faire avancer les sujets, et pareil, retour, demander aux gens comment vous avez vu, est-ce que ça a de la valeur ce meeting ou pas et bon, c'était plutôt positif à ces moments là en tout cas.
Bruno:
T'évoquais juste avant le fait que tu vas voir des gens, tu leur poses des questions parce que t'as besoin de comprendre un truc et du coup ça leur permet effectivement de jouer des choses mais c'est aussi que les gens, sachent quand venir te voir comment tu fais justement pour créer cette zone d'influence et que les gens sachent qu'ils peuvent venir te voir, et en même temps de pas non plus que attendre qu'ils viennent te voir parce que parfois si les gens viennent pas te voir c'est peut-être que justement ils sont en train de cacher quelque chose, tu sais ce qu'on dit, je sais pas si c'était tes parents aussi mais quand t'entends plus tes enfants c'est là où il faut s'inquiéter c'est ça euh.
Emmanuel:
Déjà, c'est un travail constant, parce que je ne sais pas pourquoi, mais en tout cas, les humains qui sont aussi informaticiens, ils ont tendance à ne pas forcément vouloir sortir et poser des questions. La curiosité, c'est vraiment à chérir. Et après, il peut y avoir la curiosité un peu pénible où les gens posent 5 milliards de questions et tu n'apprends pas. Mais il y a la curiosité qui en fait en vrai fait avancer tout le monde quand je pose une question dans une réunion des fois je connais la réponse mais je sais que il y a plein de gens qui n'ont pas forcément suivi l'enchaînement de conversations du coup je vais la poser et ça, je ne sais pas combien de fois, les gens qui écoutent là vous vous êtes retrouvés dans une réunion et quelqu'un disait quelque chose vous vous dites oh là là ça a l'air très compliqué ça a l'air très avancé mais je ne sais pas trop j'espère que, je comprendrai plus tard et en fait non c'est maintenant qu'il faut comprendre et, ça se trouve c'est du bullshit aussi et en fait ce qu'on voit c'est que souvent, les experts ils sont pas si experts que ça faut vraiment aller à on s'appelle ça au first principle comme ils disent en anglais d'aller creuser et du coup tout le monde s'élève dans la conversation du coup j'ai oublié ta question c'était.
Bruno:
Comment tu fais pour créer ta zone d'influence.
Emmanuel:
Pour savoir.
Bruno:
Ce que les gens font et aussi que les gens sachent quand venir te voir.
Emmanuel:
Déjà, il ne faut pas être le tyran. Ça aide d'être quelqu'un d'ouvert. Mon calendrier est ouvert. J'ai un calendrier où il y a tout affiché. Ils peuvent dire, c'est hyper important, est-ce que je peux passer par-dessus tel rendez-vous ? Ça, c'est un premier truc. De montrer, de ne pas être dans le jugement, de ne pas être dans je suis plus fort que toi, je suis au-dessus de toi, du coup, c'est moi qui prends la décision. D'être vraiment dans le mode je suis là pour vous aider et d'essayer d'amener de la valeur. Une fois que tu as ça, déjà, il y a plein de gens qui vont être plus enclins à te dire quand quelque chose ne se passe pas très bien. Genre, tiens, ça peut être... Tu vois, l'exemple que j'ai, on avait à un moment un truc pour vérifier qu'on faisait pas 5000 fois les mêmes choses donc on avait des projets enfin on déclarait les projets qu'on démarrait des choses comme ça il se trouve que c'est devenu beaucoup trop. Fastidieux procédural c'est devenu j'ai plus les mots là mais ça servait vraiment, ça amenait beaucoup plus de négatif que de positif du coup personne va rien te dire parce que t'es le bras droit du boss, sauf si t'as amené cette culture d'être ouvert, d'entendre et de dire merci du feedback, peut-être je peux pas réagir tout de suite mais voilà ce que je vais essayer d'y penser dans les X temps donc il y a ça et l'autre, façon c'est que naturellement les gens ne vont pas forcément tout te dire du coup faut aller zoomer, faut aller plonger dans une équipe, à l'époque où les gens utilisaient des mailing lists c'est beaucoup plus pratique parce que tu peux tu peux voir les choses poser les questions ou voir des signaux faibles le 1 à 1 c'est un très bon outil pour justement dire tiens il y a tel sujet qui m'intéresse en général vous avez eu des problèmes de ce type là et là bah ouais effectivement il y a eu ça et du coup de sortir des sujets, que moi je vais généraliser derrière tu vois genre j'ai eu un feedback super intéressant alors je vais pas forcément nommer la personne ça dépend c'est positif négatif etc et. J'écrivais des trucs que j'appelais des mémos. C'est-à-dire, la philosophie du projet, c'est quand j'étais sur Quarkus, c'était ça. J'écrivais des philosophies du projet, je faisais beaucoup de rappels, genre des API simples et utilisables, la consistance de la configuration, parce que c'est tellement facile de se dire, ah ouais, c'est un peu compliqué là, juste pour cette extension, pour ce plugin, je vais le faire différemment. Donc rappeler aux gens ça et de leur donner la compréhension du pourquoi les principes généraux ce qui fait qu'ils sont autonomes pour prendre les bonnes décisions et après il faut faire confiance aussi.
Bruno:
Sur ton rôle de distinguished engineer t'as pas de management, t'as pas de gens qui te reportent.
Emmanuel:
Directement il y en a mais nous on essaye de séparer vraiment le track.
Bruno:
Donc ces fameux 1-1 que tu fais comment tu choisis ces gens chaque semaine tu vois des gens différents et du coup tu vois les gens une fois par mois.
Emmanuel:
Non moi j'essaie de en fait tu te crées un réseau tu te dis voilà, il se trouve qu'après je les reproduis dans un truc un peu plus structuré mais à la base tu te dis ok je pense que cette personne c'est un agent affluent ou c'est, quelqu'un qui peut aider, l'agent du changement ils appellent ça dans certaines littératures et donc tu te connectes à ces gens-là et s'ils sont au cas de passer une demi-heure avec toi toutes les semaines c'est là où tu peux te connecter mais c'est à toi de faire ton marché il y a des gens techniques mais il va y avoir aussi peut-être des gens du marketing, de la vente ou des execs pour recevoir aussi les contraintes business sinon tu restes que dans ta partie tech.
Bruno:
Tu as évoqué aussi tout à l'heure tu as parlé de TCP et UDP en référence à une conversation qu'on a eue avant de commencer l'enregistrement, sur ces tracks d'expertise technique je sais pas, donc aujourd'hui t'es senior d'East Equation Engineer je sais pas si c'est le grade le plus haut qu'on peut.
Emmanuel:
Il y a un truc qui s'appelle fellow que personne n'a aujourd'hui alors maintenant on peut plus faire ce genre de référence mais il y a un moment il y a une grille assez claire de voilà ce que tu dois être capable de faire, pour commencer ton package de promotion alors c'est pas suffisant mais c'est nécessaire et donc dans Fello il y en avait un où il y avait marqué marche sur l'eau c'est une référence sympa mais on peut plus trop faire en tout cas dans les boîtes américaines.
Bruno:
Ma question c'était t'étais sur un niveau d'expertise technique, il y a une complexité dans notre métier c'est que, j'ai essayé de formuler ma question mais c'est parce que devenir expert technique d'un sujet c'est à dire qu'en fait t'es de plus en plus expert du sujet, sauf que dans notre métier pour être de plus en plus expert d'un sujet en fait faut être de plus en plus expert de plein de sujets différents, on parle effectivement de TCP et UDP, tu peux pas être un expert Java sans connaître effectivement la différence entre TCP et UDP, parce qu'il y a forcément un moment ça va popper quelque part mais pourtant, il y a un côté réseau il y a un côté java c'est des métiers très différents comment tu comment tu gères la précision de ton expertise et en même temps l'ouverture de ton expertise.
Emmanuel:
C'est au feeling en vrai, tu vois par exemple si tu me poses des questions ne serait-ce qu'un peu trop, juste au dessus de basique sur le front, tu vas voir que j'ai des limites à mon expertise très fortes après il se trouve je suis dans une boîte le middleware où c'est pas ça qu'on va vraiment pousser donc, il y a un peu au feeling il y a un moment si ton moteur de curiosité est assez fort il y a plein de choses que tu vas vouloir comprendre par exemple Kubernetes ce truc. Je dis pas ça négativement mais c'est un monstre de complexité je sais pas comment un jeune qui arrive de l'école il faut qu'il ait un langage, une stack il apprenne les architectures microservices qu'ils sachent Kubernetes et les, 10 abstractions clés, sans parler des autres trucs au-dessus donc je sais même pas comment ils font les gens maintenant, moi j'ai eu la chance de grossir ça graduellement entre guillemets, donc il y a vraiment un côté curiosité qui va t'amener puis il y a des choses que tu vas devoir dropper ou tu vas savoir que telle autre personne elle est bien plus efficace là-dessus du coup, je sais pas moi par exemple le réactif c'est pas trop mon truc mais il y a quelqu'un qui est brillant avec qui je travaille et du coup, bah vas-y hein tiens voilà le tampon pour signer, d'ailleurs on signe pas mais voilà, c'est un des trucs que je déteste c'est les gens qui disent, mon ADR a été la liste des gens qui doivent signer une ADR je me suis battu contre ça et les gens avaient de la résistance mais je trouve ça, il n'y a pas de raison que moi j'ai une valeur supérieure à l'autre c'est le collectif.
Bruno:
Oui mais t'es quand même censé être le sachant donc on peut dire qu'en gros ta signature elle vaut peut-être deux ou trois signatures d'autres personnes.
Emmanuel:
Ça peut parce que je suis pas le sachant par contre j'ai du contexte, que les autres n'ont pas forcément à avoir. Je pense qu'il y a ça, et après, on n'en va pas trop parler encore, mais il y a toute la partie soft skill, qui est un truc qu'il se trouve que j'ai développé autour du Covid, où j'ai fait une belle accélération là-dessus. J'ai eu la chance d'avoir des programmes pour m'aider là-dessus. Et ça, c'est hyper utile, parce que si tu as des bases fonctionnelles, techniques, assez bonnes, que t'es ok que t'as passé ce niveau où t'es ok de déléguer des choses et que justement il va y avoir des décisions qui seront pas les tiennes seront peut-être pas aux petits oignons comme t'aurais fait mais au final qui vont faire le job t'as passé ça après si t'amènes les soft skills les skills humaines quoi là tu peux avoir une grosse influence sur, alors soit l'échec soit le succès de la boîte.
Bruno:
Ce qui est marrant c'est que tu décris comme un set de compétences qui est très proche du set de skill d'un CTO. Là, tu évoques comment déléguer la décision, ce qui fait aussi partie du rôle du CTO, c'est comment s'assurer que ton équipe est capable de prendre des décisions. En général, les managers sont là pour faire en sorte que les gens soient en mesure de faire et le CTO est là pour faire en sorte que les managers soient capables de prendre des décisions pour qu'ils puissent donner les gens. Donc toi, tu es aussi dans cette optique de pas seulement laisser les gens faire mais aussi de laisser les moyens aux gens de prendre leurs décisions tout seul.
Emmanuel:
Ouais en tout cas c'est la seule façon que j'ai vu pour ce qu'elle est tu vois quand on dit tu veux être un 10x engineer ou un 100x engineer soit t'es 100 fois plus rapide que les autres ou t'es 100 fois plus brillant mais c'est fatiguant au bout d'un moment, soit ce que j'utilise tu vois beaucoup de gens au bout d'un moment qui font des mouvements brogniens donc ils vont tous dans une direction mais globalement quand tu regardes le système ça n'avance pas, si tu arrives à diriger les molécules plus ou moins dans la bonne direction, bah là t'as un effet levier fort, donc voilà, ça fait partie de ces c'est comme ça que je, je ressens l'utilité de tout ce que je.
Bruno:
Fais Et comment tu fais pour bien déléguer ?
Emmanuel:
Comment je fais pour bien déléguer ? Il y a déjà juste une différence avec le CTO, c'est que moi j'ai pas de budget et du coup j'ai pas de gens en dessous de moi non plus, c'est pas beaucoup mais j'imagine que c'est aussi une bonne partie du travail un peu pénible d'ailleurs je pense mais voilà, alors comment est-ce que tu fais pour bien déléguer, il faut euh, Je pense qu'il faut apprendre à se connaître. Donc, il y a du travail personnel. Tu vas aller méditer sur une montagne. J'en sais rien.
Bruno:
Avant de marcher sur l'eau, ça.
Emmanuel:
Oui, avant de marcher. Dans le désert, 40 jours. Non, mais il y a... Parce qu'en fait, tant que t'es attaché... Tant qu'il y a des choses qui te font bouillir pour une raison ou une autre, tant que t'es attaché aux décisions techniques, par exemple, etc., ça va être compliqué de déléguer donc tu peux voir ces choses là et le voir comme il y a un truc en moi qui gratte, d'où est-ce que ça vient ou comment est-ce que je peux m'en détacher si je peux donc il y a ce travail là, et une fois que tu as, il ne faut pas non plus être le bouddha mais une fois que tu as un certain niveau du coup tu vas ça va être moins, ça va faire moins mal de déléguer en tout cas si tu es très, protecteur de tes décisions comme certains techniques peuvent l'être, donc il y a ça il y a. Il y a l'outil dont je te parlais un peu avant c'est à dire que tu vas dire tiens ok t'as pris cette, vous recommandez d'aller dans cette direction moi il y a des trucs qui me titillent du coup je vais me poser je vais réfléchir, je vais écrire voilà pourquoi ça me titille, voilà où j'irai et puis ensuite on commence une conversation. Et du coup quand tu entends un contre-argument qui rentre pas dans ton cadre de pensée il faut reculer les 5 why de Simon Sinek c'est un nom comme ça, donc t'es pas obligé d'aller aux 5 pourquoi mais tu recules de 1, 2, 3 pour avoir la vlugoba qui est ton travail à ton niveau là, à ton niveau à toi, et les gens ayant ce cadre là vont pouvoir, s'épanouir et prendre la meilleure décision avec plus de connaissances que toi de toute façon, dans leur environnement. Écrire ça, avoir une stratégie hyper claire, c'est hyper dur. C'est hyper agonisant. Donc, je respecte totalement les CEOs qui ont des stratégies assez claires et qui n'est pas bullshit, je pense, d'un endroit à l'autre. Et alors, en général, enfin, pas en général, mais dans certaines boîtes, les execs, ils peuvent être très, très bons. Et après, la difficulté, c'est de... Cette stratégie au niveau, expliquée au niveau, elle reste trop au niveau. Donc il va falloir la décliner sur un département, sur une équipe, sur la sous-partie de l'équipe. Et souvent, c'est là où ça se perd. Et c'est là où, en tant qu'électron libre qui est un petit peu, je ne sais pas trop où le placer, tu peux aller aider un manager individuel, un directeur ou un VP pour aider à clarifier ça ou à remonter les problèmes.
Bruno:
Tu parles donc de prendre du recul avec ces fameux 5 why même si tu peux en faire moins, mais avec justement tous ces pas en arrière que tu prends, est-ce que t'as encore vraiment besoin toi de savoir coder est-ce que c'est nécessaire que toi tu connaisses tes dernières fonctionnalités d'un framework ou d'une techno en particulier parce qu'en fait t'es tellement dans cette vision globale et stratégique t'as peut-être plus forcément besoin d'avoir cette expertise, hyper fraîche, en fait, du sujet.
Emmanuel:
Ouais. De toute façon, ce qu'on a vu, c'est que tu ne peux pas tout connaître, quoi. Donc, il y a des trucs qui vont être d'où tu viens, et du coup, tu vas avoir une expertise qui va être de plus en plus vieille au fur et à mesure, sauf si tu continues à la rafraîchir, mais à un moment, il faut accepter... Et c'est hyper dur, en fait, mais je... En fait, à part demander aux gens et d'essayer d'avoir un retour honnête, ce qui est difficile, tu vois, les gens, ils n'aiment pas faire mal aux gens. Enfin, la plupart n'aiment pas faire mal aux gens, donc ils vont te donner des trucs. Ah si, en fait, c'était peut-être intéressant parce que bon, il faut essayer de voir le retour, mais tu... Non, tu connaîtras... Enfin, à un moment, il n'y a que 24 heures par jour, donc voilà.
Bruno:
Alors du coup, pour poser la question de manière un peu provocante, est-ce que tu penses que t'es parmi les meilleurs codeurs de Red Hat, ou est-ce qu'au final il y a des gens qui sont sur des grades inférieurs, ou plus jeunes plutôt pour le dire comme ça, qui sont de meilleurs codeurs que toi ?
Emmanuel:
Ouais bah t'as le tu vois le mec qui lead GCC je sais pas faire ce qu'il fait, donc déjà il y a des spécialités différentes, ensuite il y a des même dans ta spécialité à toi il y a, tu vois Quarkus par exemple, on était deux co-lead, et mon co-lead il était plus sur la couche basse donc lui il pouvait expliquer pour le coup comment marcher un switch le réseau etc et moi j'ai beaucoup travaillé la pureté des API l'expérience utilisateur etc du coup on se complétait pas mal on se parlait 3 fois par jour, et on se déléguait les choses quoi du coup à un moment chacun sa spécialité et donc non, je crois pas qu'il y ait de meilleurs codeurs, en fait c'est pas le super-héros que t'as expliqué en introduction, ça existe pas vraiment c'est juste quelqu'un qui, accepte de prendre un rôle différent et qui peut rendre la plupart des autres très malheureux en fait, donc je sais que tout le monde veut être, monté en grade ou être promu, etc mais moi il y a un moment où justement quand je suis devenu distinguished engineer, ça m'a vachement apaisé là-dessus. Et après moi le premier conseil que j'avais sur les gens qui disaient je suis ambitieux c'est ok mais c'est pas le même job quoi, donc peut-être que tu vas l'aimer mais peut-être c'est pas le moment aujourd'hui, peut-être c'est le moment peut-être c'est pas le moment et ça sera peut-être le moment dans 5 ans ou ça sera peut-être le moment jamais quoi, moi je le vois vraiment comme des jobs assez différents en vrai, comme CTO versus fronton de développeur quoi tu peux le faire mais t'es pas, je sais plus c'est pas Sylvain qui disait si c'est Sylvain qui disait il faut, il faut quand même avoir touché un peu à tout, et après évidemment tu ne vas pas être expert donc il va y avoir des gens qui vont être bien meilleurs que toi à faire un truc rac, mais tu aurais réussi à écrire le truc du début à la fin, en tout cas dans l'approche PIOC, A priori.
Bruno:
Tout le monde n'est pas d'Inseguition Engineer chez Red Hat vous êtes assez peu nombreux, je ne sais pas combien vous êtes mais est-ce qu'il y a une forme de solitude ? Est-ce que tu as des paires avec qui tu peux échanger sur ce rôle-là, sur les difficultés, sur comment ?
Emmanuel:
Oui, c'est une bonne question. En fait, ça a vachement évolué en 10 ans pour nous. Avant, Distinguish Engineer, tu étais le meilleur dans la partie avant-droite de GCC. Tu avais 10 lignes de code dans le kernel Linux c'était toi l'expert donc c'était juste vraiment une promotion au sens tu gagnais plus d'argent, et puis ils ont voulu créer une notion de communauté pour que ces gens là se mettent à travailler ensemble et prennent la stratégie, proposée par les execs alors déjà peut-être en proposant en partie mais surtout l'apprennent et l'essai de l'appliquer ou de dire quand ça n'a pas de sens, etc. Donc, faire un retour à ce niveau-là. Et pour ça, tu ne peux pas être tout seul. Il faut une espèce de communauté des gens qui ont cette influence sur différents îlots de cette boîte qui est grosse. Du coup, ils ont créé cette communauté et du coup, l'objectif, comment tu es promu, a aussi évolué. C'est-à-dire qu'on voulait plutôt des gens qui étaient capables de travailler en équipe, d'être curieux et d'aller au-delà de ce qu'ils connaissaient. Donc, moi, d'aller au-delà du middleware pour essayer de faire le lien par exemple entre Kubernetes et le middleware voilà donc il y a ça et puis, après c'est surtout quand tu la solitude elle est plutôt quand tu lead un projet et que t'es vraiment tout seul du coup à un moment il y a, Un peu comme je disais, il y a les silos avec des choses qui ne sont pas faites. Il y a aussi un moment des décisions où les silos de décision, il y a des trous. Et tu es le catch-all. Mais tu n'es qu'une seule personne et tu es expert en moins de choses. Du coup, c'est là, c'est des boulots un peu difficiles. Parce que tu es là, tu te dis, je ne sais pas moi fondamentalement. Donc tu essaies peut-être de rationaliser un peu les choses, de déléguer le plus que tu peux, etc. Mais à un moment il y a la solitude où est-ce qu'on va on prend telle décision ou telle autre après quand t'es co-lead c'est très compliqué aussi mais c'est une force dans ces situations là.
Bruno:
Pour terminer qu'est-ce qui te fait avancer aujourd'hui et est-ce que sur tout ta carrière ça a toujours été la même chose ou est-ce que ça a été en fonction des moments des différentes choses.
Emmanuel:
Non ça enfin je suis resté dans la même boîte longtemps mais c'était des c'est des jobs qui ont vraiment évolué, des domaines qui ont un peu bouchurecés dans le middleware, mais tu vois, j'étais contributeur sur le modèle, enfin, l'object relational mapper, ensuite j'ai fait des specs, au sens JCP, quoi, des specs publics, ensuite, j'ai commencé à définir la stratégie data pour le middleware, j'ai écrit là où on devrait aller, j'ai essayé de lancer ce produit-là, et au final, j'ai appris un truc c'est que si tu ne demandes pas aux bonnes personnes qui ont les pouvoirs de décision avant de travailler pendant des mois et des mois tu peux être hyper déçu à la fin donc là tu apprends ça du coup là tu as des moments où tu es usé, tu dis à quoi bon donc tu dis, je pose madame je cherche autre chose, voilà, tu as forcément ça après moi j'ai eu la chance de trouver des rebonds qui font que, c'est vraiment du je ne sais pas si c'est de l'opportunité il y a l'opportunité de prendre la balle au bon, mais bon, la balle, il faut qu'elle... Il y a des situations, quoi. Et ça, il y a un peu de la chance.
Bruno:
Et donc toi, aujourd'hui, ton moteur, c'est ta curiosité ? C'est ton envie d'en savoir toujours plus ?
Emmanuel:
Ouais, c'est ça. Il y a...
Bruno:
L'envie d'impact ?
Emmanuel:
Il y a construire. L'envie d'impact... En fait, c'est ça. À la base, je me suis dit, il faut que je fasse plus. En fait, je voulais faire plus, mais à un moment, effectivement, au niveau du code, avec un seul clavier, t'es limité. Et du coup, j'ai avancé comme ça. donc là j'ai l'impact que j'ai, je suis bien là en ce moment ce qui m'appelle c'est plutôt construire quand t'es bras droit quand t'es CTO ou bras droit tu construis, tu fais construire ou tu fais faire des gens qui vont faire construire donc il y a un côté un peu, détaché, distancié ouais désincarné non c'est toujours pas, mais bon c'est pas grave il y a un côté d'indirection, il y a un peu trop d'indirection donc il y a ce côté de construire quelque chose qui, je sais, qui, là, aujourd'hui me titille. Ce n'est pas urgent. Je l'écoute et puis, voilà, on voit ce qui arrivera.
Bruno:
OK. Canon. Merci beaucoup, Emmanuel, pour cette nouvelle discussion. Merci à toi.
Emmanuel:
Merci de l'avoir fait cheminer.
Bruno:
J'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu voudrais partager à l'ensemble des auditoristes ?
Emmanuel:
Je peux en faire deux ?
Bruno:
Tu peux en faire autant que tu veux. OK.
Emmanuel:
Le premier, c'est le Three Body Problem, le problème à trois corps. Alors je sais qu'il y a une série sur je sais pas quelle.
Bruno:
C'est sur Netflix.
Emmanuel:
Vous pouvez la regarder mais vous pouvez aussi lire le livre parce que ça démarre pareil et puis après ça évolue et je suis en train de lire le livre, et ce que je trouve vraiment déjà c'est très bien fait, très bien pensé et du coup il a construit un truc qui fait qu'il peut, continuer à parler de techno qui sont globalement existantes parce que je vais pas spoiler mais il y a un truc qui fait que même 100 ans dans le futur ça va pas forcément super évoluer. Et surtout, c'est un auteur chinois avec la culture chinoise. Moi, je le lis en anglais, mais la traduction, ils font des petites touches quand il y a des choses culturelles chinoises qu'on n'a pas. Et du coup, moi qui étais biberonné aux US, UK et France, c'est hyper intéressant d'aller toucher ces autres choses-là. Le premier. Et le deuxième, parce qu'on parlait des soft skills, de discuter, il y a un livre qui m'a beaucoup influencé qui s'appelle, Never Split the Difference donc ne coupez pas la poire en deux mais c'est un négociateur du FBI qui a écrit un bouquin de négociation, et donc c'est pas le truc un peu wouchi-washi, là c'est des techniques assez spécifiques et c'est vraiment bien de voir comment tu peux influencer à différents niveaux il explique un peu, pas forcément les causes scientifiques derrière mais, c'est un mix entre pratiques et... Alors utilisez-le pour le bien parce qu'on peut manipuler les gens un peu avec donc faites gaffe.
Bruno:
Ça marche. Et tu recommandes même pas les casse-codeurs ?
Emmanuel:
Ah bah si, ouais. Mais bon, je le... Ouais, si, allez.
Bruno:
Il sera de toute façon en description, bien évidemment.
Emmanuel:
Ouais, on sait ça. Il y a la vidéo, donc toi tu vis depuis le plus longtemps, mais nous on a démarré cette année donc donnez-nous du retour là-dessus.
Bruno:
Et dernière question qui est la plus importante de ce podcast, tu es plutôt espace ou tabulation ?
Emmanuel:
J'ai beaucoup réfléchi, parce que je me suis dit est-ce qu'en fait je m'en fous ou pas de ça et en fait je me suis dit non la vraie vraie question clivante, c'est Vim ou Imax et c'est clairement Vim, et en fait en vrai je crois que je préfère les espaces, donc je suis pas comme Sylvain en fait je crois que ce qui m'embête c'est la petite flèche, qui est affiché, voilà, je sais pas, ça me perturbe pour une raison ou une autre.
Bruno:
Sur Vim ou Imax, c'était quand j'ai commencé à lancer ce podcast et que j'ai essayé de trouver un gimmick, il y avait effectivement la question de Vim ou Imax, mais en fait, aujourd'hui, il y a tellement d'IDE différents, que je vois plus de gens utiliser du Visual Studio ou du JetBrains ou ce genre de choses qu'au final, Vim ou Imax, c'est moins un choix binaire aujourd'hui, le choix d'IDE, que des espaces ou tabulations où t'en as vraiment que deux.
Emmanuel:
Moi, un éditeur, s'il n'y a pas un mode VI, j'y vais pas. Du coup, VS Code, il y a VI. IntelliJ, il y a VI. Bon, Vim, il y a VI. Du coup, c'est important. À un moment, j'étais à Devox et j'ai pris la machine de mon compère quand on a fait le deep dive. À un moment, il y avait des I et des machins qui se sont baladés quand je codais sur scène.
Bruno:
Je vois. Top. Merci beaucoup Emmanuel pour cette vidéo.
Emmanuel:
Merci, c'était top.
Bruno:
Et merci à tous d'avoir assisté à cet enregistrement j'espère que peut-être qu'on a créé des vocations dans cet épisode des gens qui ont envie de devenir Distinguished Engineer mais c'est.
Emmanuel:
Pas un but en soi donc.
Bruno:
Ça se réfléchit donc n'hésitez pas aussi à contacter Emmanuel si vous voulez en savoir plus sur ce métier là ça fait aussi partie de ça il faut aller voir ses pairs pour voir un peu ce que ça peut être et si vous hésitez entre un rôle de Distinguished Engineer ou de CTO vous pouvez venir aussi me voir pour parler de la partie CTO et voir un peu ce qui vous intéresse le plus entre les deux. Donc voilà, je vous remercie beaucoup de partager ce podcast autour de vous. Je remercie aussi particulièrement Robin qui a mis un commentaire 5 étoiles sur Podcast Addict en indiquant super invités et super interviews. Donc merci beaucoup Robin pour ce commentaire 5 étoiles. Sur ce, moi je vous resouette une bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien.
