- Speaker #0
Je suis Cédric Teyton, CTO de PackMind, et dans TechLead Corner, je reçois des TechLead, Engineering Manager, CTO, bref, des passionnés de la tech, pour parler de leur parcours, et surtout de leur mission.
- Speaker #1
C'est-à-dire, après chaque entretien de performance, on fait le point tous ensemble. On a, enfin, voilà, on planifie un moment dédié. où on est tous ensemble, et on va partager les objectifs qu'on s'est donnés pour le prochain semestre. Et donc, on utilise un board chez chacun, mais un post-it avec ses objectifs, etc. Et puis, on trace des liens entre les personnes de l'équipe et les objectifs pour dire, tiens, moi, je vais pouvoir t'aider, en fait, juste pour identifier qui pourra m'aider à atteindre mon objectif en équipe. Donc, c'est comme ça, de manière globale dans l'équipe. Ce que j'ai observé, c'est que ça crée de la transparence. Ça évite des incompréhensions, par exemple si mon front-end prend un type de bac. Je n'ai pas envie que mes bacs soient complètement affolés en disant ouais ouais ouais, qu'est-ce qu'il va faire ? Ils n'ont pas confiance, etc. Non, ils vont être là vraiment en toute bienveillance. Ils vont être là pour aider ce front-end à monter en compétence. Ils sentent pour eux qu'il a cet objectif. Donc ils vont lui donner les outils pour atteindre son objectif.
- Speaker #0
Bonjour à toutes et tous, bienvenue pour ce nouvel épisode de TechLit Corner, épisode 8. Aujourd'hui j'ai le plaisir de recevoir Virginie Jujy. Salut Virginie !
- Speaker #1
Salut Cédric!
- Speaker #0
Comment tu vas aujourd'hui ?
- Speaker #1
Ça va très bien, et toi ?
- Speaker #0
Je vais très bien, je te remercie. Je suis ravi de t'avoir avec moi pour ce nouvel épisode. On va parler aujourd'hui de toi, de tes missions, notamment actuellement chez Encore Store en tant qu'Engineering Manager. Et on va notamment parler pas mal de ce sujet-là, de qu'est-ce que ça veut dire être Engineering Manager. Et je crois que tu as eu plusieurs fois, je crois que tu as eu différentes expériences par le passé sur ce poste-là. Donc ça va être intéressant de parler de ces sujets-là. Avant toute chose, petite tradition, est-ce que je peux te laisser te présenter à notre audience en deux minutes ? Oui,
- Speaker #1
bien sûr. Je m'appelle Virginie Jougy, j'ai 16 ans d'expérience dans le domaine du développement informatique. A la base, j'ai un diplôme de l'ENSEP en 2008 et je suis passée par différents rôles, développeur junior, confirmé, architecte, tech lead, scrum master, également coach agile et depuis plusieurs années, je suis engineering manager, ce qui m'amène ici.
- Speaker #0
C'est un chou. Alors justement sur ce point, j'ai envie de comprendre dans ton évolution, tu as dit que tu étais dev, Scrum Master, Engineering Manager. Ça m'intéresse de comprendre qu'est-ce qui a amené cette transition ? Est-ce que c'était toi une volonté au départ ? Est-ce qu'il y a des opportunités ? Tu peux nous en dire un peu plus ?
- Speaker #1
De manière assez classique, j'ai commencé sur le développement informatique, mais j'avais une grande affection sur le travail d'équipe. quel que soit le domaine, j'étais assez active dans le milieu associatif en étant étudiante, j'avais été présidente d'une asso, et j'aimais beaucoup toute cette dynamique d'équipe. Donc c'est vrai que dans mes recherches d'emploi, je favorisais vraiment les milieux où j'allais travailler en collaboration avec d'autres personnes. Donc il m'est arrivé d'avoir des postes où j'étais plus isolée, où je ne me suis pas vraiment épanouie dans ces postes-là. C'était plus des postes d'architecture où j'étais vraiment assez seule et écartée des équipes, ce n'était pas vraiment ce qui me plaisait le plus. Et donc au fil du temps, je préférais avoir des rôles de tech-lead, impliqués dans des équipes. En général, c'est des équipes allées de 4 à 20 personnes. Ça dépendait vraiment des contextes et des entreprises. Et au fil du temps, il y a une manager qui a vu en moi une âme de Scrum Master. Elle m'a dit, écoute, actuellement tu es technique, mais ça serait intéressant, tu t'intéresses à ce sujet autour de l'organisation de l'équipe, dans le contexte Scrum, etc. Et en fait, là, ça m'a vraiment ouvert une perspective complètement nouvelle sur le travail d'équipe, sur les dynamiques, sur la facilitation. Donc je pense que ce rôle de Scrum Master m'a finalement ouvert les yeux sur le fait que j'aimais travailler avec les personnes, j'aimais aider les personnes à évoluer dans leur contexte et finalement ça m'a assez naturellement orientée par le rôle de manager. qui, de ma perception, contrairement à TechLead, est peut-être plus orientée sur la performance individuelle et la satisfaction individuelle dans une équipe, et aussi sur les dynamiques entre personnes, autant d'une équipe que le rôle de TechLead, qui est plus orientée sur la vision tech, l'implémentation, les bonnes pratiques à mettre en place et les process pour que l'équipe développe des outils performants. Voilà un petit peu comment j'ai féminé vers ce rôle.
- Speaker #0
Ok, merci pour ces précisions-là, je vois bien la trajectoire que tu as pu avoir. Si tu devais, dans ton contexte actuel, justement définir... le rôle, les missions d'un ou d'une engineering manager, qu'est-ce que ce serait ?
- Speaker #1
Alors, au travers de mes différentes expériences, j'ai observé différents rôles de manager au sein des services tech. Donc j'ai pu avoir des managers qui géraient quatre ou cinq équipes à la fois, avec finalement on s'appuyait sur des tech leads et des scrum masters dans les équipes, donc ça pouvait aller jusqu'à 50 personnes à manager en direct, ce qui était énorme. J'ai vu des managers qui étaient plus... Voilà, sur deux, trois équipes. Donc ça, c'est un rôle que j'ai eu à tenir, où j'avais deux, trois équipes à organiser. Parmi, je m'appuyais sur des tech leads. Mais j'étais là vraiment pour encadrer les process, m'assurer que la cohésion d'équipe et l'organisation se passaient bien. Et là, aujourd'hui, chez Encore Store, je suis vraiment dédiée à une seule équipe, qu'on appelle Squad. Dans l'équipe, on est cinq développeurs. On travaille avec un product manager et un product designer, ainsi qu'un data analyst pour tous les aspects produits. Et moi, en tant qu'engineering manager, je suis plutôt là pour amener les conditions de réussite de mon équipe, créer la cohésion et la dynamique finalement, de manière à ce que la collaboration entre les équipes tech et produits aussi se passe bien. assurer le développement individuel de chacun des développeurs dans mon équipe. J'ai des profils assez différents. Alors, je n'ai pas de profil très junior, mais je m'arrive de temps en temps à travailler avec d'autres profils plus juniors. Là, j'ai plutôt des profils confirmés, voire très expérimentés, notamment des tech leads. J'ai un staff engineer dans mon équipe. Donc, c'est intéressant parce que je n'ai pas les mêmes, on va dire, je n'ai pas la même approche sur les personnes, des personnes qui sont plus junior. On va dire, je vais axer des aspects développement personnel sur des points différents. Mon tech lead va plutôt être là pour justement lui donner peut-être des aspects collaboration, partage de savoir, qu'est-ce qu'on peut organiser avec l'équipe pour qu'il monte en compétence sur tel sujet, qu'il s'approprie plus ou moins telle ou telle nouvelle compétence. Donc ça c'est des points sur lesquels on va être vraiment complémentaires avec Monteclid. Et au niveau d'équipe, je veux vraiment avoir ce rôle de facilitation. et assurer que je prépare bien les conditions adéquates qui puissent donner le meilleur d'eux-mêmes au final quotidiennement et collaborer correctement.
- Speaker #0
Est-ce que ça veut dire que chez Encore Store, il y a eu un choix organisationnel qui a été fait sur le fait que chaque squad avait un ou une engineering manager ? Parce que tu présentais des cas avant où il y avait une personne pour gérer 40-50 personnes, ça peut paraître beaucoup. C'est une volonté forte du management, ça ?
- Speaker #1
Oui, effectivement, chez Encore Store, le choix a été fait d'avoir un engineering manager par équipe. On a une organisation de squads, des squads c'est en général 5 à 6 ingénieurs globalement qui travaillent pareil avec un product manager, un ou plusieurs data analyst selon les sujets et un product designer. Et oui l'organisation a été mise en place de manière à ce qu'il y ait un manager par équipe. je pense que c'est un choix il y a des entreprises alors la différence que je vois là personnellement avec le recul c'est que je vois les entreprises qui ont mis un manager plus global avec plusieurs équipes souvent le rôle de manager on est plus axé sur le suivi de projets, d'avancement réorganisation des équipes et des scopes finalement de chaque équipe là en étant manager dans une équipe c'est trop anguilleux plus orienté personne, plus orienté people comme certains peuvent dire, où là je vais avoir un suivi un peu plus fin, j'ai des one on one toutes les semaines avec mes équipiers, chose qui peut être hyper difficile quand on doit manager plusieurs dizaines de personnes. Je pense que ça me fermerait toute la semaine d'avoir un one on one toutes les semaines avec chaque personne. Là on a un suivi un peu plus près ce qui fait qu'on est plus attentif finalement. Merci beaucoup. aux petits problèmes du quotidien qui, des fois, peuvent vraiment être bloquants dans la collaboration d'une équipe ou du management. Par exemple, il y a une PR qui traîne, ça fait plusieurs jours, que font les autres ? Des fois, il y a des petites frustrations. Et puis, quand on est au courant, tant que manager, on se dit, tiens, je vais rendre ça à l'équipe, essayer de comprendre ce qui ne va pas, etc.
- Speaker #0
D'accord. Vous parlez vraiment dans ces one-to-one, c'est vraiment... tous les sujets du quotidien, c'est une discussion libre, partage-moi ce que tu veux.
- Speaker #1
Oui, exactement. Moi, je partage une trame pour rendez-vous qu'on peut collaborativement remplir, où je demande ce qui s'est bien passé, qu'est-ce qui s'est mal passé, comment est-ce que je peux t'aider. Et puis, régulièrement, assez régulièrement, on se donne des objectifs tous les six mois, des objectifs individuels. C'est aussi l'occasion de faire le point régulièrement. Et puis de rectifier parfois les trajectoires quand on voit qu'il y a des objectifs qui ne vont pas être atteints, se poser la question ouvertement avec les personnes qui sont nos contributeurs et contributeuses. Est-ce que tu penses que cet objectif fait toujours sens dans notre contexte aujourd'hui ? On l'a mis en place il y a deux mois, peut-être qu'aujourd'hui il fait plus sens. Ou alors, qu'est-ce qu'il faut qu'on mette en place pour que tu puisses atteindre cet objectif ? Souvent c'est des objectifs individuels. qui permettent aux développeurs d'améliorer leurs performances. passer par exemple à un niveau supérieur c'est de confirmer à senior ou de senior à staff donc c'est important de s'assurer que régulièrement en fait que les choses se passent bien plutôt que d'attendre un entretien de performance ça serait frustrant d'avoir un feedback de son manager une seule fois dans l'année ou deux fois dans l'année donc voilà mon objectif c'est d'assurer que le feedback ils vont l'avoir il n'y aura pas de surprise quand on va faire ce point de performance qui est un peu plus administratif on va dire on va un peu plus tracer les flammes. Là, il se permet de créer une relation qui demande de confiance, de bonne communication, et puis assurer que tout le monde est orienté dans la même direction. Si on ne va pas, on est personne qui est à droite, on n'est pas à gauche, on essaie d'être tous orientés dans le même sens. Et ce one-on-one permet de s'assurer également que... que l'équipe, on va dire, les individus qui composent l'équipe, ont cet alignement déjà et qu'ils savent aussi se soutenir entre eux. Ça c'est aussi des points importants que j'essaie de mettre en place en tant que manager.
- Speaker #0
C'est plus intéressant de faire comme ça que d'avoir des objectifs à l'année où c'est un peu un cycle en V où on n'en parle pas pendant un an, c'est un peu le tabou, et puis pendant un mois à la fin tu stresses, tu ne sais pas trop, là au moins tu as un suivi sur l'année, donc l'objectif on en parle et tu aides les gens à l'atteindre. Et ça m'amène plus loin.
- Speaker #1
On en parle et puis on peut le changer aussi.
- Speaker #0
C'est une question un peu ouverte sur ça. Je trouve que ce n'est pas toujours évident. Je peux parler aussi moi en tant que CTO. En termes d'objectifs que tu fixes avec Dev, est-ce que tu peux donner un ou deux exemples ? Parce qu'on imagine souvent, il y a toujours un peu ce cliché de la productivité du long de ligne de code qui ne sont pas forcément très pertinents. Mais sur quoi tu... Est-ce que tu as des exemples tout simplement ?
- Speaker #1
Oui, tout à fait. Alors nous dans notre contexte, actuellement chez Uncore Store, on a ce qu'on appelle un objectif d'équipe. qui va être également important pour les personnes produits et qu'on va partager. Donc là, c'est vraiment un objectif qui peut être business. Par exemple, avoir tant d'utilisateurs qui utilisent cette fonctionnalité ou avoir un tel résultat business suite à l'utilisation de la fonctionnalité. Donc ça, ça va être un objectif plutôt collectif autour duquel finalement on va mettre en place les initiatives pour atteindre nos résultats. Et d'un point de vue individuel, j'aime bien quand des personnes elles-mêmes me disent moi j'ai envie d'atteindre tel objectif parce que je pense que ça sera bien pour moi Là, si je prends un exemple que j'ai actuellement dans mon équipe, j'ai des collaborateurs qui, en tant que développeur, dépeintent plus front-end ou back-end. Et là, actuellement, j'ai un développeur front-end qui est passé senior récemment. et qui, j'ai l'impression que ça lui a mis plein d'énergie et il m'a dit là sur ce semestre j'aimerais faire au moins 5 tickets back-end parce que j'aimerais vraiment élargir mes connaissances en développement, j'ai pas envie de rester poisonnée au développement front j'ai envie d'avoir un peu ce qu'on appelle là l'ingénieur entier, le T-shaped ingénieur, j'ai envie d'aller vers ce profil là Donc voilà, la mesure est assez simple. Lui il a envie d'explorer différents domaines en tant qu'ingénieur. Il fait du VVS actuellement, là il a envie d'aller sur du backend, on est sur du PHP, je suis encore store. Du coup, moi ça m'aide à identifier dans le backlog des tickets où je me dis hé tiens, là je pense que c'est bien pour débuter, tu peux regarder, ça te donnera un bon aperçu, tu pourras déjà commencer à comprendre la structure du code avec une ticket.
- Speaker #0
donc voilà et voilà c'est un exemple ça après ça veut dire que le cheminement toi après tu vas échanger avec ton tech lead pour partager les objectifs de chacun pour que cette personne ait en tête ça dans l'organisation du quotidien alors exactement,
- Speaker #1
ça c'est ce que j'avais l'habitude de faire dans mon poste précédent, j'allais voir mon tech lead et je lui dis tiens voilà on a fait des entretiens de performance un tel objectif, un tel celui-ci etc ça c'est ce que je faisais dans ma présente entreprise et en fait je me suis rendu compte que ce n'était pas évident de créer de la cohésion et de l'entraide de cette manière-là. Là, maintenant, ce que j'ai mis en place dans mon équipe, ça fait deux ans maintenant qu'on fait ça, c'est-à-dire après chaque entretien de performance, on fait le point tous ensemble. On a planifié un moment dédié. où on est tous ensemble et on va partager les objectifs qu'on s'est donnés pour le prochain semestre et donc on utilise un board alors nous on travaille sur Miro parce qu'on est en remote mais bon on peut faire ça sur un tableau on met chacun un post-it avec ses objectifs etc et puis on trace des liens entre des personnes de l'équipe et les objectifs pour dire moi je vais pouvoir t'aider en fait juste pour identifier qui pourra m'aider à atteindre mon objectif en équipe donc fait comme ça de manière globale dans l'équipe Ce que j'ai observé, c'est que ça crée de la transparence. Ça évite des incompréhensions. Par exemple, si mon front-end prend un type qui est back-end, j'ai envie que mes back-ends soient complètement affolés en disant Qu'est-ce qu'il va faire ? Est-ce qu'on peut avoir confiance ? etc. Non, ils vont être là vraiment en toute bienveillance. Ils vont être là pour aider ce front-end à monter en compétence. Ils sont pourront qu'il a cet objectif. donc ils vont lui donner les outils pour atteindre son objectif ce qui fait que d'autres ingénieurs ça va les aider à monter en compétence dans le partage de connaissances, dans le mentoring et mon devoteur fondant ça va l'aider à monter en compétence techniquement du coup c'est super complémentaire, ça ouvre des opportunités et j'ai trouvé que en partageant comme ça les choses ça a plusieurs effets ça crée un environnement sécure, enfin voilà, on est à l'aise avec ses collègues on n'a pas peur de prendre une tâche en se disant qu'est-ce qu'ils vont dire si je prends la tâche Ça permet de créer plus de communication. Ce que j'ai remarqué, c'est que maintenant j'ai des équipiers qui vont plus collaborer en one-on-one ensemble. Ils se sont mis des sessions hebdo où ils vont faire du pair programming. assez naturellement, parce qu'il y en a un qui a vu qu'il pouvait apporter du support à l'autre, ou l'autre a vu qu'il pouvait avoir de l'aide d'une autre personne. Du coup, ça crée vraiment une bonne cohésion. Si un collègue réussit son objectif, au final, c'est un peu toute l'équipe qui est contente parce qu'on a soutenu la personne. Donc ça crée vraiment une bonne ambiance de collaboration, plutôt que de le faire juste avec mon déclin en disant voilà, il y a un tel, un tel, un tel lui ça lui met une charge également pas une charge de travail supplémentaire là on fait un peu plus naturel et on fait le point régulièrement et puis c'est très malin parce que sinon même si tu passes l'info à la personne qui est tech lead derrière peut-être qu'un matin en daily elle va dire c'est
- Speaker #0
telle personne qui va prendre le ticket front on va pas comprendre pourquoi je suis un peu surprenant et limite il va se prendre des vannes tiens tu sais faire du front finalement je trouve ça hyper malin de mettre en commun enfin qu'il y ait des objectifs d'équipe où tout le monde est aligné, c'est bien, mais de mettre aussi en lumière les souhaits individuels de chaque personne pour que derrière, quand il y a des choix qui sont faits, on sache pourquoi. Finalement, ça me paraît très sain et je pense que c'est une super idée de faire ça.
- Speaker #1
Oui, et puis c'est plus naturel. C'est plus naturel que... C'est pas caché, nous dans notre équipe en tout cas, on a fait le choix de ne pas se cacher les choses, de garder une certaine transparence et puis de se fournir l'entraide qu'on peut. Du coup ça ouvre des opportunités un peu à tout le monde et ça crée vraiment une ambiance d'équipe plus conviviale, plus intéressante volontairement.
- Speaker #0
Et dans ton poste actuel, à quel point tu es impliqué encore aujourd'hui sur des sujets techniques ? Je pose une question, peut-être que se posent certains devs techniques qui se voient peut-être évoluer en tant qu'EM et qui ont peut-être peur, ou je ne sais pas, justement, tout dépend des souhaits de chacun et de chacune.
- Speaker #1
Alors, je dirais que ça va dépendre des équipes. Nous, aujourd'hui, il y a eu un peu des changements en termes d'organisation dans l'entreprise où on avait des managers plus hands-off, mais maintenant, on nous demande d'être un peu plus hands-on. Moi, pour ma part… Je ne suis pas une zone à 50% parce que parfois, actuellement, je n'ai pas de product manager, donc je fais un peu le backup du product manager. Je dirais que je fais entre 20 et 25% actuellement. Il m'arrive de soumettre des requests. mais je fais beaucoup plus de lecture de PR que j'en soumets. Je n'ai pas envie de me mettre sur le chemin critique, en fait. J'essaie de ne pas être un bloqueur pour mon équipe. D'autant plus que le challenge pour moi, c'est que je ne connais pas forcément les langages, donc il faut aussi que je monte en compétence dessus. Donc c'est bien parce que j'ai du support de mes collègues, ils sont assez sympas pour ça. Ils me disent, là, ils vont mieux que tu utilises quelle pratique, etc. J'ai des vieux réflexes de développeuse Java, des fois avec le PSP, c'est des choses étranges. Mais c'est intéressant. Donc voilà, je suis plutôt à 25%. Après je travaille beaucoup avec des partenaires avec qui on s'intègre sur les API et tout ça. C'est là où je suis un peu plus analysée dans API, vérifier comment ça fonctionne, si c'est compatible avec nous, etc. Je fais pas mal d'analyses de bugs opérationnels. les vérifier les logs tracer certains événements etc donc ça va être surtout des tâches très opérationnelles pour ce qui se passe en production pour aider l'équipe à traiter les problèmes en profondeur ok
- Speaker #0
ça marche très clair Et finalement avec tout ce qu'on raconte, il y a bien sûr un peu de technique en fond, mais on parle beaucoup d'humains, d'organisation, de communication, d'écoute. Selon toi, si quelqu'un vient te voir demain en te disant j'aimerais bien être engineering manager en termes de soft skills, notamment si on met le côté tech, qu'est-ce qui va être fondamental selon toi, chez une personne ?
- Speaker #1
Alors, pour devenir un engineering manager, je pense qu'il faut apprécier déjà le contact humain. Parce que quand on est ingénieur, on est plus à gérer des problèmes de système. technique. Quand on commence à devenir tech lead, c'est là qu'on commence à se rendre compte que la dimension humaine est importante dans le sens où la manière dont on va communiquer un message, dont on va être présent ou absent, finalement pour l'équipe, va changer la manière dont les personnes vont réagir. Je pense qu'il faut apprécier l'humain avec ses qualités et ses défauts, je dirais, globalement. Un point important, moi j'ai la chance je dirais de passer par ces rôles de Scrum Master et Coach Agile qui m'ont permis de prendre du recul finalement sur les dynamiques d'équipe. Surtout des principes autour de tout ce qui est psychologique finalement, d'équipe, composition d'équipe, la complementarité des profils dans une équipe, la diversité, l'importance de la diversité dans une équipe, tous les aspects un peu systémiques, si il se produit ça dans ton équipe, essayer de l'analyser un petit peu en prenant du recul, en regardant qu'est-ce qui va déclencher telle ou telle réaction ou telle ou telle situation. Je pense qu'il faut aimer prendre du recul sur ce point-là et s'intéresser à ces sujets-là. Pour moi, c'est un atout. Ça s'apprend sur le tas, mais ça peut éviter de faire des erreurs. Des fois, les erreurs de management sont difficiles à récupérer, plus que les erreurs techniques.
- Speaker #0
Si tu devais te rappeler tes premiers pas, justement, tes premiers mois en tant qu'engineering manager, c'est quoi qui était le plus dur ? Est-ce que tu t'en souviens ?
- Speaker #1
Alors, ça a été plus dur pour moi de devenir Scrum Master que de devenir engineering manager. Ou des fois, je pense que j'ai été un peu brutale avec certaines personnes dans des phrases que j'ai écoutées en vien, ou j'ai peut-être manqué l'empathie. et je me suis dit non, en fait là ce que tu viens de faire, ça va être dur à récupérer maintenant, tu vas pouvoir que tu t'accroches pour que finalement la relation fonctionne bien et je pense que c'est ça qui est le plus challengeant, c'est quand on est manager ou quand on est tech lead quel que ce soit le sujet que ce soit organisationnel ou technique je pense que le plus important c'est s'assurer qu'on va préserver la relation dans la manière dont on va s'exprimer dans les choix qu'on va faire dans les décisions qu'on va prendre je pense que c'est vraiment le point le plus important, c'est dire ok je suis pas d'accord avec cette personne, je suis pas d'accord sur son comportement je suis pas d'accord sur ce qu'elle a fait, ce qu'elle a dit, etc maintenant il va falloir que je trouve les bons moyens et la bonne manière de dire les choses pour que la relation soit préservée mais que ce qui nous a dérangé, ce qui m'a dérangé ne se reproduise plus c'est ça le plus difficile
- Speaker #0
D'accord, je comprends. Effectivement, quand tu as commencé par Scrum Master, tu as déjà eu ces sujets de gestion d'équipe et de l'humain que tu as appris sur le terrain. J'ai l'impression qu'il y a beaucoup d'apprentissage. Une petite question que j'avais en suivant, c'était quand tu es devenu EM, est-ce que tu t'es formé d'une façon ou d'une autre en interne ? Est-ce qu'il y a des gens qui t'ont donné des tips ? Finalement, c'est le terrain principalement qui t'a fait découvrir tout ça.
- Speaker #1
Je suis passée d'un rôle où j'étais plutôt une sorte de super Scrum Master coach agile dans une équipe, un rôle d'Engineering Manager. Je connaissais déjà très bien l'équipe et ses problématiques. Et au final, en tant que coach, j'avais une certaine frustration parce que je ne voyais pas des personnes passer à l'action pour mettre en place des choses dans cette équipe. Donc en tant que manager, pour moi ça a été un peu du pain béni dans le sens où je voyais exactement ce qu'il fallait faire, ce qu'il fallait mettre en place. Je voyais quelle personne aider, quelle personne faire changer de poste, etc. Parce qu'en tant que coach, j'avais vraiment passé beaucoup de temps finalement dans l'observation. dans l'écoute et dans le conseil, mais pas vraiment dans l'action. En tant que manager, du coup, pour moi, ça a vraiment été une libération parce que j'avais une certaine frustration finalement parce que quand on est dans ce rôle de coaching... le passage à l'action ne dépend pas de nous et je trouvais c'est ce qui me manquait en fait j'avais besoin de quelque chose de plus dans l'action de remettre en place les choses c'est
- Speaker #0
pas du coaching directif c'est au service des personnes tu proposes des choses après si elles ne sont pas passées à l'action tu ne peux pas forcer les gens donc là ça m'a moi j'avais vu des choses sur une équipe donnée
- Speaker #1
je me suis rendu compte que j'avais pour certaines choses bien vu pour d'autres ça n'a pas fonctionné comme je voulais et je dirais qu'on a bon fil du temps qu'aucune équipe n'est la même parce que de toute façon quand bien même on se travaille d'une équipe à l'autre avec des personnes identiques le contexte est différent il y a d'autres personnes en équipe, les relations entre les personnes sont différentes, on n'a jamais le même contexte il n'y a pas de recette magique finalement qui va marcher d'une équipe à l'autre parce que quand on essaie d'appliquer la recette magique la réaction va être différente le résultat va être différent donc c'est assez intéressant
- Speaker #0
C'est vrai que quand tu connais le contexte c'est vrai que c'est bien parce que tu sais déjà où tu mets les pieds mais c'est vrai que tu as une autre problématique à gérer c'est une relation qui change les gens se disent avant cette personne était Scrum Master j'interagissais avec elle sur tel sujet maintenant je vais devoir interagir différemment peut-être me confier davantage je pense qu'il faut un temps d'adaptation pour tout le monde aussi
- Speaker #1
Oui, tout à fait.
- Speaker #0
Super. En tout cas, il y a un point que tu as mentionné pendant qu'on parlait il y a quelques minutes, qui était le fait que vous étiez une équipe qui fonctionnait en full remote. Donc avec des personnes qui sont je crois un peu partout en Europe, tu me confirmes ?
- Speaker #1
Oui, tout à fait. Je crois qu'au maximum on s'est retrouvés sur cinq pays différents. Là actuellement on est sur quatre pays, avec différentes nationalités et cultures mélangées, donc c'est assez intéressant.
- Speaker #0
J'imagine que ça a amené pas mal de défis aussi, parce que travailler en full remote, c'est sûr qu'aujourd'hui beaucoup de gens aiment bien, pour plein de raisons évidentes, mais il faut arriver à maintenir un équilibre d'équipe, une vie d'équipe, mettre en place des choses qui fonctionnent bien, qu'on arrive quand même à se parler, à interagir, sans toujours parler uniquement quand on a besoin de questions, etc. Et je sais que tu as parlé de ce sujet-là spécifiquement au dernier DevFest à Toulouse, sur le management d'équipes qui fonctionnait comme ça en 100% remote. Donc ça m'intéressait d'avoir un peu plus d'insights à ton côté là-dessus. Donc voilà, comment tu as construit cette culture-là ? Est-ce que toi, quand tu étais Scrum Master, il y avait déjà des choses en place ? Qu'est-ce que tu as apporté en plus en tant qu'Engineering Manager ?
- Speaker #1
Du coup, le pool remote, moi je l'ai connu uniquement sur le Core Store. Donc je suis arrivée chez Encore Soir en 2022. La première fois que j'ai travaillé en following mode, comme beaucoup de personnes, c'était au moment du Covid et du confinement. J'ai vraiment pas aimé ça. Parce que je pense que c'était pas un choix. Je pense que quand on subit des bugs, on les aime pas trop en fait. Mais là chez Encore Soir, ça a été vraiment un choix pour moi. Et à la différence de mon rôle précédent où j'étais engineering manager sur place, c'est-à-dire que j'allais au bureau régulièrement, je voyais régulièrement les flèches. Là j'avais un nouveau défi, pour moi en tant que GMAS c'était vraiment un défi d'avoir une équipe full remote. Ils étaient très visuels, ils mettaient beaucoup de choses sur les murs, ils créaient des tableaux pour les équipes, bref. La réunion qu'on faisait, il y avait un support visuel à la fin. Donc j'ai remplacé ça par des éléments dématérialisés, donc on travaille beaucoup avec Miro entre autres, mais bon il y a plein d'outils qui permettent ça. ce qui fait qu'à chaque réunion, effectivement, il y a un miroir ou une page l'enfer, etc. J'ai toujours ce côté de dire, voilà, ou bien la substance importante de la réunion à garder en tête, tout est noté là.
- Speaker #0
J'ai gardé ces habitudes d'une manière différente. Après, la première difficulté a été de construire une culture d'équipe et de confiance. La chance que j'ai eue, c'est que mon équipe était nouvelle quand je l'ai rejointe. Au début, on était trois, donc c'était bien. On a appris à se connaître. Du coup, à trois, c'est plus facile. Il y a des canaux de communication. Ils sont simplifiés, on a pu faire pas mal de travail en paire, à deux, etc. Ça permet de donner des bonnes habitudes, d'être dans une relation de confiance, de comprendre comment fonctionnaient les uns les autres, où allaient être les blocs cachés les uns les autres. On a vite fait connaissance comme ça sur les premiers mois, puis après l'équipe a grossi. Donc là il a fallu que, j'ai pas eu d'affaire de recrutement externe, c'était plutôt des mouvements d'équipiers entre équipes en interne. Donc là il a fallu que j'identifie finalement les collaborateurs qui allaient matcher dans mon équipe en terme de caractère, de séniorité. A distance c'est pas évident. parce qu'à distance j'en ai parlé pendant la conférence on n'a pas cette machine à café etc donc on voit un peu la tête des infos des fois on contacte un tel ou une telle pour avoir des informations comment ça s'est passé dans ton équipe est-ce que tu vois tel profil avec telle personne dans ton équipe on force un peu les échanges pour justement avoir le ressenti des autres, c'est assez intéressant après on ne bosse pas que sur ça merci On se base aussi sur notre propre expérience. Mais oui, ça fait partie des challenges qu'il peut y avoir en remote. Et notamment les moments informels en équipe pour les remplacer. Donc nous, ce qu'on fait, c'est qu'une manière hebdomadaire, on se met un temps off le vendredi après-midi pendant une petite heure, une autre quart d'heure. Souvent on fait des jeux en ligne, on change de jeu régulièrement, on trouve des jeux de plateau en ligne, en asynchrone, donc c'est assez sympa. La culture de la synchrone est assez importante quand on est en full remote. Donc ça passe beaucoup par l'écrit ou les enregistrements de réunion par exemple. Ça c'est quelque chose que je trouve assez différent par rapport au travail au bureau. Vraiment la culture de l'écrit est quand même plus importante. Ce qui est bien parce que parfois il y a des choses où spontanément au bureau on va aller déranger les personnes. Mais en fait quand on les écrit, parfois on se dit Ah ben c'est bon, j'ai trouvé la solution. Juste en écrivant parce qu'on a pris ce temps pour mettre les choses à plat. Et au final, on s'est débloqué soi-même. Donc ça c'est vrai, c'est un des côtés intéressants.
- Speaker #1
Il peut y avoir aussi parfois un travail de réajustement à faire, parce que je suis remarqué aussi que toutes les personnes ne s'expriment pas de la même manière à l'oral qu'à l'écrit. Et parfois, il peut y avoir... Alors, je pense que c'est bien qu'il y ait les deux, forcément, parce que quand tu connais en plus pas trop la personne, tu peux avoir tendance à peut-être mal interpréter des choses qui sont dites à l'écrit sur un ton. Tu peux peut-être te sentir un peu agressé sur un truc, ou tu n'es pas sûr si la personne sur quel ton elle le lit.
- Speaker #0
parce que je n'en sais rien elle n'a pas mis un smiley alors que toi t'en mets enfin t'as peut-être des trucs comme ça des fois aussi oui oui oui j'ai juste les mots utilisés ça m'est arrivé une fois de demander à te dire un collègue s'il te plaît édite ton message ne dis pas je vois ce que tu veux dire je comprends ne le dis pas comme ça s'il te plaît parce que là ça mettait un peu de ville sur le feu et ça allait amener la situation vers On vient des échanges un peu musclés.
- Speaker #1
Oui, surtout qu'en plus, peut-être que tout le monde n'est pas English native. Peut-être que c'est la seconde bande de beaucoup de monde. Donc, il y a peut-être aussi des fois des conflits à ce niveau-là.
- Speaker #0
Oui, il y a des erreurs. Ça m'arrive également de mal taper ou de mal orthographier. Donc, c'est vrai que ça peut être des choses qui peuvent être bloquantes, effectivement, dans le maths. Je pense que c'est important, et d'ailleurs même quand on recrute finalement des personnes sur les postes remotes, je pense que c'est important de vérifier à quel point elles adhèrent à cette philosophie de travail, parce que c'est vraiment une philosophie de travail. C'est un choix d'entreprise, ça fait partie de l'acquisition de l'entreprise. À quel point elles adhèrent ? Comment elles communiquent ? Si elles n'ont jamais travaillé en remote, comment elles se projettent ? Dans ce contexte-là, je pense que ça fait effectivement partie des choses qu'il faut bien valider pour être sûr que les personnes sont compatibles. Tout le monde n'est pas compatible. Donc, c'est comme ça.
- Speaker #1
Et en mis les temps d'échange que vous avez informels le vendredi, est-ce qu'il y a peut-être des daily chaque matin où vous faites ça en vision ? C'est un petit message écrit, c'est quoi ?
- Speaker #0
Oui, alors nous c'est assez classique, on fait un daily tous les matins, de manière vraiment classique. Une fois par semaine on le fait en asynchrone, parce qu'en interne on a ce qu'on appelle le tech Friday. Donc une fois par semaine on le fait en asynchrone, et après la journée c'est mis en place aussi certains codes de communication. Par exemple, quand on utilise l'environnement de test, on travaille avec Slack, donc on a un canal dédié de l'équipe. Et par exemple, plutôt qu'à chaque fois envoyer un message je vais utiliser l'environnement de test etc., on met à jour le statut de notre équipe dans Slack en disant environnement de test occupé par un tel On s'est mis en place des outils comme ça, on travaille beaucoup avec des notifications automatiques aussi sur ce qui se passe en production, donc on est alerté de manière rapide quand il y a des problèmes. On a un système d'alerte qu'on utilise. Tout ça permet de travailler efficacement.
- Speaker #1
Pour éviter que la synchrone crée parfois trop de détranglement, un petit peu de frustration, vous vous êtes mis aussi des codes, des règles sur de telle heure à telle heure on est là. Parce que parfois quand tu es en remote, tu peux avoir ce côté un peu... J'allais dire, peut-être plus informel de je mange un peu plus tard ou j'ai mon truc à faire, donc ma mission je la fais et je la finirai peut-être à cette heure-ci ou un peu plus tard dans la soirée parce que je vais sortir 5 minutes Vous avez défini un peu des moments, comment dire, si je vais être beaucoup trop loin, j'irai des et c'est le temps de réponse ou limite au bout de deux heures de pas de réponse, c'est pas cool pour la personne, il n'y a pas besoin d'aller jusque-là.
- Speaker #0
On n'est pas allé jusque là dans notre équipe parce qu'il n'y a pas eu de besoin. Après ça ne veut pas dire qu'il n'y a pas d'autres équipes qui l'ont fait, mais je pense que ça dépend vraiment du besoin. Je sais que parfois j'ai des collaborateurs qui peuvent avoir des rendez-vous médicaux dans la journée, ils vont les prendre et effectivement... Il y a des fois où je me suis trouvée moi-même à dire c'est sûr que vous travaillez si tard, c'est OK avec ça Je suis plutôt dans l'autre sens où je vois que mes collègues ne sont pas perfectionnistes, mais ils ont envie vraiment de faire leur boulot jusqu'au bout correctement. Comme beaucoup de développeurs, ils ont aussi une certaine passion dans ce qu'ils font. Et des fois, c'est vrai que j'aurais été plutôt du genre à dire ouais, t'étais pas d'astreinte voilà, une PR à minuit peut-être que je peux attendre demain quoi, c'est pas grave je sais, voilà, c'est plutôt ça où je vais plutôt faire voilà, avoir le côté un peu protecteur, je dirais mais juste fais attention à ton équilibre vie pro, vie perso, te mets pas en péril parce que oui, sur le projet il faut qu'on avance et bien sûr il y a toujours, voilà, l'envie de décliner vite au revoir mais il faut quand même respecter une certaine équipe et pareil des fois je vois des collègues ça arrive qu'on travaille beaucoup dans mon équipe en tout cas on est sur des sujets logistiques on travaille beaucoup avec des partenaires externes dont on ne contrôle pas toujours les problèmes qui peuvent y avoir une certaine frustration des fois de la fatigue quand il y a des incidents qui sont liés aux partenaires on se fait aussi des incidents internes externes pour voir ça peut fatiguer un peu les personnes parfois je viens d'écouter toi. Si tu as besoin de prendre ta journée demain, tu la prends, on assure un reste avec l'équipe. Voilà, tu as fait ton max aujourd'hui, je vois que tu arrives un peu à tes limites, point du recul quoi. C'est aussi mon rôle en tant que manager quoi, je sais qu'ils vont donner beaucoup de même. mais moi j'ai besoin qu'il dure autant que ce soit pas juste un one shot et qu'après la personne elle soit cramée ouais c'est pas je fais assez attention d'avoir ce préservé très clair et dans
- Speaker #1
un précédent podcast j'avais un invité, Mickaël Véguerich qui travaillait beaucoup en remote aussi mais qui disait, c'est important quand même pour moi de voir au moins une fois et ensuite de temps en temps les équipes parce qu'il disait que la La relation que tu as avec quelqu'un, elle change dès lors que tu la vois en vrai et que tu échanges avec elle. C'est une question rapide, est-ce que tu es d'accord avec ça ? Et est-ce que vous vous voyez régulièrement justement en physique ?
- Speaker #0
Oui, on se voit régulièrement. L'objectif c'est d'être au joint une fois par trimestre. Mais bon, ça dépend des budgets disponibles qui sont alloués en interne, on va dire surtout le service tech. Donc on essaie de se voir régulièrement. Après, ça me fait toujours super plaisir de se voir tous ensemble parce que forcément on va partager le moment d'un repas ou autre, ce qu'on ne va pas forcément faire. C'est un peu moins agréable de manger en visio. Voilà, on se regarde. Voilà, c'est pas le truc le plus naturel. Mais étrangement, j'ai pas senti un gros changement dans les relations entre les personnes. C'est toujours un plus, c'est toujours un plus dans la dynamique, parce que parfois, on va aussi prendre le temps peut-être de faire des workshops un peu plus chronotables. En remote, on prend l'attention au temps qu'on passe en ligne. C'est aussi éprouvant de passer une heure et demie en visio. C'est pas génial. Donc généralement, on limite plutôt les temps de réunion entre 40 minutes et 50 minutes. Mais c'est vrai que quand c'est des grosses séances là, on préfère les faire ensemble. C'est pour ça qu'une fois par trimestre c'est bien, parce que nous justement, comme on est sur des objectifs collectifs, ils sont changeants à peu près tous les trimestres. Des fois on peut garder les mêmes pendant 6 mois, 11 mois, voire un an. Mais du coup c'est bien, le trimestre c'est un bon rythme pour nous. Après voilà, ça dépend des équipes. J'ai vu qu'il y avait d'autres entreprises qui faisaient des passages obligatoires au bureau tous les mois ou toutes les deux semaines. Je pense que ça dépend du fonctionnement. Nous à la tech on est tous en full remote, ce qui fait qu'il n'y a aucune équipe qui se retrouve sur site. Donc chaque équipe finalement est assez autonome dans la manière dont elle va s'organiser.
- Speaker #1
D'accord, parce que je me demandais si d'une équipe à l'autre, vous aviez défini quelques guidelines avec les EM, partagez quelques tips, bonnes pratiques, ou peut-être vous le faites, mais dans la pratique, peut-être que notre équipe sur notre projet fonctionne de manière très différente. C'est ça.
- Speaker #0
On n'a pas tous les mêmes périmètres et les mêmes contraintes, à la fois techniques et business. Donc du coup, on est assez libre de s'adapter. Moi, par exemple, je crois que mon équipe, c'est la seule équipe qui ne fait pas de Scrum, ce qui est assez marrant. On a des sujets très opérationnels, c'est plus pratique pour nous de travailler de cette manière-là.
- Speaker #1
Ok super, est-ce que en conclusion de cette partie là on pourrait dire que finalement si tu vois pas un gros delta quand les gens se rencontrent en vrai, est-ce que ça veut dire que finalement tu fais bien ton travail de cohésion et le fait que chaque personne travaille bien ensemble, se connaissent bien et que finalement quand on se voit c'est presque c'est cool mais c'est pas game changer parce que voilà on fonctionne bien, on se connaît bien, on se connaît bien, finalement je pense que tout le travail que tu fais ça sert à ça.
- Speaker #0
Oui c'est vrai, après c'est ma perception. Donc c'est vrai que je ne vois pas de différence, je sais que mes collègues voient la différence, mais comme moi j'ai des points de contact réguliers avec tout le monde, j'ai peut-être aussi cette proximité qui se fait avec tout le monde de manière un peu plus forte que d'autres. Mais oui ça fait partie effectivement de mon boulot en tant que manager, créer des conditions de réussite c'est vraiment... Voilà ce que j'essaie de mettre en place, après la cohésion d'équipe et puis après m'assurer qu'individuellement, dans le cadre de cette cohésion d'équipe et de cet objectif de performance, parce qu'au final, en tant que manager, on est là pour ça, aussi les personnes individuellement s'y retrouvent.
- Speaker #1
Merci beaucoup Virginie pour toutes ces infos, tous ces éléments, c'est très riche. J'aurais encore plein de questions que je pourrais approfondir, mais je vois que l'horloge tourne, on arrive bientôt en fin de ce podcast. Avant de passer à la dernière partie sur tes recodes lectures, j'avais une petite question traditionnelle que je pose à toutes les personnes que je reçois dans le podcast. Je serais curieux d'avoir rapidement ton avis sur la Gen AI dans le contexte du dev, tous les outils qui arrivent massivement. de tous les coding assistants, tout ce que les devs ont aujourd'hui à disposition. C'est quoi ton avis là-dessus ? Est-ce que tu es plutôt enthousiaste, méfiante ? Comment tu vois les choses ?
- Speaker #0
Je suis plutôt enthousiaste parce que ça peut permettre à des équipes, justement, si elles utilisent un modern dia commun, de plus facilement réaliser les bonnes pratiques ou les fois internes. Moi je vois ça plutôt d'un bon oeil dans cette utilisation-là. Nous on est nombreux à utiliser Copilot. Ça c'est pas un grand souci. En interne, on a même une IA d'entreprise qui est utilisée. Je pense que c'est un outil qui s'appelle Dust. Mais voilà, même en interne, on a une IA qui est alimentée par nos sources internes, ce qui permet à tout le monde parfois d'être plus efficace quand on recherche des informations. Donc ça peut vraiment aider. Et moi, à titre personnel, effectivement, en tant que manager, j'utilise pas mal Grammarly pour rephraser des fois ce que je peux dire, m'assurer que c'est entendu la tonalité que je veux utiliser, si je veux être sympa, si je veux être formelle, etc. Je trouve que c'est pas mal. Je trouve qu'il y a plein d'outils qui peuvent aider et qui peuvent faciliter la collaboration et la communication.
- Speaker #1
Ok, top, donc plutôt enthousiaste.
- Speaker #0
Oui, oui, oui. Après, il faut l'utiliser, bien sûr.
- Speaker #1
Bien sûr. Toujours. Excellent. Et autre tradition, comme je le disais, est-ce que tu as des recours de lecture ou de visionnage à partager avec nos auditeurs et auditrices ?
- Speaker #0
Oui, alors j'ai quelques recommandations pour peut-être des ingénieurs, des développeurs qui aimeraient aller vers du management. Je pense que l'aspect facilitation est super important. Et moi, il y a un livre que j'ai utilisé qui s'appelle Game Storming, qui est vraiment pas mal. Et après sur le côté plus managérial, il y a un livre que j'ai trouvé vraiment super bien. C'est un français qu'il a écrit, c'est Dream Team c'est Ludovic Giroudon. Il est vraiment très bien ce livre, surtout pour débuter en tant que manager. Je pense qu'il y a toutes les recettes de base. Après, il faut faire évoluer les recettes au fil du temps. Mais il y a vraiment les bases.
- Speaker #1
La cohésion d'équipe notamment, le management ?
- Speaker #0
Sur le management, la cohésion d'équipe, sur tout ce qu'on peut rencontrer dans le management, c'est-à-dire la préparation des entretiens, la gestion des one-on-one, identifier finalement ceux qui sont au top de l'équipe. ceux qui sont peut-être moins performants dans l'équipe, comment les aider à mieux performer, etc. Il y a vraiment beaucoup d'éléments dans ce livre qui sont intéressants.
- Speaker #1
Ok, excellent. Est-ce que par hasard la conférence dont j'ai évoqué sur Odefest 2003 est disponible en ligne ?
- Speaker #0
Oui, il semble qu'elle est accessible bien le site du DeppFest et sur YouTube également.
- Speaker #1
D'accord, je mettrai également le lien, tu pourras la retrouver facilement. Excellent. Merci beaucoup Virginie pour ces recos. Ça fait tout presque bientôt 50 minutes qu'on discute, Virginie, de sujets hyper intéressants. Comme toute bonne chose, ça a une fin. je te propose qu'on s'arrête ce huitième épisode. Encore une fois, j'aurai plein d'autres sujets hyper intéressants à aborder avec toi, mais c'était déjà hyper riche et je suis sûr que le contenu va intéresser beaucoup de personnes. Premièrement, je te remercie beaucoup pour tous les éléments que tu nous as partagés. J'espère que tu as passé un bon moment aussi à les partager avec moi. Je te souhaite plein de bonnes choses pour la suite.
- Speaker #0
Merci Cédric et merci d'avoir donné la parole dans ton podcast c'est une première et je suis super contente de l'avoir fait tant mieux,
- Speaker #1
peut-être je te le souhaite, ce ne sera pas la dernière mais content de t'avoir proposé cette expérience et puis je te dis à très bientôt et encore merci pour tout Virginie
- Speaker #0
Avec plaisir
- Speaker #1
A bientôt, et quant à nous chers auditeurs auditrices, on se retrouve très bientôt pour un neuvième épisode de Tech Lead Corner. Bye bye.
