Construire une équipe Product & Engineering résiliente : organisations et processes

0:00 Il y a aussi des questions pour sonder un petit peu où vous en êtes. Mais voilà, donc 30 minutes, 30 minutes. J'en dis pas plus et je laisse, Olivier, je te laisse la main. Ça te va? Oui, merci Lucas. Bonjour à tous. Écoutez, ravi de se rencontrer, ravi de passer cette heure tous ensemble. Comme Lucas l'a dit, moi j'ai prévu un certain nombre de slides et du contenu, mais je vais vous sonder régulièrement pour un peu orienter et m'assurer qu'on couvre les sujets qui vous intéressent. Et puis après, on aura du temps encore sur les Q&A s'il y a des sujets que je n'ai pas traités et qui vous intéressent. Que vous voulez qu'on aille creuser. Du coup, très rapidement, donc ça, c'était le point de départ un peu qu'on avait discuté avec Lucas et l'équipe de Tech.Rocks. Donc, je me suis pas mal inspiré de ce point de départ-là. Je me présente rapidement. Donc, moi, je suis CTO, CTO, j'étais en charge de l'équipe product sur les deux ans et demi.

1:05 Mais à la base, je suis vraiment plus côté CTO. Je suis chez BlaBlaCar depuis 2017 et avant, j'ai eu une longue expérience chez Apple en France et aux US pendant 13 ans. Et depuis 4-5 ans maintenant, je fais pas mal d'engine investing, dont je crois certaines boîtes qui sont représentées aujourd'hui. Et je fais pas mal de coaching de CTO et de VP Engineering. Et j'ai toujours... Moi, j'aime beaucoup ça. Ça m'aide aussi à lever la tête du guidon. Donc, ravi de le faire encore une fois aujourd'hui. Donc au menu aujourd'hui, un peu ce que quand je réfléchissais au sujet avec Lucas, il y avait plusieurs directions possibles. Celle vraiment de départ qui était résilience d'une organisation product engineering et j'ai un certain nombre de slides là-dessus.

2:08 Mais je voulais aussi traiter un peu de la résilience individuelle, votre résilience à chacun, soit comme engineering leader, soit comme CTO. Il y a certaines problématiques qui sont vraiment, je trouve, spécifiques au rôle de CTO et un peu à faire la connexion avec le reste de la société, le reste des autres fonctions. Une chose sur laquelle, moi, ravi d'en parler, mais pour le moment, ces slides-là, elles sont plutôt en appendix, c'est la résilience de votre produit, de votre plateforme tech. Donc ça, dites-moi si vous voulez qu'on en parle, mais je me suis plutôt concentré sur les premiers aspects. Je voulais commencer par, juste, en fait, c'est quoi la résilience? Et moi, la définition de laquelle je suis parti, c'est la capacité. du coup individuel ou d'une organisation à s'adapter à un stress. Et quand je réfléchissais, je me suis dit, ah tiens, est-ce que c'est un stress forcément externe ou est-ce que ça peut être un stress interne?

3:09 Et j'ai décidé de traiter les deux. Et donc, ma première question pour vous, c'est quel type de stress peut avoir à affronter une équipe product engineering? Et à quoi avez-vous déjà été confronté? Et je suis ravi qu'on prenne peut-être 20-30 secondes pour soit lever la main, soit dans la fenêtre de discussion, que vous me disiez c'est quoi les enjeux que vous avez déjà eus, c'est quoi les problèmes auxquels vous avez déjà été confronté? Et ça me permettra aussi d'orienter ensuite la suite de la discussion. Ok, première réponse. Peut-être, Sian, sur delivery, je veux bien que tu me précises. C'est quoi? C'est la delivery ne va pas assez vite ou problème de delivery? C'est la timeline du delivery.

4:11 Donner une timeline et s'y tenir? Et s'y tenir avec un scope business prédéfini. Okay. Guillaume, même question peut-être sur toi, sur gouvernance. Est-ce que tu peux préciser? Oui, bien sûr. Juste pour donner un peu de contexte, moi, je suis un jeune CTO et ma première expérience, on n'était qu'une équipe de tech de cinq personnes. Et je sais que pendant ma première équipe, on avait des problèmes de gouvernance, c'est-à-dire que mon premier CTO, avant que je sois CTO, avait du mal à faire entendre ses idées. Et le classique du stand-up, avec quelqu'un qui remet en doute le stand-up, et donc ce dialogue qu'il y a eu, où moi j'avais pris ce rôle d'effectuer de la gouvernance. Mais comme là, je suis dans ce projet-là de commencer à... construire une équipe technique. Je suis assez curieux de savoir c'est quoi les pain points et surtout c'est que là je suis encore libre de choisir le chemin que je vais prendre, même s'il va à chaque fois être modifié, mais c'est plus facile au début de pouvoir façonner quelque chose.

5:13 Et donc j'avoue que si tu as des conseils à donner sur ce sujet, je suis totalement preneur. Ok, je ne sais pas si... Ravi de partager un peu mon expérience. Merci à tous ceux qui ont mis des commentaires, ça m'aide. Alors, je vais... On va parler, alors attendez, là-dedans, il y a pas mal de trucs autour de, on va dire, les sujets, un peu interaction entre équipe product et engineering. Du coup, j'ai bien envie de démarrer par ça. Qualité des engagements forecast, compétition et vitesse 1, efficience, relations, etc. Du coup, je vais peut-être démarrer par ça. Alors, attendez. Ouais, stress, product, business. Moi, c'est comme ça que je l'ai appelé un peu le côté, tiens, quand il y a un antagonisme qui se crée entre les équipes product,

6:15 Et business, et je pense que c'est peut-être intéressant aussi qu'on creuse là-dessus sur business, product et engineering. Et donc moi, ce que j'ai constaté, je trouve qu'il y a intéressant de… c'est intéressant de mettre le doigt dessus, c'est que souvent, il y a un vrai enjeu de timing où une équipe business et par extension, un peu une équipe produit a envie de mettre rapidement quelque chose en prod, soit pour apprendre des utilisateurs, soit pour impacter positivement le business plan et améliorer le revenu, etc. Là où l'engineering qui voit un peu le côté à tiens, une fois que c'est en prod, il va falloir que je le maintienne dans le long terme, a un peu cette angoisse de, oui, je pourrais aller vite, mais dans ce cas-là, je vais prendre de la dette technique. Que en tant qu'équipe engineering, je vais être tout seul après à porter et dont souvent les équipes business et product n'ont pas conscience.

7:27 Souvent, moi, ce que j'ai constaté, c'est qu'il peut y avoir un peu une crispation du coup de… et des équipes qui ont du mal à se parler parce que ça devient, tiens, l'équipe engineering freine des cas de fer parce qu'ils voient que, Aller vite, ça voudrait dire se mettre à risque après sur le long terme. Parfois même, ça a été, ils ont eu et essayé d'avoir la discussion, mais en fait, assez rapidement, une fois qu'ils ont mis en prod, On les fait passer sur d'autres sujets produits. En fait, il n'y a jamais eu l'occasion de revenir sur cette dette technique qu'on avait créée. Et là, pour moi, il y a un vrai sujet qui doit être porté par les CTO, les VP Engineering, et peut-être collectivement par l'équipe Engineering sur... En fait, expliquer ces enjeux-là, ce« oui, on peut aller vite sur telle fonctionnalité, peut-être que d'ailleurs, même pour l'utilisateur, ça ne fera pas une grosse différence,

8:29 mais c'est un raccourci qu'on prend à court terme et qui va nous coûter dans le temps. » Et de soin de vie, j'aime assez l'idée de dette technique parce qu'elle raconte bien l'histoire de, en fait, on s'accélère sur le court terme, on reçoit le prêt de la banque, on peut dépenser cet argent, mais en fait, en vrai, on s'est engagé à le rembourser sur le long terme et avec des intérêts. Et c'est quoi les intérêts quand on parle de dette technique? Pour moi, les intérêts, ça va être un mix de peut-être reliability qui n'est pas la bonne ou qualité qui n'est pas la bonne pour l'utilisateur final ou ça peut être diminution de la vélocité des équipes. Et je crois que si on n'explique pas ça, en fait, c'est difficile de faire toucher du doigt des équipes product et business qui n'y comprennent rien, entre guillemets, enfin, en tout cas, qui n'ont pas une connaissance fine des sujets engineering. Et du coup, on ne peut pas vraiment avoir cette discussion à tiens, qu'est-ce qu'on optimise? Est-ce qu'on cherche vraiment juste à optimiser le court terme? Qu'est-ce qui se passe sur le prochain sprint? Où est-ce qu'on essaye d'optimiser sur où est-ce qu'on sera dans deux ans ?

9:33 Et finalement, les choix qu'on va faire dans ce cas-là, ce n'est forcément pas les mêmes. Et c'est pour ça que je parle un peu d'une nécessité, d'une empathie croisée entre les équipes. Je crois que c'est important que les équipes business et product comprennent ces enjeux-là. Et ça ne veut pas dire qu'ils soient capables d'aller réparer de la dette technique, mais en tout cas qu'ils y soient sensibilisés. Mais à l'inverse, et j'ai vu aussi ce biais-là, So... Ce manque d'empathie là aussi des équipes engineering et avec parfois des équipes engineering qui sont là non mais en fait moi ces sujets business je m'en fous en fait à la fin c'est important que les équipes d'ingénieurs se rappellent que c'est ça qui paye leur salaire et donc ben non en fait ça les intéresse le succès de la boîte et c'est pas engineering contre business et products c'est en fait ensemble comment est-ce qu'on a la bonne discussion pour atteindre les objectifs de la boîte donc là je crois qu'il y a vraiment un sujet de

10:36 raconter les enjeux des uns et des autres et d'éviter un peu que chacun se mûre dans une approche un peu simpliste de« Ah, mais tiens, les équipes engineering, elles essayent toujours d'augmenter le scope» ou« Ah, tiens, ça prend toujours beaucoup plus de temps que ce que ça devrait» versus des équipes business et product qui seraient« Ah, mais on ne fait que des trucs hyper crades, hyper rapides». Je crois qu'en fait, c'est important de discuter ensemble de… Et honnêtement, il n'y a pas une réponse unique. Parfois, ça peut être, ah tiens, il y a tel sujet où on a envie de mettre très rapidement en prod quelque chose parce que ça va nous permettre d'apprendre. Parfois, c'est en fait cette brique-là, c'est une brique importante et sur laquelle ensuite on va itérer et on va construire d'autres choses. Ça ne sert à rien de prendre des raccourcis et d'essayer de faire un hack parce qu'en fait, à la fin, cette brique-là, elle fait partie de la vision. Autant construire le… l'intégralité du scope correctement tout de suite, ça nous fera gagner du temps pour la suite. Peut-être le dernier élément que je rajouterais là, c'est je crois que créer des…

11:47 pardon, aligner des périmètres et que du coup les équipes product, enfin un PM soit bien aligné avec une équipe engineering en termes de scope, en termes de périmètre. Ça aide beaucoup parce que ça permet ensuite d'avoir des conversations communes et que ce soit collectivement un PM et une équipe engineering qui soit responsable d'objectifs communs. Et ces objectifs communs, c'est important qu'il y ait un mix dedans de peut-être des choses assez court terme, de« tiens, on veut shipper telle nouvelle feature» ou« on veut explorer telle nouvelle fonctionnalité produit», mais aussi des objectifs long terme de« reliability, sécurité, qualité du code et de la stack». Et qu'ensemble, cette équipe-là sur ce périmètre-là puisse discuter ensemble de c'est quoi les objectifs sur chacun des sprints et à un peu plus long terme, sur les 3-6 prochains mois, quels objectifs ont se créé en commun et que ce ne soit pas, tiens, d'un côté l'équipe produit qui tire pour aller

12:52 à toute vitesse et prendre le plus de raccourcis possible et de l'autre côté l'équipe engineering qui soit le pied sur le frein en train d'essayer un peu de limiter la casse, limiter... les dégâts, mais sans expliciter quels sont les risques que ça fait porter au business sur le long terme. Peut-être que je vais m'arrêter là, ça va me permettre de lire, il y a des commentaires qui ont été ajoutés, mais si vous voulez réagir à ça, peut-être ravi de soit creuser, soit prendre des réactions. Si personne ne se lance, moi j'ai une petite question par rapport à ça. Moi, j'ai un contact où, quand on parle de dette technique, Il me dit toujours que ce n'est jamais le bon terme et me pousse toujours en avant le terme du debt fonctionnel. En disant que l'idée, c'est qu'avec la dette technique, on crée potentiellement un gap de communication avec les autres équipes. Il dit que le debt fonctionnel, c'est intéressant parce que ça permet de sensibiliser le reste des équipes à dire, voilà, si on fait ça rapidement, ça a un coût.

13:54 Et ce coût-là va se répercuter sur la prochaine feature. Et donc, à quel point c'est en accord avec ça? Et j'aime bien cette approche, je ne sais pas si c'est ça. Dis-moi. Est-ce que tu es capable de me préciser un peu quelle différence tu fais entre dette technique et dette fonctionnelle? Peut-être qu'elle est minime ou limitée? Dans la façon dont il me le communique, Je n'ai pas sensiblement l'impression qu'il y a une vraie différence avec ce purement technique, mais c'est juste de faire comprendre que la dette technique, Et aussi souvent fonctionnel, puisque après, potentiellement, problème de mise en prod et donc de fonctionnalité, etc. Mais c'est juste dans la façon de le vendre, de le communiquer. Oui. Oui, enfin, je n'ai pas un avis hyper fort là-dessus. Peut-être moi, la manière dont je le décris, c'est en fait, souvent, la discussion avec des équipes product et business, elle s'arrête à une équipe engineering qui dit, attendez, il faut qu'on…

15:00 termine de faire telle ou telle chose pour telle feature, qui est déjà en prod, parce qu'on a pris des raccourcis, Et la discussion, rapidement, elle est coupée en mode, bon, mais en fait, si ça ne change rien pour l'utilisateur final, on s'en fout. Et or, je crois que c'est intéressant de parler un peu de tout ce qui se passe sous la surface de l'eau. Et il y a une petite partie qui est, qu'est-ce que l'utilisateur final boit? Mais il y a un certain nombre de choses, et tu vois, moi, que je classifie un peu dans quatre dimensions. Il y a les aspects qualité. Parfois, ça marche très bien pour 95% des utilisateurs. Est-ce que vraiment, on s'en fout des 5% d'utilisateurs finaux? Tu as les aspects sécurité, ça marche peut-être parfaitement bien pour l'utilisateur final, mais en fait, ce n'est pas sécure ou ce n'est pas compliant d'un point de vue privacy, etc. Il y a les aspects scalabilité, ça marche peut-être très bien pour aujourd'hui, on a 100 utilisateurs de la feature et ça marche très bien pour eux, mais en fait, passer à 1000 ou 10 000 ou 100 000, ça ne marcherait pas.

16:06 Et le dernier aspect, c'est l'aspect reliability. Ça marche peut-être très bien, mais avec un taux d'erreur ou taux de latence qui ne sont pas les bons. Et tout ça, c'est des trucs où à la fin, tu peux dire, oui, ça marche très bien pour l'utilisateur final, donc j'en ai rien à foutre, on continue et on passe à la feature suivante. Pardon, j'en ai oublié un, mais qui est vélocité de l'équipe, qui revient un peu à ce que tu disais de, attendez, en fait, on a fait, des hacks, où on a coupé des branches, et du coup, on a une complexité dans le code qui n'est pas répercutée forcément à l'utilisateur final, mais qui, le jour où on va vouloir continuer à itérer sur ce code, où il faudra fixer des bugs, où il faudra faire de la maintenance, en fait, ça nous coûtera plus cher. Et donc, ces différents aspects-là, je crois qu'ils sont hyper importants à communiquer, effectivement, et ça permet de faire toucher du doigt à des gens qui ne sont pas côté engineering, de, en fait, voilà un peu ce qu'on a coupé, ce qu'on a pris comme raccourci. Et voilà pourquoi, bien que la feature soit peut-être en prod pour les utilisateurs, on a encore du travail à faire.

17:14 Et d'ailleurs, peut-être que même, et à un moment, je pense que c'est intéressant de step back et de dire, en fait, ça ne sert à rien de, pour certains types de features, ça ne sert à rien d'essayer de sprinter et de mettre en prod quelque chose qui n'est pas complètement fini et peut-être qu'on ferait mieux de prendre quelques jours de plus pour... Pour terminer de manière plus complète et pouvoir se dire non on a vraiment fini et on met tout ça de derrière nous plutôt que plutôt qu'avoir qu'avoir essayé de sprinter mais mais être un peu arrivé sur la ligne enfin arriver à un endroit que certains considèrent être la ligne d'arrivée mais qui ne l'est pas vraiment Donc être endurant, pas d'être un sprinter. Oui, j'ai une des slides où j'ai écrit c'est un marathon, pas un sprint. Et effectivement, je crois que... Ça fait partie un peu de comment on gère l'énergie des équipes et l'énergie des individus. Merci. Yann, tu mentionnes la notion de dette organisationnelle.

18:15 Pour moi, c'est assez différent. On peut en parler. Je ne sais pas, est-ce que tu veux intervenir? Oui, je veux bien. Ce que j'entends par dette organisationnelle, c'est que j'ai vu beaucoup de fois les processus de l'entreprise être impactés par la manière de faire de la technique. Bon, là, on rentre dans tout ce qui était loi de Conway, etc. Là-dessus. Et donc, le coût de la dette organisationnelle sur les silos, sur la manière de communiquer entre les équipes, etc., impacte la manière dont on va designer le produit, impacte et va créer implicitement de la dette technique aussi, là-dessus. Oui. Alors là, je vais essayer de trouver mes slides parce que du coup, peut-être la slide qui se rapproche un peu de ce que tu décris, c'est celle-ci. Alors, je te rejoins tout de suite. Et c'est ça, en gros, il y a un peu ce côté, il faut bien clarifier les problèmes qu'on essaye de résoudre.

19:21 Et effectivement, il y a un moment où… une organisation était peut-être la bonne pour développer un certain produit ou pour accélérer sur certaines... dimension. Si les enjeux changent ou si la taille de l'organisation change, ce qui marchait peut-être bien et ce qui était peut-être adapté ne l'est plus forcément. Et c'est vrai que vouloir garder à la fois l'organisation, les process en se disant que ça marchait bien jusque-là, ça peut ralentir et créer effectivement un certain nombre de problèmes. Et tu mentionnes effectivement le côté loi de Conway. On se retrouve à designer les systèmes en fonction de l'organisation plutôt qu'en fonction de quel problème qu'on essaye de résoudre. Là, pour moi, il y a un vrai sujet et ce n'est pas facile parce qu'il y a clairement ce côté, surtout pour des boîtes en croissance rapide, il y aura en permanence des choses qui vont se mettre un peu à dysfonctionner, parfois de manière assez à bas bruit, parfois de manière un peu explosive suivant les cas.

20:29 Mais c'est sûr qu'en fait, une équipe qui scale, elle va être en permanence en train d'ajuster des choses, parfois incrémentales, parfois ce sera intéressant de faire un step back et de se dire attendez en fait là étant donné les enjeux qu'on va avoir pour les deux prochaines années ou pour les 12-18 prochains mois, c'est intéressant qu'on se réorganise et qu'ensuite on recolle les morceaux de« bon, en fait, le système actuel, ce n'est pas forcément le bon pour cette nouvelle organisation, mais ce n'est pas grave, on va adapter les deux, on va prendre le temps de se réorganiser pour atteindre ses objectifs business. Je pense là, j'ai mis en gras un peu le côté organisation proche. Je crois qu'il y a aussi un risque de, ah tiens, on est cinq et on veut s'inspirer de ce que Google a mis en place. Et en fait, non, Google a mis en place des choses parce qu'ils sont plusieurs centaines de milliers. Et je crois que c'est important de mettre dans le...

21:30 de s'inspirer de ce que d'autres organisations ont fait, mais de mettre dans le contexte, eux, quels étaient leurs problèmes et à quel point est-ce que c'était similaire ou pas à ceux que vous, vous êtes peut-être en train de... Ceux auxquels vous êtes confrontés et comment est-ce que vous voulez essayer de les résoudre. Dans tous les cas je trouve que c'est toujours hyper intéressant et ça c'est plus et on va en parler un peu après de quelle est la culture de l'organisation et se mettre dans un mindset et créer une culture où en fait l'organisation est apprenante et ça veut dire que quand il y a quelque chose qui ne s'est pas bien passé, on va en parler on va prendre le temps de faire une rétrospective un post-mortem, je ne sais pas comment vous vous appelez finalement ça a assez peu de la terminologie et importe moins que le fait de créer ces moments d'apprentissage ensemble et de pouvoir entendre le feedback, feedback positif, mais aussi parfois feedback négatif de« Ah tiens, ça, ça n'a vraiment pas bien marché.

22:32 » Qu'est-ce qu'on fait pour que ça ne se reproduise pas? Et c'est important dans ces cas-là que l'apprentissage ne soit pas… Et de la même manière, quand on fait un post-mortem sur un incident de prod, les action items, ça ne peut pas être« Ah, on fera plus attention la prochaine fois. » Il faut que ce soit« Ah tiens, comment est-ce qu'on change le système? » système et l'architecture, ça peut être l'architecture, ça peut être le système au sens large, ça peut être l'organisation, ça peut être... Mais tous ces aspects-là, comment est-ce qu'on change le système pour que les différentes causes qui se sont agrégées et qui ont contribué à cet incident n'arrivent plus? Je fais une petite pause, je vous laisse. Peut-être je reviens, Romain, est-ce que je vois ton commentaire là, un peu comment on fait valoir cette valeur technique versus le vite fait, mais le business est content.

23:34 Est-ce que ce que j'ai déjà partagé, ça aide? Est-ce que tu veux qu'on creuse? Non, ça aide. Après, nous, c'est vrai qu'on a pas mal ces sujets-là ici parce que finalement, on a eu un peu des fois cette bataille, comme tu disais, entre la prior business et le côté, tu as des devs qui récupèrent une énorme dette sur la partie paiement typiquement et on nous dit qu'il faut mettre des nouveaux moyens de paiement. Oui, mais si on met des nouveaux moyens de paiement, c'est plus long. Et alors que si on refacto, entre guillemets, ce sera moins long pour après. C'est vrai que nous, pour l'instant, ce qu'on a réussi à faire, qui est pas mal, comme tu disais, on a un PM et moi et mes team leads de l'équipe de dev qui sont des bons binômes et qui partagent finalement beaucoup maintenant le business. En fait, tout est business. On partage vachement les KPI et la North Star sur les équipes de paiement. Ça va être la conversion finalement. On partage ça aux équipes à la fin de tous les sprints et on drive un peu avec ça.

24:35 Et nous, on leur fait comprendre que tant que le tunnel de paiement sera endetté, on va apporter de la valeur, mais plus lentement. Typiquement, on met du 3-4 fois en ce moment, c'est long à faire parce que finalement, le code est assez endetté. C'est clair pour eux, ils veulent quand même qu'on le mette 3-4 fois. Typiquement, avant le Black Friday, très vite, on l'a fait. On est en train de le méper ce matin. C'est la merde, on a des problèmes aussi. Mais c'est comme ça qu'on a voulu faire. Et au moins, tout le monde sait que si on le fait, si derrière, on refacto, demain, quand on mettra, je ne sais pas, Amazon Pay ou n'importe quoi qu'on n'a pas aujourd'hui, ça mettra moins de temps. Mais c'est vrai que c'est ça qu'on partage et qu'on essaie de faire, c'est de montrer déjà qu'à la tête des équipes, ça s'entend bien, entre guillemets, ou du moins on partage les tenants aboutissants, on va faire quick and dirty, ou alors on va permettre d'apporter de la valeur plus vite pour plus tard en refactorant typiquement. Forcément tout le monde n'est jamais content, les devs c'est les premiers des fois à vouloir cliner un petit peu leur code parce que c'est les premiers, c'est toujours pareil, quand la chambre est en bordel on n'a pas envie de se coucher en fait, donc ils ont tout le temps envie de bien ranger les choses, donc on essaie de leur partager un peu ça.

25:47 Et c'est peut-être ça le plus dur en fait, c'est de faire arriver cette information jusqu'aux feuilles de l'arbre pour que tout le monde soit embarqué et que tout le monde comprenne que c'est ça les objectifs. Oui, mais dans ce que tu décris, j'entends un certain nombre de points positifs. Et effectivement, c'est toujours un peu work in progress. Il n'y a pas de réponse absolue. Mais peut-être dans ce que tu disais aussi, je crois que, et parmi des choses qui sont plus intangibles et donc pas évidentes à communiquer, mais pour moi, quand on se retrouve, quand on arrive dans des zones où en fait, il y a régulièrement des bugs, il y a régulièrement des incidents de prod, je crois que c'est un thème. intéressant de faire toucher du doigt le côté, ah tiens, en fait, ça crée du contexte switching pour tous les ingés. Et ce contexte switching-là, en fait, il a un vrai coup de, ah tiens, la personne était en train de bosser sur la prochaine feature. D'un coup, en fait, elle doit basculer parce qu'il y a un incident de prod.

26:51 L'incident de prod, il met une heure à être résolu. En fait, la vraie perte de productivité pour l'ingé, c'est probablement sa demi-journée, en fait, parce que le temps qu'après, il revienne, il se replonge dans la feature, etc. Et ça aussi, pour moi, ça fait partie un peu des coûts un peu cachés où ça aide de les verbaliser et d'aider le reste de l'organisation à les toucher du doigt. Je me permets d'intervenir là-dessus. Ce qui a marché, nous, en interne, sur la dernière année, c'est qu'on s'est vachement inspiré de Conto. C'est-à-dire qu'on a essayé de travailler la cohérence et la culture de la qualité. On s'est dit, à force de faire au pitch ou à la demande du qualitatif, du PA qualitatif, du refacto, du pas du refacto, etc. En fait, on perd les équipes et puis on perd nos interlocuteurs. Et ils en viennent carrément à challenger, du pourquoi là vous faites de la qualité, c'est important, alors que là, deux semaines avant, vous avez fait un truc quick and dirty, j'arrive pas à comprendre.

27:52 Et les zones d'incompréhension comme ça, ça crée de la friction, typiquement quand on commence à vouloir monter le niveau. Ça, on l'a fait. pendant trois ans. Et en 2023, on a pris ce que c'est un peu conto, et on s'est dit, bon, on va essayer de créer une culture dans l'ingénierie. On s'est dit, on va dire, non, dans la structure, c'est ce niveau la qualité, et c'est tout le temps. Ça fait partie de la culture. On n'imagine pas faire sans. Et bien entendu, au début, ça ralentit, on est challengé sur le niveau, mais ça force à parler un peu business, et comme tu disais, contribution de la qualité, et un coup sur le business. Mais après, ça apporte de la cohérence, et le sujet, il ne vient plus sur la table. C'est-à-dire que c'est tout le temps à ce niveau-là, et ça n'est pas négociable parce que c'est culturel. Il faut réussir à faire passer ça, en tout cas, un des axes, c'est de réussir à faire passer ça dans la culture, plutôt que dans le contexte. Oui, c'est ça. Et que ce n'est pas une décision à chaque fois très contextuelle, très conjoncturelle, mais ça fait partie de la culture.

28:57 Mais ça, en fait, encore une fois, et je vois dans certains des exemples, ah tiens, parfois, il y aura des deadlines très fortes. Clément, tu mentionnes le côté, ah tiens, des commissionnements d'un contrat. Là je ne sais plus qui mentionnait Black Friday, en fait, ça aussi, c'est une réalité du business et c'est important que les équipes engineering, ils ne soient pas, enfin, soit, soit, et de l'empathie pour ça, parce que c'est juste une réalité de la société. Et donc, il y aura des fois où il faudra couper des coins, il y aura des fois où il faudra... faire un sprint, je crois là où on peut perdre un peu les équipes ou perdre de la crédibilité, c'est quand ces chocs externes ou ces contraintes externes, on commence à faire des promesses qui ne sont pas tenues. De« Ah ben tiens, oui, il y a une deadline très forte sur Black Friday, mais en fait, on prendra le temps après de cleaner et de terminer.

29:58 » Et qu'en fait, ça ne se fait pas parce que juste après, Après Black Friday, maintenant, il y a Noël. Donc, en fait, il faut continuer à sprinter. Et on se retrouve à enchaîner des sprints et à un peu accumuler les couches d'aide technique ou d'aide fonctionnelle, comme on veut l'appeler. Et où il n'y a pas cette confiance qui se crée non plus. Et où du coup, les équipes engineering, à un moment, disent, visiblement, on n'entend pas les enjeux que nous, on essaye de mettre sur la table. Donc, en fait, on va freiner. Soit on va les mettre, on va faire du travail un peu dans le noir et on va réserver une partie de notre bande passante pour ces sujets-là parce que si on commence à les discuter, on nous le vole à chaque fois. Mais je trouve que ce n'est pas un très bon… Évidemment, c'est une solution, mais je trouve que ce n'est pas une très bonne solution parce qu'en fait, on a coupé la communication entre les différentes parties de l'organisation et du coup, chacun se retrouve un peu à optimiser avec un contexte très partiel et je crois qu'à terme, ça donne

31:01 le feedback que j'ai entendu souvent de gens hors de l'équipe engineering qui disent, en fait, l'équipe engineering, c'est une boîte noire, je ne comprends pas ce sur quoi ils bossent et oui, il y a des trucs qui rentrent, il y a des trucs qui sortent. Est-ce que ça va assez vite? Je ne sais pas. Est-ce que ça pourrait aller plus vite? Je ne sais pas. En fait, je ne comprends pas comment ils travaillent et je trouve que c'est dommage d'en arriver là. Donc pour moi, c'est plus comment on crée la visibilité, la transparence et le bon niveau de confiance pour… pour avoir ces discussions-là en commun, collectivement. Peut-être sur ces sujets un peu de structure, organisation des équipes, J'avais une dernière slide que je vais passer, puis après, on pourra peut-être passer à d'autres sujets. J'ai parlé un peu du côté 1PM, une équipe engineering, et je pense que c'est important que là-dedans, vous ayez un mapping de tout. Tout ce qui est dans le produit ou dans le scope de l'équipe engineering et que ce soit mutually exclusive, collectively exhaustive.

32:08 C'est-à-dire à chaque partie de la stack, il devrait y avoir une équipe qui est associée et pas plusieurs, mais pas non plus zéro. Et ça, ça arrive parfois quand les équipes se réorganisent très rapidement, mais parfois il y a des bouts de la stack où en fait personne n'est responsable de ça. Et je crois qu'une fois que vous avez ce pavage finalement avec à chaque fois une partie du produit et en face une équipe qui en est responsable que conjointement, product et engineering puissent avoir un ownership sur le long terme en fait. Et c'est ensuite ensemble qu'ils vont pouvoir avoir la discussion de, ah tiens, on a besoin d'investir pour peut-être faire un refacto ou retravailler les fondations de telle partie du produit. Voilà comment on propose de le faire. Ah tiens, on a... ces enjeux business-là sur cette partie du produit, voilà comment on veut les adresser et un peu développer et pas juste sur un sprint ou sur un quarter, mais une vision un peu plus long terme de voilà comment petit à petit on va améliorer les choses, voilà comment on va continuer à apprendre d'un point de vue business et product, mais aussi voilà comment on veut

33:21 peut-être mettre à niveau la stack technique, mettre à jour les dépendances, améliorer la qualité, déployer des tests automatiques pour améliorer la vélocité de l'équipe et la rélabilité, etc. Mais avoir un peu cet ownership commun et cette vision commune sur les périmètres bien identifiés. Et idéalement, entre deux scopes ou entre deux équipes, il y a une interface qui est bien définie et qui va permettre à chaque équipe d'être relativement autonome sur son périmètre. Je m'arrête là, peut-être s'il y a des réactions ou des questions là-dessus. Et après, on peut passer à d'autres sujets. Je vois que l'heure tourne vite. Pas de réaction. Qu'est-ce que vous préférez faire? Moi, j'avais peut-être pour vous montrer un peu les sujets dont je... Bon, perdre un collaborateur essentiel, un collaborateur toxique. Ça, on a parlé structurisation d'équipe.

34:21 Après, sinon, résilience individuelle. Je vous laisse choisir, peut-être, si vous voulez rapidement me dire qu'est-ce qui vous intéresse. On peut, ravi de... Choose your own adventure. Oui, succession planning. Ok. Boris, tu veux tout? Non, visiblement, il y a une petite majorité qui se dégage sur la résidence individuelle. En fait, pour moi, il y a une vraie tension, et je pense que c'est particulièrement vrai sur les métiers de l'engineering, sur... Souvent vous êtes arrivé là où vous êtes parce que vous étiez des bons ingénieurs parce que vous aviez un impact positif

35:30 sur le produit sur l'architecture etc mais du coup c'est pas forcément facile de prendre de la hauteur et d'avoir notamment d'être un bon sparring partner pour ça peut être vos co-founders ça peut être pour le reste de l'équipe dirigeante ça peut être pour votre alter ego côté product et il y a un peu un côté si vous êtes je crois que j'ai une ouais je crois que j'ai et ça ça s'applique peut-être enfin là c'est des exemples qui sont un peu plus orientés sitio mais honnêtement je crois que à partir du moment où vous êtes vous avez une équipe sous vos sous votre responsabilité vous allez avoir cette tension entre des sujets assez macro de comment je comprends et comment j'aide à définir ou comment j'influence la stratégie long terme de l'entreprise, comment je recrute. Quand vous recrutez, en fait, souvent, c'est quelque chose qui va avoir un impact dans 3 à 6 mois, on va dire, versus des sujets très micro. Tiens, en fait, vous êtes celui qui connaît le mieux la prod, il y a un incident de prod, vous allez aller aider.

36:39 Vous avez pris un ticket Jira ou une épique parce que vous avez envie de bosser sur le produit. Et en fait, ce n'est pas facile de faire l'ascenseur entre ces sujets micro et ces sujets macro. Et pareil, là, il y a juste un coût de context switching qui est assez important et dont il faut être conscient. Je pense aussi qu'il y a un biais, encore une fois, il y a un biais chez les ingénieurs de, en fait, les sujets micro et aller coder, aller fixer un incident de prod. Probablement la plupart d'entre vous, vous aimez bien le faire. Et encore une fois, c'est ça qui, jusqu'à présent, vous a apporté de l'énergie. Et il y a un vrai enjeu à lever la tête du guidon et être capable d'aller sur des sujets macro. Et encore une fois, il y a une... Ce n'est pas facile d'avoir la souplesse pour être capable de faire, certainement pas les deux à la fois, mais même pour passer de l'un à l'autre dans la même journée, en fait, ce n'est pas évident. Et donc, il y a un peu un côté de qu'est-ce que vous pouvez déléguer, qu'est-ce que vous ne pouvez pas déléguer.

37:43 Et être un peu, en fait, avoir cette… faire ce step back là et se dire, tiens, je reviens là, c'est quoi les sujets sur lesquels je vais passer du temps? Comment est-ce que je gère un peu mon niveau d'énergie? Parce qu'encore une fois, si… coder ça vous apporte de l'énergie, en fait, ce n'est pas absurde de vous dire, tiens, je vais quand même bloquer un peu de temps dans mon emploi du temps pour faire ça de temps en temps. Mais en fait, il faut être conscient que vous arrivez probablement à un moment où ce n'est pas là-dessus qu'on vous attend. Et donc, c'est plus le sujet de où est-ce que je passe du temps et où est-ce qu'on m'attend, qu'est-ce qui m'apporte de l'énergie, où est-ce que j'apporte de la valeur ajoutée, où est-ce que j'en ai moins, qu'est-ce que je peux déléguer, qu'est-ce que je ne peux pas déléguer. La réalité aussi, c'est que, et c'est ce que je mets là, c'est plutôt un bon signe quand vous arrivez à vous libérer du temps parce qu'il y aura en permanence des chocs un peu externes qui peuvent être des chocs business de« Ah tiens, il faut peut-être influencer la stratégie.

38:46 » Ça peut être« Ah tiens, on va faire une nouvelle levée et il y a besoin que vous alliez aider pour discuter avec les investisseurs ou pour construire un deck. » Ça peut être« Ah tiens, on discute M&A, qu'est-ce que ça voudrait dire? Il faut faire une due diligence, etc. » En fait, il y aura en permanence des choses un peu externes. Que seul vous pouvez faire, vous n'allez pas déléguer ce genre de choses, vous ne pouvez pas souvent déléguer. Et donc, être capable d'avoir ce temps, un peu de temps libre, un peu d'énergie restante, un peu de… En fait, c'est ça qui va vous permettre d'être disponible dans ces moments-là. Peut-être qu'il peut se passer des périodes de temps assez longues dans lesquelles il n'y a pas ces chocs externes. Et dans ce cas-là, vous allez vous trouver un nouveau rythme. Et ça peut être parfois, oui, je vais continuer à coder. Ça peut être, je vais continuer à passer du temps sur ce sujet qui est peut-être un sujet un peu micro. Tant que vous avez un peu le self-awareness, la conscience de, en fait,

39:49 c'est pas là dessus que enfin peut-être que demain je vais être rappelé à un truc plus urgent ou plus structurel ou plus long terme et faudra que je je je Je pose ça. Mais ouais, en tout cas, il y a vraiment cet enjeu de créer une organisation et vous entourer de gens avec qui finalement, à qui vous allez pouvoir déléguer de manière, je dirais, à vous enlever une partie de cette charge mentale-là. Et ça ne veut pas dire que vous n'en avez plus rien à faire et que vous n'intervenez plus, mais c'est, ah tiens, peut-être que demain, je vais être pris pendant trois semaines d'affilée sur un truc où je vais être la tête dans le guidon. Qu'est-ce qui se passe à ce moment-là et est-ce que mon organisation, elle continue de fonctionner ou pas? Georges, tu posais la question du succession planning. Je trouve que ce n'est pas facile à faire. En tout cas, ce n'est pas facile à faire dans une organisation qui évolue rapidement, une boîte qui scale. Souvent, ça se fait un peu plus tard, à un moment où la structure de l'organisation se…

40:57 ça fermit un petit peu et commence à émerger et où il y a une vision assez long terme et où du coup, en fait, il n'y a pas forcément de changement tous les 6 ou 12 mois, de changement d'échelle ou de changement organisationnel. Après, moi, quelque chose que j'ai beaucoup fait et que je vous conseille de faire, en fait, c'est développer la mobilité interne dans vos équipes et aider les ingénieurs qui souvent considèrent que leur valeur ajoutée, elle est sur un framework particulier ou sur une partie de la stack particulière, aider. les aider à voir qu'en fait, non, leur valeur, elle vient d'un mindset d'ingénieur, d'une capacité à apprendre et qu'en bougeant d'une équipe à l'autre ou d'une partie de la stack à une autre partie de la stack, ils amènent un contexte qui peut être un contexte business, un contexte où ils connaissent le produit, ça peut être qu'ils connaissent le contexte de l'autre équipe. Et en fait, ils vont amener ce contexte-là dans un nouveau métier. Oui, ils vont devoir se reformer sur une partie de la stack ou sur une autre partie du produit, mais finalement, cette partie-là, c'est la partie qui est la plus facile à apprendre et ça peut les aider à ouvrir un peu des horizons.

42:10 En échange, ils viennent avec une connaissance de l'entreprise, un réseau en interne et des connaissances. Et exactement, à la fin, ça apporte beaucoup de résilience parce qu'il y a des gens qui ont vu des perspectives différentes et ont été capables d'amener une culture commune et d'amener, de participer un peu, développer la... Une vision commune et du coup, un partage de la connaissance. Je crois que j'avais une slide sur laquelle je ne suis pas encore passé. Je vais essayer de la retrouver. Oui, mais là, peut-être Gilles, pour rebondir sur ce que tu disais, c'est en fait, à la fin, le but, c'est aussi que personne, ne soit irremplaçable, mais même pas vous, en fait. Et je trouve que c'est intéressant de passer par l'écrit pour ça. Toutes les conversations qui auront lieu autour de la machine à café, en fait, elles n'auront pas été capturées.

43:15 Une des choses faciles à faire, enfin, deux choses faciles à faire et que moi, je vous conseille de faire, c'est, préférez la communication dans les channels publics, sur Slack ou sur l'outil que vous utilisez. Mais souvent, naturellement, les gens ont plutôt tendance à pinger les gens individuellement ou les équipes, elles ont tendance à se créer un channel privé. En fait, je crois que c'est hyper intéressant que autant que possible, les équipes et les discussions aient lieu en public. Évidemment, quand c'est possible et il y a des sujets people ou des sujets très stratégiques où ça ne pourra pas être le cas, mais honnêtement, dans une équipe engineering, je crois que 99% des discussions et notamment toutes les discussions techniques, elles devraient, elles peuvent avoir lieu en public et ça permet de laisser une trace. Et même les décisions les plus importantes, avoir un petit, donc ADR, c'est Architecture Decision Record, mais même Decision Record, c'est la partie importante. Les grandes décisions qui sont prises, je trouve que c'est intéressant de les mettre par écrit.

44:21 Et ça n'a pas besoin d'être des documents de 10 pages. Ça peut être, voilà la question qu'on s'est posée, voilà les alternatives, les différentes options qu'on a explorées. Voilà les critères qu'on a identifiés et voilà pourquoi, sur la base de ça, quelle est la décision qu'on a prise. Et juste avoir ça et l'avoir à un endroit qui peut être un Notion, qui peut être un Confluence, qui peut être un répertoire avec des Google Docs, en fait, à la limite, le format, on s'en fout un peu, ça permet de laisser une trace et que si un an après, peut-être avec des gens qui ont pris la décision mais qui ne sont plus là, on se repose la question de se dire, ah tiens, on avait identifié ce problème. et voilà comment on y réfléchissait à l'époque, où ça peut être, ah tiens, en fait, il nous manquait une partie des éléments, il y a des nouveaux éléments qui n'ont pas été pris en compte, et donc peut-être qu'il faut réouvrir cette décision-là et en rediscuter. Et clairement, Clément, tu le mentionnes, le remote n'aide pas, mais c'est pour ça que je trouve passer par de l'écrit et de l'écrit qui est accessible à tout le monde, ça aide.

45:29 Et c'est aussi, et c'est peut-être, je vais m'arrêter là-dessus, après on prendra les 10 minutes restantes pour peut-être des questions-réponses. Je trouve que c'est aussi, si vous arrivez à le structurer et petit à petit à collecter cette information-là, je trouve que c'est intéressant parce que c'est des choses que vous allez demain pouvoir mettre dans des LLM et peut-être aller ensuite interroger le, ah ben tiens, j'ai ces deux années de décision ou d'historique Slack, dis-moi comment on a parlé de tel sujet ou retrouve-moi les moments où on a parlé de telle problématique. Encore une fois, ce que vous ne pourrez pas faire, tout s'est fait à l'oral. Je m'arrête là. J'ai l'impression d'avoir sprinté et de ne pas avoir fait un marathon. Mais peut-être que je vous laisse poser des questions. Approche Chaos Monkey au niveau organisationnel pour tester la résilience de mon équipe. Peut-être, Gilles, ça m'intéresse.

46:30 Qu'est-ce que tu ferais? L'idée, c'est pour l'instant, comme tu disais, on est une petite équipe. Donc, il y a quand même malgré tout des actions qui ne sont portées que par certains individus. Ce serait de tester, de dire de façon un peu aléatoire, cette semaine, cet individu n'a plus le droit de faire ces actions-là. Je n'en sais rien, ça peut être des processus à exécuter, des choses comme ça, et de vérifier que le reste de l'équipe est capable de prendre cette charge à sa place. Donc, je sais que ça a bien été documenté et que globalement, même si je sais que ce ne sera pas performant, qu'on va perdre du temps, ça reste quand même un moyen de vérifier que la résilience est quand même là, d'un point de vue organisationnel. Alors, là où je te rejoins complètement, c'est que forcer tout le monde à prendre des vacances et à être complètement déconnecté, c'est un bon moyen de vérifier que justement personne n'est irremplaçable. Et je trouve chaque fois qu'il y a un peu un inconfort en disant« Waouh, cette personne-là, elle part en congé maternité, elle part en congé paternité pendant X semaines ou X mois, waouh, on ne va pas y arriver.

47:33 » Je trouve que c'est des signaux intéressants de« Attendez, qu'est-ce qu'on fait pour être dans une situation où, et même de manière plus simple, de deux semaines en vacances, comment est-ce qu'on fait pour qu'on ne soit pas tous en apnée à un peu retenir notre respiration, attendre que la personne revienne? » Et effectivement, Il faut que… Et je l'ai à un endroit… Mais est-ce que tu penses que ça peut être quelque chose qui peut être fait de façon automatique? Parce que là, tu dis que ça dépend des périodes de congés, etc. Moi, je vous rappelle qu'ils ne sont pas capables de tester de façon continue. Moi, je ne sais pas si… Alors, moi, ce que je disais, c'est en fait, naturellement, ça devrait être testé au moins une fois par an parce que les gens devraient partir en congé et pas juste prendre une journée partie, une journée par là. Et je pense, et ça aide, ça force ce test-là. Toi, ta question, c'est est-ce que tu, de manière peut-être un peu arbitraire ou automatique, dire, attendez, en fait, là, on va se forcer. Moi, cette conversation-là, je l'amènerai et je la ferai, je mettrai chacune des équipes en responsabilité de ça.

48:42 Et dire, attendez, vous êtes responsable en tant qu'équipe de vous assurer qu'aucun des collaborateurs ne détient une expertise unique ou devient irremplaçable. Mais après, est-ce que, je ne sais pas si je le ferai de manière, je dirais, automatique et systématique pour toutes les équipes, parce que chaque équipe a des enjeux un peu différents. Il y a des vrais enjeux de prod, il y a des équipes où c'est plus une connaissance de l'architecture, il y a des équipes où c'est plus, ah tiens, telle partie du code, en fait, etc. Je crois que dans tous les cas, faire l'exercice mental de« Ah tiens, telle personne, elle ne va pas être là pendant deux mois. » C'est quoi les choses qui se… C'est quoi les inconforts et c'est quoi les choses où on se dit, waouh, ça va être douloureux ? Et se dire, tiens, en fait, ces trucs-là, on va bosser dessus. On va passer du temps, on va documenter, on va automatiser des choses, etc. Mais ce n'est pas OK. On veut bosser là-dessus.

49:43 Et effectivement, le tourner en disant, en fait, on va travailler notre résilience, on va travailler notre capacité à, en commun, parce que collectivement, on est responsable de cette partie du scope, il faut qu'on soit capable de survivre, même si quelqu'un demain a un accident ou demain disparaît. Pour une raison X ou Y. Je prends les questions, je vais peut-être les prendre dans l'ordre. Collaborateur toxique. Là, on revient un peu à la question de la culture. C'est en fait, vous êtes, en tant que manager, vous êtes responsable du mindset et de la culture de votre équipe ou de votre organisation. Et ça commence par vous êtes un exemple. Normalement, vous devez être un bon exemple, mais parfois, en fait, on peut se retrouver à être un mauvais exemple. Et donc, c'est important de se rappeler qu'en tant que manager, en tant que leader, on est un exemple en permanence. Et les gens vont regarder comment vous prenez les décisions, comment vous réagissez.

50:45 Et c'est une des manières que vous avez, peut-être dont vous ne vous rendez pas compte, mais de changer la culture. La deuxième manière, c'est les recrutements. Et clairement, vous avez un rôle important lors des recrutements pour amener le bon type de mindset. Mais du coup, aux collaborateurs toxiques, pour moi, il faut le... l'attaquer, je dirais, de manière assez directe avec la personne en lui donnant le feedback et en lui donnant une chance de réagir. Mais si après, la personne ne réagit pas ou continue à être toxique, je crois qu'en fait, il faut avoir très rapidement la conversation de ça ne fonctionne pas. Et souvent, les gens ne sont pas heureux dans des rôles où ils deviennent toxiques. En fait, ça peut être des gens qui sont attachés à l'entreprise, mais qui ne sont pas contents et un peu... peu rumine ça et je pense que c'est important d'avoir la discussion et de dire, en fait, on a déjà eu la conversation il y a un mois, ton comportement n'a pas changé et il impacte le reste de l'équipe. En fait, il faut qu'on sorte de ça.

51:49 Faisal, tu mentionnes comment faire quand la roadmap business change H24. Pas facile. Là, il n'y a pas de recette magique parce que la réalité de ce qu'une équipe engineering construit, c'est que ça s'inscrit forcément dans un temps qui est un peu long. Et si effectivement, il y a des grands coups de volant côté business ou côté product, en fait, il y a une tension qui va se créer parce que côté business, on peut décider plusieurs fois par jour de changer la direction, mais la réalité, c'est que côté engineering, à côté de… Enfin, si on compare, le paquebot, ce n'est pas une image très positive. La réalité, c'est que ça demande du temps d'implémenter ce changement-là. Donc, je crois qu'il y a une discussion à avoir avec le business de dire, en fait, là, vous donnez des grands coups de barre à gauche, à droite, mais en fait, derrière, il y a une machine qui se met en route qui… au mieux en fait va être un peu insensible à ces coups là parce que vous ajustez à 45 degrés autour d'une direction long terme et peut-être du coup parlons plutôt de la direction long terme si vraiment vous êtes en train de faire des allers retours entre deux trucs opposés bah la réalité c'est qu'on nous on va être

53:00 un peu à l'arrêt et on ne va pas avancer parce qu'un sens on va à gauche, un sens on va à droite. Au final, on va faire du sur place si ça change tout le temps. Si je peux réagir en 10 secondes, effectivement, nous, on a un peu ce souci. C'est la première fois que je travaille en grande boîte. C'est quoi le nombre peut-être, juste pour donner les ordres de grandeur? 800, entre 600 et 800 personnes. Mais la majorité, ils sont dans le service. Et nous, ils ont racheté trois startups, ils ont émergé et on a créé un département un peu produit. Ça se gère en haut en ce qui concerne la roadmap, ce n'est pas clair. Et en plus, comme c'est un sujet assez pointu dans la santé, on ne peut pas trop la trouver nous-mêmes. Je viens de récupérer le produit parce que je ne comprenais pas pourquoi certaines décisions ne faisaient pas trop de sens dans le produit. Mais en fait, je comprends maintenant que... Ça va bien au-delà de ça et c'est le contexte business qui n'arrive jamais chez les ingénieurs, mais en fait, même chez les produits, il n'est pas clair.

54:07 Ma nouvelle stratégie, c'est de dire, on va développer, quand ils nous cassent les pieds avec des features et tout, on développe les MVP les plus petits possibles. Et ça, je traîne le produit là-dessus. Pour qu'on délivre le plus de business, mais vraiment en faisant le moins possible. Et le seul point sur lequel nous, on travaille vraiment et on est responsable dans l'équipe, c'est d'améliorer le produit actuel. en allant voir les utilisateurs et voir ce qui se passe, en étant sur Mixpanel et en améliorant notre point à nous. C'est ça un peu ma réaction que je dis à mes équipes. Parce que ça fait deux ans et demi que la stratégie, c'est comme ça. Je ne sais pas quoi faire pour la faire changer. Je ne pense pas que ce soit dans mes mains, en fait. Oui, j'allais le dire. Il y a parfois... En fait, l'équipe engineering, elle est au bout de la chaîne de production. Et donc, souvent, on observe ce qui sort de l'équipe engineering en disant« Ah, mais c'est…» ou ce n'est pas le bon niveau de qualité, mais ce n'est pas ça en fait dont on a besoin. Mais effectivement, le diagnostic, il doit, et souvent parmi les causes,

55:13 l'équipe engineering en maîtrise un petit nombre, mais il y en a un certain nombre qui en fait sont plus en amont sur stratégie business, contexte business, stratégie produit, etc. Et ce n'est pas toujours facile. Et effectivement, au mieux dans ces cas-là, en tant que VP engineering, en tant que personne en engineering, on peut aider les gens à prendre conscience. J'aime bien ce que tu écris, Boris, sur un peu le côté visibiliser un peu ces changements de prio et être capable de dire aux gens, mais attendez, regardez, il y a trois mois, vous nous disiez que ça, c'était le truc le plus important de la Terre. Et là, aujourd'hui, en fait, ce truc-là, vous n'en parlez même plus ou bien vous nous dites, non, non, en fait, c'est un P2 par rapport à tel nouveau truc. Et ça fait deux ans que ça dure. Je trouve que ça aide effectivement. Et ça n'a pas besoin d'être agressif en mode, vous ne faites pas votre table, mais juste en mode, regardez, en fait, il y a une réalité de, on change régulièrement de prio et nous, côté engineering, en fait, on va avoir du mal à être vraiment efficace dans ce contexte-là.

56:20 Et tu as raison, après, que tu as des stratégies d'adaptation qui est celle que tu décris, de dire, en fait, je sais que les prios vont changer, donc non, je ne vais pas faire des gros investissements parce que probablement dans trois mois, on sera en train d'explorer une direction un peu différente. Et je pense que c'est une bonne stratégie, mais effectivement, c'est une stratégie d'adaptation. Et idéalement, tu as envie petit à petit d'influencer le reste de l'organisation, mais ce n'est pas forcément dans tes cordes ou tu n'as pas forcément aujourd'hui l'oreille pour avoir ça. Je vois qu'on arrive au bout des 13 heures. Nazim, je n'ai pas pu adresser ta... Je pense qu'on peut prendre peut-être la dernière question de Nazim. Oui. Si ceux qui doivent partir peuvent partir. Mais si ça te va, après, ça se dépend si Olivier a un hard stop. Non, je n'ai pas de hard stop. On peut prendre quelques minutes de plus. Nazim, ouais, alors, en fait, c'est marrant parce que tu dis que ta question rejoint celle d'Antoine sur le collaborateur toxique, mais c'est vrai que parfois, il y a des collaborateurs qui deviennent toxiques parce que

57:23 l'organisation évolue, ça peut être la stratégie business évolue, ça peut être, ah tiens, la taille de l'organisation évolue, ils étaient arrivés dans une équipe de 10, ils étaient hyper heureux, aujourd'hui, on est 50 et il y a un côté un peu, c'était mieux avant et en fait, articuler le, en fait, ouais, on est dans une organisation qui change, qui a changé, qui va continuer à changer, et clarifier avec les personnes, en fait, on attend de vous que vous ayez, que vous soyez au clair avec vous-même de, voilà la direction dans laquelle on veut aller, on va vous l'expliciter, et on ne va pas, on traite tout le monde comme des adultes, mais voilà la direction dans laquelle on veut aller, voilà ce que ça veut dire pour votre métier, votre équipe. C'est OK de ne pas être d'accord avec cette direction-là, mais il y a un moment où effectivement, et je te rejoins Nazim là-dessus, il y a un moment où si…

58:26 on a fait le constat de voilà la direction à laquelle on veut aller et la personne est fondamentalement pas d'accord avec cette direction là bah oui je crois que la bonne discussion à avoir c'est mais écoute ça sert à enfin il faut qu'on a discussion de comment on t'aide à trouver quelque chose dans un environnement où tu seras plus heureux mais visiblement ce sera pas cette et ça peut être on va te changer d'équipe si si c'est un une problématique vraiment spécifique à une équipe mais souvent ça sera plutôt bah ouais les besoins de l'entreprise ont changé et là aujourd'hui toi tu ne te projettes pas dans ce que l'entreprise est en train de devenir, ça ne sert à rien de s'entêter. Si tu n'as pas envie de changer, en fait, ça ne va pas marcher. Après, il y a un autre enjeu qui est parfois les gens… ont envie de changer mais n'y arrivent pas. Et là, je trouve que souvent, il faut que ce soit une autre discussion. Parfois, les gens ne se rendent pas compte qu'en fait, on leur demande de changer, mais si on leur articule ce besoin-là, ils sont prêts à se mettre en mouvement. Mais je trouve que c'est intéressant de différencier quel est leur niveau de self-awareness par rapport à un peu ce changement-là qui est en train d'arriver et parfois, c'est où est-ce qu'ils en sont un peu dans la courbe de deuil.

59:29 Et parfois, on est surpris de se rendre compte qu'en fait, à aucun moment, on leur a articulé le… on a besoin de changer et voilà pourquoi d'un point de vue business ou d'un point de vue organisationnel, on est en train de changer. Et voilà du coup ce qu'on attend de toi. Est-ce que tu es partant ou pas? Et parfois, cette discussion n'a pas eu lieu. Et pour moi, il faut que ça commence par ça. Après, si la personne a fait ce travail-là de compréhension et se dit, non, en fait, je n'ai pas envie de faire ça, fondamentalement, ça ne m'intéresse pas ou j'ai l'impression que je… je ne vais pas y arriver ou je n'ai pas envie de faire l'effort, là, c'est une autre discussion. Et effectivement, oui, je crois que dans ces cas-là, il faut avoir la discussion de, écoute, tu ne seras pas heureux chez nous. Comment on passe à la suite. Je reprends juste ça. J'ai l'impression qu'il y a quand même aussi un gros timing de temporalité. Parce que ce genre de profils qui sont assez rapidement toxiques, J'ai l'impression qu'il ne faut pas vite s'en sortir, mais ils peuvent faire partir d'autres profils.

1:00:32 C'est dur, je trouve, de prendre des bons choix à ce genre de moment. En fait... Mon expérience, c'est qu'effectivement, en tant que VP Engineering CTO, on a peur de ce côté, ah tiens, on va créer un peu un côté, ah tiens, d'un coup, tout le monde va se mettre à partir. Mon expérience, c'est que, un, ça n'arrive pas. Ça n'arrive pas si on traite les gens comme des adultes et si on est clair sur voilà ce qui a changé, etc. Et qu'à l'inverse, il y a un risque qu'à un moment, en fait, là, je vais relire, mais comme manager, vous êtes en permanence un exemple. Et si à un moment, les gens autour de vous ont l'impression que vous tolérez un comportement qui est toxique, en fait, ça envoie un message aussi très fort à l'organisation de c'est OK d'être agressif, c'est OK d'être désagréable, c'est OK. Et en fait, tu as aussi un effet de contagion dans l'autre sens que je trouve toujours un peu dangereux. Après, il y a un aspect qui est quand même aussi de dire que c'est tous des adultes, oui, mais on est tous des individus qui pensent d'abord à nos intérêts.

1:01:39 Et ça ne peut pas dire que ça va forcément se terminer sans douleur et sans cri, entre guillemets, parce que la personne peut aussi décider de retourner sa veste et juste de mettre la situation encore plus compliquée juste pour tirer la couverture de son côté. Oui, mais c'est là où en fait, Je trouve articuler le... Peut-être que nos intérêts à ce stade de l'histoire divergent. Et peut-être que ce n'était pas le cas il y a deux ans quand tu es arrivé. Et peut-être que tu as apporté plein de choses sur les 18 derniers mois. Mais là, aujourd'hui, visiblement, ce que toi, tu as envie de faire n'est plus aligné avec ce dont l'organisation a besoin, etc. Je crois que ça aide à avoir une discussion un peu plus factuelle et encore une fois, mettre le doigt sur peut-être un peu le problème et avoir cette discussion-là. Après, effectivement, s'il y a quelqu'un à un moment qui devient extrêmement toxique et qui cherche à faire partir tout le monde, etc., il y a un problème fondamental.

1:02:46 Moi, ce que j'ai vu souvent, c'est plus une inquiétude du management de« Ah, mon Dieu, ça pourrait se terminer comme ça», mais qui, en vrai, ne se matérialise pas. Et d'autant moins que, en fait, vous avez travaillé sur, pas que sur les éléments toxiques, mais sur tout le reste de l'équipe. Qui souvent en fait n'est pas dupe de ce qui est en train de se passer, et de ce côté, ah tiens, ben oui, il y a peut-être cette lutte de pouvoir ou cette toxicité qui est en train de se mettre en place, parce que, ah tiens, telle personne, elle est en train de devenir un peu toxique, parce que le contexte... change, etc. Mais qui un peu permet à tout le monde de prendre un peu de recul par rapport à ce qui se passe. Mais encore une fois, moi, je ne laisserai pas cette situation s'installer parce que c'est quand ça s'installe dans la durée que ça devient aussi beaucoup plus difficile à adresser. On a largement dépassé.

1:03:48 On a pris 7 minutes de plus. Non, non, non, mais après, c'est plein de questions encore. Et je pense que ça a pu aider en tout cas tout le monde. En tout cas, merci à toi, Olivier. Super retour. Et je pense qu'on aurait pu en passer encore quelques heures dessus. Merci à tous pour vos questions, feedback, participation. C'est super. On voit que le sujet plaît. On espère que ça peut vous aider encore une fois. On se retrouve d'ici deux semaines pour le Tech.Rocks Summit, qui est le dernier gros événement de l'année. Et d'ici là, on vous souhaite une bonne semaine et une bonne journée. Et encore merci Olivier pour tes précieux conseils. Merci à tous, merci pour vos questions. A très bientôt. Merci. Merci, au revoir. Merci, au revoir.