Transcription

• Speaker #0

  On imagine qu'un bon tech lead est le meilleur développeur de l'équipe, celui qui code le mieux. C'est d'ailleurs souvent lui qu'on choisit pour le poste. Pourtant, pour Sherin Khoury, être un bon tech lead, ça ne se joue pas uniquement du côté du code. L'important, c'est les interactions avec les autres devs et le lien qu'ils créent avec l'utilisateur sur le terrain. Et ces deux points-là, on ne les regarde pas assez. Sherin est principal software engineer chez Red Hat, sur le cœur d'OpenShift. Dans cet épisode, Chérie nous explique pourquoi, sur les sujets peu prioritaires, elle laisse son équipe faire des erreurs, même en voyant le problème venir. Parce que l'erreur fait apprendre plus vite qu'un conseil. Comment une réécriture techniquement irréprochable a coûté deux ans à l'équipe qui l'a menée, qu'un point important a été oublié, emmener les utilisateurs vers cette nouvelle version. Et ce que ces expériences passées en offshore lui ont appris pour réussir aujourd'hui avec des systèmes agentiques. Arriver avec la solution toute faite ne marche pas. Mieux vaut donner le contexte et construire ensemble. Et comme d'habitude, si vous n'avez pas le temps de regarder l'interview complète, nous avons préparé un guide résumé de cet épisode. Le lien est en description. Chérine, si tu devais décrire la différence entre un tech lead qui fait avancer le projet et un tech lead qui le freine mais sans savoir, c'est quoi le premier point qui te vient ?

• Speaker #1

  Alors, ce que je pense, c'est qu'un tech lead, il faut qu'il ait une vue vraiment d'ensemble. de son produit, de son projet. Et juste se focaliser sur le dev, c'est vraiment une erreur. Il faut vraiment voir la globalité. Il faut vraiment s'intéresser à plein de choses. Donc, à s'intéresser à ce qui se passe côté business, côté produit. Il faut aussi s'intéresser à ce qui se passe en opération, en production et à plein d'autres facettes du produit. De voir vraiment dans sa globalité. Si on fait vraiment un tech lead, c'est le dev uniquement. peut être vraiment à côté de la gestion ou de ce qu'un tech lead doit vraiment faire.

• Speaker #0

  Justement, tu parles uniquement du dev, on pense souvent que le tech lead, ça doit être le meilleur développeur de l'équipe. Tu en penses quoi de cette affirmation ?

• Speaker #1

  Moi, j'en suis beaucoup revenue avec l'expérience que j'ai eue. Vraiment, au début de ma carrière, j'essayais vraiment en tant que tech lead de dire, voilà, il faut que... Ce que je veux faire au niveau design, ce soit vraiment écrit noir sur blanc pour que les gens, les développeurs avec lesquels je travaille puissent le faire ou l'exécuter vraiment comme je l'ai entendu. Et finalement, je pense que c'est vraiment une erreur. Un tech lead, ça doit être quelqu'un qui doit limite influencer son équipe, certes, avoir une maîtrise technique pour pouvoir les guider. Mais ça ne doit pas forcément être celui qui doit faire, en fait. Ça ne doit pas être celui qui fait. Ça doit être celui qui les fait grandir, qui leur apprend des choses, qui écoute aussi leur retour et qui, en fait, arrive à les faire travailler en équipe, tirer profit des points forts et des points faibles de chacun pour arriver à sortir quelque chose de bien. Donc il faut qu'il puisse aussi s'appuyer sur les autres, parce que potentiellement les autres en savent plus que lui.

• Speaker #0

  Du coup, par rapport à ce que tu viens de dire, le TechKid, tu peux décrire un peu son rôle, mais il peut quand même aussi avoir le rôle de développeur, il peut avoir les deux casquettes. Si dans son rôle de développeur, il code tout lui-même, vraiment un peu en mode silo, Est-ce que, pour toi, ça allume une alarme ? Est-ce qu'il y a quelque chose qui n'est pas dans le bon sens par rapport à ce que tu dis ? Oui,

• Speaker #1

  carrément. Alors, je ne dis pas que le tech lead ne doit pas faire de dev ou ne doit pas coder. Au contraire, il doit garder ce point-là et garder cette envie, cette curiosité d'aller découvrir, d'aller mettre les mains dans le cambier, etc. Mais s'il est celui qui doit gérer tous les bugs, fixer les choses, faire ou implémenter toutes les fonctionnalités, ça veut potentiellement dire qu'il y a quelque chose qui soit ne fonctionne pas au niveau de l'équipe, il n'arrive pas à les faire... Faire travailler les développeurs ensemble, c'est quand même une de ses qualités, un de ses rôles, en fait. Ou alors que, par exemple, il faut revoir un petit peu le design du produit pour que ce soit plus facile à appréhender, plus facile à débuguer, plus facile à analyser. Et donc, du coup, c'est une des choses aussi de dire, voilà, il faut qu'il soit un facilitateur.

• Speaker #0

  D'accord. facilitateur, mais pas forcément porter son équipe.

• Speaker #1

  Dans quel sens ?

• Speaker #0

  Est-ce que tu fais une différence entre un peu support et béquille, ou d'essayer de faire grandir ? Comment tu fais la part des choses, toi ?

• Speaker #1

  Alors, moi, de mon côté, j'essaye vraiment de dire qu'il faut qu'il arrive à les faire grandir. C'est-à-dire que... Alors... C'est vrai que ce n'est pas quelque chose qui vient naturellement. Naturellement, en tant que tech lead, on se dit, je suis responsable de ce produit et de la façon dont il va grandir, comment les fonctionnalités vont vivre dedans. Alors, en fait, j'en suis revenue aussi de ça. Il faut, à mon sens, dire, voilà, il y a une fonctionnalité, je fais confiance. à quelqu'un ou à plusieurs personnes de mon équipe pour la prendre en compte. Je serai là pour donner un avis, pour donner des conseils, pour donner aussi la façon dont moi je l'implémenterai, mais ce ne sera pas forcément ça qui va être retenu. C'est-à-dire que ce travail d'équipe ou ce pair programming, par exemple, qui peut se mettre en place où on va... challenger des idées. Potentiellement, le tech lead va être surpris par les idées qui peuvent arriver dans son équipe et il faut laisser cette possibilité aux autres de s'exprimer et que potentiellement, sur certaines features, ce ne soit pas l'idée du tech lead qui prime et qui sera réellement implémentée, mais une autre. Parce que c'est potentiellement une meilleure qu'on est arrivé collectivement à monter et Même des fois, il faut autoriser les personnes de se planter. C'est-à-dire que moi, ça, c'est quelque chose que j'arrive maintenant plus à faire puisque je peux, par exemple, dire, voilà, sur certaines fonctionnalités, sur certaines choses, ça, c'est vraiment une priorité très forte et j'aimerais rester garant de ce qui va se passer ici. Mais par contre, sur d'autres qui sont par exemple moins prioritaires, on a plus de temps, elles sont moins visibles du client dans un premier temps, etc. On peut dire, voilà, l'équipe a choisi d'implémenter d'une autre manière. Je vois qu'il va y avoir un problème, je peux le signaler. Ils vont peut-être prendre en compte mon conseil et peut-être pas. Et en fait, dans ce cas, je laisse faire parce que c'est aussi un apprentissage et c'est ça aussi le rôle du tech lead. C'est pas un rôle de... c'est ma parole qui va être exécutée. Il est là pour faire grandir les autres et les autres, s'ils ne se plantent pas, ils n'apprennent pas. Et en fait, on est tous passés par là. On est tous passés par dire, il faut que je... teste un truc, que je vois que ça ne marche pas, pour que je puisse rebondir et faire autre chose.

• Speaker #0

  L'apprentissage par échec, oui, tout à fait. Alors, on va en revenir sur les risques, parce que j'ai deux, trois points que j'aimerais bien creuser avec toi. Mais juste avant, au niveau communication, comment, en tant que tech lead, par moment, tu peux avoir une position un peu délicate, notamment avec l'architecte ou d'autres décideurs techniques, CTO ou autres, dans l'entreprise. Comment tu gères un petit peu euh... ce côté gardien du temple, mais cohérence avec d'autres personnes ? Comment tu gères un peu cette communication ?

• Speaker #1

  Alors, pour moi, c'est essentiel de garder une relation vraiment très fluide avec tous les interlocuteurs. Et donc, pour moi, c'est assez important de nourrir cette relation.

• Speaker #0

  La question est vraiment sur quand tu vois en tant que tech lead quelque chose qui ne fonctionne pas, que peut-être l'architecte ne voit pas parce qu'il est un peu déconnecté du... Enfin, un peu plus loin, on va dire ça comme ça, du code réel. Comment tu gères un peu ce problème de, de temps en temps, tu peux avoir une petite bataille d'égo, quoi ?

• Speaker #1

  Oui, c'est vrai. Il y a beaucoup de batailles d'égo. Oui, c'est vrai, beaucoup avec les architectes, un petit peu aussi avec certains product managers ou product owners qui considèrent que ce que le client voudra, ce sera ça, etc. Et donc, moi, en tant que tech lead, je pense que c'est important que le tech lead s'exprime sur ces sujets-là. C'est-à-dire que l'architecte ou... où le product owner ne connaisse pas aussi ce qui se passe au cœur, comme tu l'as dit, au cœur du produit. Et ça, c'est le tech lead qui peut le remonter. Et c'est important qu'il le remonte. C'est-à-dire que souvent, moi, je sais que je l'ai aussi vécu, des situations où ça vient, les architectes disent « Ah ouais, le serverless, maintenant, les prochains microservices qu'on va faire, ça va être du serverless, etc. » Et donc, en fait, le tech lead, en fait, il a aussi un rôle à jouer. Il peut être en désaccord et dire, voilà, en fait, avez-vous pensé à ce qui va se passer quand on va devoir faire de l'observabilité là-dessus, par exemple ? Enfin, il y a plein, comme on disait, il y a plein de facettes, en fait, à considérer, ne serait-ce que notre équipe est prête à... à mettre en... à implémenter quelque chose qui réserve un reste. Est-ce que, par exemple, nos chaînes de CICD, elles sont prêtes à faire des tests dans ce sens-là ? toutes ces craintes-là qui peuvent venir, en fait, du terrain, il faut que le tech lead soit la voix de l'équipe pour les remonter. Alors, il va peut-être pas forcément avoir gain de cause à chaque fois, mais il aura au moins alerter sur des problématiques qu'il aura vues.

• Speaker #0

  C'est génial. En général, d'une façon que l'architecture n'est pas décidée par un tech lead, même s'il peut y participer, il peut y avoir aussi la gestion des risques techniques qui n'est pas dans sa bannière. Mais il peut avoir une... position où ça doit être important ? En quoi c'est un problème le fait qu'on n'inclue pas le Tech Lead dans la gestion des risques techniques ?

• Speaker #1

  Alors justement, comme on a dit, le Tech Lead, il voit des choses qui sont beaucoup plus sur le terrain, sur le produit. Et quand on ne l'inclut pas, il y a des choses qui peuvent aussi passer à l'attrape en fait. et donc on peut s'en rendre compte un peu plus tard dans le cycle de dev ou dans la préparation du produit et on va se dire ah bah tiens en fait on n'a pas vu ce point là et donc c'est important que le tech lead il ait cette relation un petit peu avec les autres membres extérieurs en fait, autres décideurs autour de l'équipe parce que ça va être lui qui va potentiellement vulgariser certaines choses, vraiment. Et donc, du coup, il faut qu'il adapte aussi son discours, sa façon de parler aux différents interlocuteurs. Il y a une partie de stratégie quand on est tech lead. Il faut savoir comment je vais discuter avec cet architecte pour faire valoir mon point, comment je vais discuter avec tel product owner pour faire valoir tel autre point. Et donc, du coup, il y a aussi de la stratégie dans un métier de tech lead.

• Speaker #0

  Et du coup, comment, au quotidien, le tech lead, il essaie d'arbitrer entre aller vite, shipper vite et, de temps en temps, ralentir pour bâtir, en fait, pour construire, pour solidifier.

• Speaker #1

  Oui.

• Speaker #0

  Cette ambivalence qui est liée à notre métier. Et comme c'est lui qui... qui reçoit cette première question. Souvent, le développeur peut arriver à TechLead en lui disant « Ok, on fait comment ? Est-ce qu'on prend le temps de mettre en place tel composant pour pouvoir livrer ? Ou est-ce qu'on livre vite comme on a fait la dernière fois parce qu'on a besoin d'aller vite ? » Et c'est lui qui est le premier à recevoir cette question. Comment il peut... Est-ce que tu as des conseils ? Est-ce que tu as des choses que tu pourrais partager pour aider ? Je trouve que c'est un point un peu pas évident, en fait.

• Speaker #1

  Oui, c'est vrai. Alors, la réponse, c'est ça dépend.

• Speaker #0

  C'est toujours ça dépend.

• Speaker #1

  C'est toujours ça dépend, exactement. Mais effectivement, je pense que d'un point de vue de TechLead, il faut en fait accepter ce jeu de... En fait, j'évalue des risques. En fait, on va voir un certain problème. Par exemple, disons... Oui, cette implémentation, soit on la fait à la va-vite et voici le risque. Ou alors, on peut la retarder. Et voici les autres risques. Et donc, du coup, il faut qu'il arrive à accepter ce jeu-là. C'est-à-dire, des fois, on va dire non. En fait, c'est vrai que si on retarde cette fonctionnalité encore plus, on a des pertes liées au business, etc. Et il va falloir qu'on fasse des choix. Alors, il va falloir effectivement... regarder comment je fais, par exemple, pour avoir un design qui peut être évolutif et sur lequel on peut revenir sur une situation qui est beaucoup plus maintenable, beaucoup plus facile à implémenter, beaucoup plus correcte, dans un deuxième temps. Mais du coup, oui, on évalue un risque. On dit, voilà, là, j'accepte ce risque et voici mon plan pour aller plus loin. Effectivement, c'est une négociation un petit peu avec les autres stakeholders. Ok, je suis d'accord pour respecter ta date, mais est-ce que tu es d'accord pour que par la suite, on fasse ça et qu'on ralentisse sur un autre truc pour pouvoir se remettre en forme, par exemple, par la suite ?

• Speaker #0

  D'accord. Et toutes ces décisions, idéalement, on essaie d'étracer ?

• Speaker #1

  Oui. Oui, c'est important, oui.

• Speaker #0

  Et tu as des conseils pour ça ?

• Speaker #1

  Alors, il y a pas mal de documents qu'on peut mettre en place. Le mieux, c'est de les mettre le plus proche possible du code. Les petits fichiers MDL dans le code base. Exactement, exactement. Tous ces fichiers-là.

• Speaker #0

  Que les agents pourront se nourrir par la suite, peut-être, peut-être.

• Speaker #1

  Oui, donc après l'offshore, les agents. qui vont venir, effectivement. Parce qu'en fait, c'est vrai que dans les pratiques, c'est des bonnes pratiques qu'on fait depuis très très longtemps. En fait, ces choses-là...

• Speaker #0

  Ça révèle que les bonnes pratiques, on les utilise depuis longtemps. Exactement. Notamment les ADR.

• Speaker #1

  Les ADR, exactement. En fait, on les mettait en place pour que d'autres personnes qui ne sont pas directement sur place avec nous, lors de la réunion, puissent suivre ce qui... un peu ce qui s'est passé et comment on en est arrivé à cette décision-là. Mais comme tu le dis, peut-être que demain, ce seront les agents qui vont les lire.

• Speaker #0

  Voilà. OK. Et tu as... Donc toi, tu documentes beaucoup ça avec des architectures d'Exercise Young Record ? OK. Et tu as un format préféré ? C'est quoi les conseils ? Pour en faire beaucoup, quels sont les pièges ? Est-ce que ce qui peut arriver, c'est que de temps en temps, tu essaies de faire les choses trop bien ? Enfin, je vais essayer de dire ça comme ça. Est-ce que tu as des points ?

• Speaker #1

  Alors, c'est vrai. Un des trucs que je pense, c'est qu'il faut que le principal y soit. Des fois, on passe énormément de temps à mettre... Plein de détails, on perd beaucoup de temps. Et finalement, ce n'est pas quelque chose qui est lu ou qui est important à voir par la suite. Ce qui est important, c'est d'avoir les points clés qui ont amené une décision bien déterminée.

• Speaker #0

  C'est d'avoir cours et concis et droit au but.

• Speaker #1

  Exactement. Je reste sur quelque chose de très concis. Typiquement, j'essaie de... pas dépasser, par exemple, trois pages de contenu de manière à ce que ce soit vite, quelqu'un peut vite le parcourir, comprendre les principaux enjeux et ce qui s'est passé, en fait.

• Speaker #0

  Et pareil, en termes de contexte engineering, demain, de ne pas avoir des documents trop longs, éviteront d'amener trop de contexte aux agents. On a un effet qui se coule. Puis plus on a un document court, plus on a la certitude qu'il sera lu. Enfin, plus de chance qu'il sera lu.

• Speaker #1

  Oui, ce qui est d'ailleurs le contraire de ce que les agents nous font aujourd'hui. Parce que les agents, ils nous écrivent des tartines à chaque fois.

• Speaker #0

  Les meilleurs agents, ils progressent là-dessus.

• Speaker #1

  Oui.

• Speaker #0

  Clairement. Ok, super. J'aimerais bien qu'on parle un petit peu de pourquoi on fait les produits. pour des clients, pour le business d'entreprise, pour avoir d'impact sur les utilisateurs et l'entreprise. Donc, souvent un tech lead parle beaucoup de craft, d'architecture, de bonne pratique, de problématiques techniques. Est-ce qu'un tech lead qui optimise son code sans réfléchir à l'impact client, Est-ce qu'il y a quelque chose, enfin la question est un peu orientée, mais t'en penses quoi de ça ? Est-ce que TechLead doit être focus sur le code ou commencer à se projeter sur l'impact de ce qu'il est en train de faire ?

• Speaker #1

  Oui, je pense que je suis assez d'accord avec toi. Effectivement, on peut dans la technique, dans l'amélioration des performances, l'amélioration de comment mon code est fait, est-ce que mon architecture est libre. Il y a beaucoup de choses qui sont effectivement des points sur lesquels le technique... peut se pencher et y passer énormément de temps. Mais au final, comme tu l'as souligné, si finalement le produit n'est pas utilisable... Je vais te donner un exemple. Récemment, j'ai vu un produit qui... effectivement il avait été abandonné pendant un certain temps en tant qu'open source et en fait il a été repris par une équipe. L'équipe a décidé effectivement que c'était important de faire une réécriture et en fait une des choses que le TechLead a négligé, c'est comment un utilisateur qui utilise le truc depuis déjà presque une dizaine d'années, il utilise des Et il a donc ses habitudes, les arguments qui vont avec, les fichiers de configuration qui vont avec, etc. En fait, ce qui a été négligé, tout simplement, malgré tout le bon design du truc, c'est qu'au final, comment un utilisateur va passer d'une version à la prochaine version ? Si ce n'est pas fluide, si cette migration n'a pas été pensée, en fait, ça a été un échec. C'est-à-dire que l'équipe a passé effectivement près d'un an à réécrire ce petit outil. Elle l'a rendu effectivement beaucoup plus efficace, beaucoup plus rapide. Il y avait énormément d'améliorations qui ont été faites. Mais en fait, les clients ne sont passés sur cette nouvelle version-là que près d'un an plus tard. C'est-à-dire qu'on a mis deux ans finalement à prendre en compte des nouvelles fonctionnalités, des bugs fixes, des choses comme ça. Simplement parce qu'on avait décidé que les nouvelles fonctionnalités iraient sur la nouvelle version. Et en fait, les clients disaient « moi je l'utilise de cette manière-là, donc cette fonctionnalité, si elle n'est pas primordiale pour moi » . En fait, je ne vais pas passer du temps à faire la migration pour l'utiliser. Je vais rester sur la précédente. Et donc, pour l'équipe, c'était un calvaire. Parce que du coup, ils se sont retrouvés à devoir maintenir la précédente version tout en écrivant la nouvelle version.

• Speaker #0

  Et du coup, ce qui n'est pas évident, c'est comment tu exprimes ce que tu es en train de faire par rapport à l'impact que ça a. De temps en temps, traduire des changements techniques pour qu'ils montrent cet impact, ou qu'ils prennent en compte l'impact sur les utilisateurs ou l'entreprise, c'est quelque chose qui n'est pas facile à exprimer. Et ça fait qu'on peut avoir aussi, on en revient sur le point tout à l'heure de communication, où l'EPM ne comprend pas ce que le technique est en train d'exprimer et personne ne valorise quelque chose d'important.

• Speaker #1

  Oui, je pense que c'est effectivement un peu le problème du langage où tout simplement, c'est comme si en fait un technique devait parler plusieurs langues. Ils doivent parler la langue de ses développeurs, il doit pouvoir leur expliquer ce qu'on attend du produit ou des choses comme ça. Il doit aussi parler la langue de ses autres stakeholders, que ce soit des architectes, des product owners, etc. Et donc en fonction à qui il parle, il va potentiellement parler d'une façon différente. ou apporter ses arguments d'une manière différente. Et c'est important de savoir parler ces langues-là pour pouvoir se faire entendre. Récemment, j'ai eu un peu ce cas où je me suis rendu compte que je m'efforçais en fait à mettre du détail technique pour expliquer un certain point. Et en fait... Au final, je me suis dit que mon interlocuteur, c'est un manager de haut niveau. Il ne va jamais s'intéresser à ces détails techniques-là. Du coup, j'ai complètement laissé tomber mon document. Je me suis dit que j'allais lui faire trois slides. Je vais écrire juste une phrase limite par slide. On parlera ensuite. Effectivement, ça a été la bonne façon d'agir. parce que En fait, pour moi, c'était limite comme si je faisais de la provoque, mais c'était nécessaire de passer par ce point-là où c'est une phrase très synthétique et qui potentiellement l'interpelle pour qu'on puisse passer sur la discussion ensuite.

• Speaker #0

  Et le fait de ne pas avoir pris cet angle technique au début, Tchuuuuuuuut ! Tu as créé ce dialogue très tôt.

• Speaker #1

  Exactement.

• Speaker #0

  Parce que sinon, après, on ne t'écoute plus en fait. Exactement.

• Speaker #1

  Alors, il faut dire quand même que faire cette partie technique profonde et détaillée était quand même nécessaire pour en fait avoir les arguments et savoir se projeter sur quels sont les risques qu'on est en train d'encourir en continuant comme ça.

• Speaker #0

  Parce qu'il faut que ça s'appuie sur quelque chose de solide.

• Speaker #1

  Exactement. Il faut que ça reste quand même basé sur quelque chose d'objectif et de vrai. Mais une fois qu'on a cette base-là, il faut savoir s'en affranchir et dire voilà mon message pour cet interlocuteur-là. Alors que pour un autre interlocuteur, je vais avoir un autre message, peut-être plus détaillé ou moins détaillé, avec un angle différent aussi. Il faut prendre tout ça en compte, en fait.

• Speaker #0

  Alors, la question qui me vient, c'est du coup, est-ce que cette compréhension business, un peu, elle est importante ? Est-ce que, si je vais dans le provoque aussi, est-ce qu'un tech lead doit comprendre aussi bien le business que la technique ?

• Speaker #1

  Oui, absolument. Moi, je suis pour qu'un tech lead, par exemple, puisse participer. à des labs ou à des activités où il peut avoir accès aux vrais clients derrière. Parce que souvent, en fait, le tech lead, il ne voit que la partie product owner et il ne voit pas plus tard le client. Donc, que ce soit au travers de, j'ai un incident du support, je vais y participer. voir vraiment où c'est que ça coince pour un client donné. Ça peut être aussi au travers de tout ce qui est je présente mon produit chez un client, voir aussi quelles sont les interrogations qu'un client peut avoir, qu'est-ce qui bloque pour l'adoption du produit, etc.

• Speaker #0

  Tout est surprise qu'on peut avoir au passage.

• Speaker #1

  Oui, parce qu'en fait souvent ces informations-là sont un peu agrégées et on a d'un point de vue technique que par exemple le... les pics ou la story qui arrive du product owner et qui dit, en tant que client, j'aimerais faire ça. Mais en fait, ça ne dit pas forcément qu'est-ce qui a généré ce besoin au départ. Et moi, j'aime bien aller, en tant que tech lead, moi, j'aime bien aller dans ces situations-là où c'est peut-être un peu plus difficile parce qu'en fait, confronter directement un client, c'est... il faut aussi savoir absorber la frustration d'un client ou sa colère c'est des choses qui sont pas évidentes pas tout le monde a cette capacité là de recevoir ces retours là qui peuvent être un petit peu échaudés par moment mais je pense que c'est vachement formateur et ça aide vachement à dire euh Quand on prend des décisions techniques par la suite, ben non, en fait, il faut que je pense à telle personne parce qu'à ce moment-là, ce choix-là va faire une différence par rapport à tel autre choix.

• Speaker #0

  On comprend l'impact de ce qu'on fait. Oui,

• Speaker #1

  on comprend l'impact, exactement.

• Speaker #0

  Même si ce n'est pas forcément facile, parce qu'il peut y avoir des éléments négatifs qu'on n'attendait pas, mais il peut y avoir aussi des éléments positifs qu'on n'attendait pas, et on fait un peu ce métier pour ça.

• Speaker #1

  Oui, tout à fait.

• Speaker #0

  Et nous, on a un mantra chez nous qui est il faut emmener l'équipe tech sur le terrain.

• Speaker #1

  Oui.

• Speaker #0

  Et régulièrement, dans les épisodes d'En part en prod, quand on essaie de faire ressortir c'est quoi les bonnes pratiques pour essayer de construire du bon logiciel, du patrimoine technologique pour l'entreprise, revient tout le temps ce sujet de, il faut que les développeurs se rendent compte des utilisateurs, ce qu'ils vivent, et d'aller faire en sorte que les développeurs parlent aux utilisateurs. Et souvent c'est difficile. C'est intéressant ce que tu disais. On n'est pas obligé d'avoir des choses... De temps en temps, les utilisateurs peuvent être loin, mais on peut avoir des salons au milieu, ou des organisations, des événements au milieu, qui créent un peu ça, sans avoir à formaliser des choses très compliquées. Mais je suis très aligné à ce que tu dis. Et ça, c'est pour le point de vue de l'utilisateur. Mais dans le business de l'entreprise, qu'est-ce que... Est-ce que tu as un avis similaire, différent ? Oui,

• Speaker #1

  je vois, tu vas en venir. En fait, je pense que, par exemple, les développeurs sont souvent un peu dans leur bulle. Et on comprend tout à fait ça. Ils ont un certain nombre de choses à appréhender, etc. Mais, par exemple, si on ne va pas travailler avec quelqu'un qui fait de l'ops, de l'opérationnel, Si on ne voit pas la vie de quelqu'un qui fait du support, si on ne voit pas comment un quality engineer va travailler, si on ne voit pas ce qu'un security engineer va réfléchir, en fait, on a une vision très, très restreinte finalement de ce que c'est que le métier de développeur. et je pense que le tech lead c'est ça son rôle aussi dans l'équipe c'est d'être C'est de connaître ces enjeux-là. Et moi, j'aime vraiment aller... Tout comme on fait du pair programming entre nous, j'aime bien dire qu'il y a un incident avec le support. En fait, je vais me connecter et je vais travailler avec eux pour savoir... Quels sont les outils qu'ils sont en train d'utiliser ? Est-ce qu'ils y vont par la bonne approche ou pas ? Est-ce que c'est important peut-être que je documente une certaine partie différemment ou que je fasse des formations en interne ? Pareil pour les opérations. Est-ce que vraiment l'environnement, l'infrastructure sur laquelle on est en train de déployer fait qu'il y a des choses que je dois appréhender différemment dans mon produit ? ou dans la façon dont je propose sa livraison. Il y a beaucoup de choses qu'on peut vraiment prendre par ces échanges avec des personnes qui sont extérieures à l'équipe de dev en soi et qui peuvent en fait enrichir le point de vue du tech lead pour son produit et pour son équipe.

• Speaker #0

  Génial. Est-ce que ça t'est déjà arrivé de ne pas être au rendez-vous, d'être un mauvais t'équilibrer ?

• Speaker #1

  Oui.

• Speaker #0

  Tu as un exemple ou quelque chose que tu as appris par...

• Speaker #1

  Par la force des choses. Oui, en fait, il y a quelques années, quand l'offshore était vraiment quelque chose... À la mode. À la mode, exactement. Eh bien, en fait, c'était effectivement difficile pour moi de voir comment on va... qu'on va organiser l'équipe. Et dans un premier temps, mon idée, c'était de dire, il faut que tout soit écrit. Tout le design soit écrit, toute la façon de travailler soit rédigée pour que ce soit un point de repère pour les gens. Et finalement, je me suis rendu compte que ça ne fonctionnait pas. Ça ne fonctionnait pas pour plusieurs raisons. D'une part, parce que même si on parlait la même langue, des fois, ce n'est pas forcément compris. Et d'autre part... parce que connaître les gens, c'est quand même important pour comprendre leur réaction par rapport à nous. Et donc du coup, je me souviens que ça n'a pas fonctionné pendant très longtemps. J'avais beaucoup de problèmes à respecter mes délais et à livrer quelque chose de qualité. Et finalement, je me suis rendue compte que... Avoir des discussions avec eux, même si à l'époque, c'était quand même beaucoup la voix plus que la vidéo. Aujourd'hui, la vidéo, elle aide beaucoup. Même quand on est à distance, on peut quand même faire des choses.

• Speaker #0

  Mais gérer ça par téléphone, c'était dur. Oui, gérer ça par téléphone, c'était dur.

• Speaker #1

  Et surtout, arriver dans un mode, voici le design fait, ça ne fonctionne pas. Pour moi, je... pense que la meilleure approche, c'est d'arriver avec la problématique, l'expliquer, même si on a une idée très claire de ce que doit être la réponse, mais en fait, arriver ensemble à la formuler, cette réponse, en fait. Et ça, ça permet aux personnes d'être beaucoup plus engagées. Donc, notamment dans le contexte de l'offshore, où des fois, il y a des égos qui sont un peu difficiles à gérer, surtout lorsque le tech lead est une fille.

• Speaker #0

  Oui, je peux comprendre.

• Speaker #1

  Il vaut mieux, en fait, avoir cette Ausha d'en fait faire participer tout le monde pour aboutir, en fait, à la solution qu'on veut mettre en place.

• Speaker #0

  Si je fais un pont, Maintenant qu'on a des agents IA pour nous aider, est-ce que d'arriver avec une solution d'entrée avec l'agent est une bonne approche ? Est-ce que dans ce contexte d'engineering, est-ce que d'amener du contexte sur le pourquoi, sur l'objectif, sur les choses qu'on imagine et les choses qui... qui peuvent poser problème et d'avoir ce temps de discussion, je ne sais pas si c'est une discussion, mais ce temps d'échange avec l'agent pour pouvoir construire la bonne solution. Est-ce qu'on n'est pas en train de faire un petit parallèle aussi ?

• Speaker #1

  Complètement. Complètement. C'est un peu le... En fait, c'est d'ailleurs... J'ai repensé à l'offshore il y a assez récemment de... cette nouvelle tendance un petit peu à travailler avec les agents. Et je trouve qu'on est dans le même move, en fait. Tout comme avant, on se disait, si je fais avec de l'offshore, j'irai plus vite, je ferai plus de choses. Aujourd'hui, avec les agents, on fait un petit peu la même chose.

• Speaker #0

  Donc peut-être que ceux qui ont l'expérience, des expériences réussies, parce qu'ils ont eu des échecs, Avec l'offshore, peut-être se retrouvent dans une position un peu plus favorable, on va dire.

• Speaker #1

  C'est vrai.

• Speaker #0

  En plus du fait qu'ils ont l'expérience pour pouvoir comprendre à multiniveau ce qu'ils sont en train de faire. Ok, super intéressant. Et donc du coup... Tu as parlé beaucoup de communication, etc. Si on parle du T-shape, du TechLead, est-ce que délargir son T-shape avec des compétences Ops pour la prod ou des compétences produits pour comprendre le pourquoi et pourquoi les users stories sont exprimés de cette façon-là ou les retours utilisateurs qui peuvent être un peu déstabilisants, Est-ce qu'élargir son t-shirt est quelque chose qui... qui apporte, comment on peut faire ?

• Speaker #1

  Alors, en fait, effectivement, c'est très important d'avoir un petit peu une vue d'ensemble et avoir une expérience un peu anti-shape, donc plus en latéral que plutôt en profondeur sur un sujet bien déterminé. C'est important. C'est important aussi de pouvoir s'appuyer ou d'avoir confiance et d'avoir dans son équipe ou avec les collaborateurs, d'avoir cette confiance-là et de dire, voilà, moi, je suis OK pour dire je ne connais pas tout sur tout sur telle technologie, mais je sais que lorsque je vais discuter avec telle personne, son avis est quelque chose en lequel je peux avoir confiance. Donc, un peu plus effectivement, on peut avoir une formation un peu plus transversale et peut-être pas forcément très profonde sur tous les sujets, mais on peut compenser ça différemment. On peut compter les uns sur les autres et c'est ça, en fait, le rôle aussi du TechLit, c'est de faire monter des personnes dans son équipe en compétence sur certains sujets pour qu'ils puissent aussi s'appuyer sur eux.

• Speaker #0

  Si un TechLit qui est en train de nous écouter, il aimerait bien changer quelque chose demain matin, lundi matin, parce qu'on sort les épisodes dont on part en proie de vendredi. Parce que c'est bien que ça parte en proie de vendredi. Ça part en proie de vendredi, c'est bien. Et donc du coup, lundi matin, il veut changer quelque chose parce qu'il a écouté notre échange pendant le week-end. Il commence par quoi ? Tu lui donnerais quel conseil, toi ?

• Speaker #1

  Bonne question. Je dirais que la première chose à faire, c'est de se dire que son rôle, c'est de faire grandir les autres qui sont dans son équipe et de voir un petit peu comment il peut les faire évoluer, leur apprendre des nouvelles choses. C'est effectivement un des trucs importants, un atout important du TechLead, c'est de transmettre en fait. de transmettre une certaine passion pour faire les choses d'une certaine façon, ne pas se transmettre du stress. Par exemple, un tech lead qui va répondre à des messages à 19h, 20h, etc., il va transmettre aussi à son équipe cette... pensée qu'on attend de moi en tant que développeur aussi que je ne lâche jamais. Et donc du coup, c'est important aussi pour le tech lead d'être un peu garant et de faire par l'exemple de garantir que son équipe est dans un environnement serein.

• Speaker #0

  Alors, j'ai une question, une dernière question sur l'IA, parce qu'on ne peut pas s'empêcher de poser des questions sur l'IA. avec l'IA qui code de mieux en mieux, qui devient assez essentielle dans notre workflow, dans notre software delivery lifecycle. Comment va évoluer le rôle de Tech Lead ? J'ai un avis sur la question, mais j'aimerais bien entendre ton avis. Est-ce que ça va être un rôle de plus en plus important, de moins en moins important, qui va disparaître ? Quel est ton avis ?

• Speaker #1

  Alors, on va voir. Moi, je suis plutôt... En fait, j'ai envie d'être optimiste et de dire que tout comme tout plein d'autres évolutions par ailleurs, notamment le cloud, etc., qui nous a fait un petit peu peur aussi au début, mais qui nous a, par exemple, permis de pouvoir... tester dans des situations beaucoup plus réelles, dans nos CICD par exemple, parce qu'on pouvait faire des choses plus rapidement. Moi, je pense que les agents aussi peuvent nous aider, c'est-à-dire que si on s'appuie correctement sur eux pour dire ben oui, voilà, moi en tant que tech lead, peut-être, je ne sais pas, moi... Un sujet bien déterminé, je ne le connais pas forcément beaucoup, mais je peux m'appuyer sur les connaissances d'un agent pour m'aider aussi à apprendre et à appréhender certaines problématiques. Je le vois du coup un petit peu comme un exosquelette, un peu comme avoir un petit peu des super pouvoirs aussi. Et donc du coup, j'espère que ça va permettre à l'ensemble de la communauté d'un petit peu évoluer dans le sens, s'appuyer un petit peu sur ses connaissances pour élargir son domaine de compétences d'une manière un peu artificielle, mais pourquoi pas.

• Speaker #0

  Qu'est-ce qui manque le plus souvent aux équipes pour passer de simplement faire du développement à... Produire d'impact.

• Speaker #1

  Pour moi, c'est cette sensibilité. Cette sensibilité aux autres qui sont autour. Que ce soit les clients, dans un premier temps, puisque c'est pour eux qu'on travaille, mais aussi pour toutes les parties prenantes autour de l'équipe. Je pense notamment aux opérations. à ceux qui vont faire passer des certifications sur le produit, à toutes ces autres unités qui sont autour et qui vont permettre à ce produit de se démarquer par rapport à quelque chose d'autre.

• Speaker #0

  Génial. Comment tu fais ta veille, toi, Chérine ?

• Speaker #1

  Alors, ma veille, c'est beaucoup de podcasts. Très bien. Finalement, d'horizons très différents. Ok.

• Speaker #0

  Vas-y, donne-en. Donne des noms.

• Speaker #1

  Des noms. Alors, je continue à écouter les cast-coder, même si, en fait, c'était du Java, en fait, beaucoup à l'époque. Maintenant, ça commence à évoluer. J'écoute aussi le DevOps Paradox, en anglais. qui sont deux compères, pareil, qui font des discussions autour de sujets bien déterminés. Et j'aime bien la façon de penser qui est un peu ouverte.

• Speaker #0

  D'accord.

• Speaker #1

  J'écoute quelque chose qui s'appelle le Cloudcast, qui ne s'appelle plus le Cloudcast d'ailleurs, puisque avec l'avènement de l'IA, Le cloud n'est plus la dernière hype. Ils se sont renommés récemment, mais je ne me souviens plus. On retrouvera le nom,

• Speaker #0

  on mettra le lien en description.

• Speaker #1

  Oui, on mettra le lien en description. Et eux aussi, ils ont une certaine vision plus business, je dirais, que juste technique. Après, j'écoute... What's in the source ? Qui est le What's in the software open source ? Non. Comment ça s'appelle ? C'est le truc de la sécurité. Le truc autour de la sécurité du CNCF.

• Speaker #0

  Je ne connais pas celui-là.

• Speaker #1

  Et tout un tas d'autres podcasts liés à Kubernetes, des choses comme ça.

• Speaker #0

  Génial, génial. Rien à voir, c'est quoi la dernière série ou le dernier film que tu as vu ?

• Speaker #1

  La dernière série que j'ai vue ou le dernier film ? La dernière série, c'était Good Cop, Bad Cop. C'est un truc un peu rigolo sur... sur des shérifs aux Etats-Unis, un frère, une sœur. D'accord,

• Speaker #0

  c'était bien ?

• Speaker #1

  C'était sympa. Ok. C'est rigolo.

• Speaker #0

  Ok, d'accord. Intéressant. Et un film ?

• Speaker #1

  Et un film, ça fait très longtemps que je n'en ai pas regardé.

• Speaker #0

  On regarde moins de films maintenant, ça y est.

• Speaker #1

  Mais si, j'ai regardé un qui s'appelle One Battle After Another. C'est le film avec... Je crois que c'est One Battle After Another.

• Speaker #0

  Je peux regarder rapidement. Je peux te dire ça.

• Speaker #1

  C'est avec DiCaprio, normalement.

• Speaker #0

  Oui, exact.

• Speaker #1

  C'est un très très long film. Il paraît qu'il est très bien. Oui, vraiment très très bien sur... sur un petit peu... Comment garder sa liberté de penser dans une Amérique qui cherche à faire rentrer tout le monde dans ses rangs ? Je ne me souviens plus de quoi le nom exact. Et peut-être que le nom en français n'est pas la même chose. Une bataille après l'autre.

• Speaker #0

  Une bataille après l'autre en français. Et en anglais, c'est One battle after another.

• Speaker #1

  After another. Donc je la vis bien. Tu la vis bien. C'était dans l'avion.

• Speaker #0

  et je l'ai mis dans ma liste à voir celui-là je regarderai ma mère l'a vu, elle m'a dit qu'il était super il est super il a très bon feedback et bon film ça court pas les roues non plus alors ça sera bien super recos est-ce que tu as des recos du coup ? en plus des podcasts que tu as cités mais est-ce que tu as des recommandations de livres ou une série qui déchire qu'il faut que tout le monde connaisse ou rien à voir, des recommandations des choses à partager,

• Speaker #1

  des choses qu'il faut que je connaisse des choses à partager dans la tech moi j'aime bien tout ce que fait Aurélie Vache qui est beaucoup en dessin Merci. sur comment expliquer ce que c'est qu'un pod par exemple ou comment fonctionne le réseau dans Kubernetes. Des concepts des fois assez complexes qui peuvent être vraiment rendus simples avec quelques dessins. Elle fait ça vraiment à la main. Elle prend le temps d'imaginer comment je peux expliquer ça.

• Speaker #0

  Je ne dis rien, mais je suis sûr qu'en voyant un dessin, ça va me faire...

• Speaker #1

  Je suis sûre.

• Speaker #0

  Ok, cool.

• Speaker #1

  Et puis en dehors de ça, en dehors de la tech ? Moi, j'aime beaucoup lire en anglais, mais...

• Speaker #0

  D'accord. Et tu as un livre que tout le monde devrait lire ?

• Speaker #1

  Que tout le monde devrait lire.

• Speaker #0

  Si tu ne dois en retenir qu'un seul. C'est dur, ça.

• Speaker #1

  Non, c'est dur, ça. Mais récemment, j'ai lu The Wife of the Serial Killer, qui était vraiment bien. OK. Moi, j'aime bien lire les livres de... un petit peu de... les thrillers, quoi.

• Speaker #0

  Voilà, les thrillers, policiers, voilà. Ok, d'accord. Génial. Bon, si on veut te contacter, ou te suivre ?

• Speaker #1

  Je peux te contacter. En fait, je suis un peu moins sur Twitter ces temps-ci. Je suis sur LinkedIn. Donc, pareil, Chahine Kouri sur LinkedIn. Oui, essentiellement là.

• Speaker #0

  Ok, d'accord. Génial. De toute façon, on mettra tout ce qu'on a dit, on mettra les liens. On s'embête pour mettre tous les liens de questions. Il y aura tout. Il n'y a pas de souci. Merci d'avoir passé un peu de temps avec moi. Et avec tous ceux qui... qui sont encore là. Si vous êtes encore là, c'est que vous avez kiffé quand même, normalement. Si vous êtes tech lead, il faut vous envoyer ça à vos potes. Il faut partager l'épisode, il faut mettre un like, il faut mettre 5 étoiles sur les plateformes de podcast. Il faut faire un feedback à Chérine. Ça peut être intéressant.

• Speaker #1

  Ça m'intéresserait.

• Speaker #0

  Voilà. En plus, elle est adorable. Franchement, il n'y aura zéro problème. Faites-lui un feedback. Faites-nous un feedback. Inscrivez-vous à Newsletter avec Sarbrica, comme ça vous êtes au courant des prochains épisodes, un peu comme ce qu'on fait aujourd'hui, et d'autres sur plein d'autres thèmes. Moi je partage beaucoup le côté éclectique que tu partages, j'aime beaucoup faire plein de choses différentes. Donc si vous êtes un petit peu curieux, abonnez-vous à Newsletter. Une fois par mois j'envoie un petit mail avec un peu les petites nouveautés des contenus qu'on produit chez Sarbrica. Voilà, n'hésitez pas et puis à très vite pour un prochain épisode, merci !

• Speaker #1

  Merci beaucoup Julien !

• Speaker #0

  Ce que retient Chérine, c'est ce qui manque le plus souvent aux équipes pour avoir de l'impact, la sensibilité aux autres. Aux clients d'abord, puisque c'est pour lui qu'on travaille, mais aussi à tous ceux qui font qu'un produit tient, une fois en prod. C'est cette exigence-là qu'on pousse jusqu'au bout chez Exabrica. On construit des solutions critiques et on s'engage sur le résultat. Si votre projet n'aboutit pas, on n'est pas payé. Contactez-nous en suivant le premier lien en description. Et n'oubliez pas, le monde se divise en deux catégories. Ce qui suivant par en prod