Meetup Tech.Rocks

Dév Senior avec 6 ans d'expérience, et après ?

Meetup Tech.Rocks · 16 avril 2022 · 57 min · en français

Résumé

Replay du meetup Tech.Rocks du samedi 16 avril 2022 consacré aux perspectives d'évolution d'un développeur senior. Grâce à ses nombreuses compétences techniques et à son ouverture sur le business et le marketing, un développeur full-stack peut exercer des postes variés : CTO, directeur de site, lead dev, directeur produit, head of digital… Mais faut-il manager pour progresser ? Les intervenants répondent notamment à cette question et échangent sur le sujet.

Summary

Replay of the Tech.Rocks meetup of Saturday 16 April 2022 on career paths for senior developers. With their wide range of technical skills and exposure to business and marketing, full-stack developers can take on many roles: CTO, site director, lead developer, product director, head of digital… But do you have to become a manager to progress? The speakers answer this question, among others, and discuss the topic.

Thèmes : Recrutement & carrière

Transcript complet

Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.

Bonjour tout le monde et bienvenue dans ce nouveau Meetup Tech.Rocks. Je vais inviter dans deux secondes les autres intervenants à me rejoindre sur scène et on va surtout se présenter. Je vais vous partager mon écran. Hop là, et on est là. Ok, donc aujourd'hui, moi je m'appelle Valériane Venance, j'ai le privilège de servir la communauté de développeurs au sein de l'entreprise qui s'appelle Twilio, où je suis du coup développeur évangéliste. Aujourd'hui, je suis avec Dimitri Baeli, qui est CPO de Aramis Auto, Hugo Lassiège, cofondeur et CTO de Malt, et Caroline Therwath-Chavier, CEO de Allyance. Excuse-moi Caroline, si j'ai écorché ton prénom, j'ai un peu de mal. Est-ce que vous voyez bien mon écran? J'ai l'impression que tout va bien.

Ok. Alors aujourd'hui, avant que les intervenants se présentent tous ensemble, aujourd'hui on a quelque chose, on a une vraie problématique qui est de dire... Vous voyez bien mon écran ou pas? Est-ce que vous pouvez me confirmer dans le chat? Parce que je n'ai pas le retour. Non, on ne voit pas mon écran. OK. Tac, screen toucher. Non, il ne veut pas. Alors, je vais essayer de le repasser sur mon premier écran. Ce serait dommage que vous manquiez les visuels. Hop. Est-ce que là, vous le voyez ? Ok, bon, ça ne veut absolument pas. Ce que je vais faire, c'est que je vais vous partager du coup le template de la présentation là, tout de suite, dans le chat. Comme ça, vous pourrez suivre avec moi et on se retrouve tout de suite en slide 3 du coup. Alors, je vous le partage avec tout le monde.

Ok. Voilà, c'est bon. Désolée pour ce petit cafouillage, je vous le mets de fait ici. Vous avez du coup la présentation Google Docs directement. Et si vous voulez suivre avec moi, on va se retrouver directement en slide 2.3. Vous allez voir de fait une petite image où on voit un senior, enfin une personne, gravir une montagne. Et enfin, enfin, en haut de la montagne, cette personne devient senior. Et puis en image 3, elle se rend compte que c'était juste un pic et qu'il y a encore pas mal de choses derrière. Parce que la question, plus de progression de carrière, plus de progression salariale, C'est quoi la valeur travail alors si à 31 ans, on est arrivé à la fin? Et puis, c'est quoi les challenges qui vont nous rester à accomplir? Est-ce qu'à 31 ans, on a vraiment fini de se confronter à tous les challenges de notre vie déjà?

Ou est-ce que la seule solution, ça va être de devenir directeur? Du coup, si on part directement au slide 4, c'est ce qu'on appelle le principe de Peter. Le principe de Peter, c'est dire que vous êtes junior, tout va super bien et tout, vous passez senior, voilà, on y est aux 6 ans. Et puis, là, vous êtes toujours dans votre zone de compétence et ce genre de choses. Et puis, en fait, vous allez vouloir monter et vous retrouver directeur. Sauf que là, ce ne sera plus… le même domaine de compétences du tout. Et en fait, tout simplement, vous allez vous retrouver incompétent à un niveau où vous aurez peur, en fait, que les autres se rendent compte. Qu'est-ce que ça veut dire? Vous êtes monté et puis vous êtes à un endroit où vous n'êtes plus compétent. Et si quelqu'un se rend compte, il se passe quoi? Vous redescendez? Bref, ça, c'est des vraies questions qui sont quand même assez stressantes et on n'a pas envie de se retrouver du coup en haut de l'échelle du principe de Peter. Et aujourd'hui, ce qu'on va proposer du coup avec les différents intervenants, c'est des solutions à ça et voir quelles sont du coup les alternatives, les options que l'on veuille devenir directeur ou autre chose.

Du coup, Dimitri, si tu veux bien me rejoindre sur scène. Et ce qu'on va faire également, du coup, ce que je vous propose durant la présentation, c'est que... Bonjour Dimitri. Bonjour. Que vous posiez vos questions directement aux intervenants. Et si les autres intervenants souhaitent aussi rebondir sur l'intervention de Dimitri, rejoignez-nous sur scène avec grand plaisir. Bonjour, est-ce que tu peux te présenter? Bonjour, Dimitri Baely, je suis un des cofondateurs de Tech.Rocks. Il y a quelques années, justement, pour partager un peu toute l'expérience autour de la séniorité dans la tech, que tous les CTO et tech leads qui sont un peu isolés dans leur contexte puissent échanger les uns avec les autres. Donc très très content de... De vous retrouver ici. Et en termes de travail, je viens de démarrer un nouveau poste chez Back Market, justement pour l'organisation des équipes tech chez Back Market, où il y a déjà 250 personnes à la tech, plus 200 postes, 100 postes ouverts actuellement.

Donc, des bons challenges d'organisation et des bons challenges de faire grandir des seniors au sein de la structure back market. Donc, on est plein dans le sujet. Super, absolument parfait. Et du coup, pour un peu illustrer ce que tu es venu partager avec nous, j'ai un visuel qui m'a été passé avec une double échelle. Est-ce que tu veux en... Parler, est-ce que... En fait, la question, c'est qu'est-ce qu'on propose aujourd'hui aux gens qui, à la base, du coup, sont d'abord juniors, puis ensuite software engineers, puis seniors? Qu'est-ce qui se passe ensuite pour eux? La question effectivement de la carrière tech que tu as bien posée tout à l'heure, où on fait une école d'ingénieurs, On est passionné par l'informatique, on est développeur et on apprend à développer, à produire, à contribuer aux différents logiciels sur lesquels on est amené à travailler.

On finit par se poser la question au bout de 6-7 ans, qu'est-ce qui se passe après 10 ans? La problématique, c'est tant qu'on continue d'apprendre, on est content, mais peut-on continuer d'apprendre pendant 10, 15, 20 ans? Et au bout de 6-7 ans, on découvre un petit peu ce questionnement, dois-je devenir manager pour continuer de progresser au niveau salaire? Ou puis-je continuer d'être très technicien et continuer de progresser en termes de salaire? Donc on a un petit peu cette question du salaire et de la progression qui vient de challenger notre passion de l'informatique, la passion de devenir développeur. Classiquement, avec Hugo, il y a beaucoup de gens qui travaillent sur ces problématiques au sein des entreprises. On a deux points de vue, le point de vue de l'individuel. J'ai une petite question qui concerne ces questions individuelles, qui est une question de François, qui est, est-ce que ici le terme engineer englobe à la fois le métier de développeur et d'architecte pour vous?

Oui, c'est tous les métiers de la tech, de comment on s'y retrouve. Donc, on pourra essayer de positionner le métier d'architecte à l'intérieur. Est-ce que c'est un contributeur? individuelle ou est-ce que c'est un manager ? Donc ça, on pourra y répondre, discuter de ça aussi avec Hugo. Donc là, je présente vraiment le Y qu'on a en face de nous, qui est la synthèse qui est faite avec Hugo du marché. De tel que ça existe dans la plupart des boîtes. Donc là, on est plus sur une synthèse avec les deux branches, une branche d'engineering management, où on est manager d'équipe tech avec de l'expérience tech, et cette branche qu'on propose de creuser, de discuter, et c'est aussi beaucoup avec Hugo qu'on a envie d'échanger là-dessus, sur cette notion de... De contributeurs individuels et de est-ce qu'on peut rester expert et rémunéré à notre valeur en tant qu'expert indéfiniment dans la tech. Voilà un petit peu le programme avec une question de est-ce qu'on peut faire les deux en même temps?

Est-ce qu'on peut passer de l'un à l'autre? Comment on grandit? Et toutes ces questions-là. Et est-ce que tu as des axes de réflexion et des pistes à donner à notre audience aujourd'hui? En termes d'introduction, on a pris le parti un petit peu avec Hugo dans les recherches et dans le sujet de moi prendre le point de vue du manager des gens tech. Quelles questions doit-on se poser en tant que manager de senior tech ou de personne tech? Comment on les oriente? Quelles questions on se pose pour les orienter? Donc moi, j'ai envie de recevoir des questions sur cette problématique-là et de vous orienter vers les discussions avec Hugo sur... Comment on vit en tant que tech, en tant qu'architecte, en tant que contributeur individuel, comment on se pose des bonnes questions et comment on choisit notre carrière. Et Caroline, que je te laisserai présenter, était très questionnée sur le sujet, j'imagine, pour les personnes recrutées ou l'accompagnement de leur carrière.

Oui, complètement. Et d'ailleurs, est-ce que ce ne serait pas l'occasion de faire monter Caroline sur scène avec nous pour commencer justement à ajouter un peu à la discussion? Bonjour Caroline. Je rappelle que tu es du coup CEO chez The Allyance. Est-ce que tu veux te présenter en quelques mots? Oui, je vais faire court et je salue la très belle transition. Pour faire simple, je m'appelle Caroline Therwath-Chavier. Dimitri, est-ce que tu peux mute, s'il te plaît? Merci. Merci. Je m'appelle Caroline Therwath-Chavier. Pour faire très simple, en fait, ça fait 10 ans que je fais du recrutement dans la tech. Donc, des développeurs, des développeuses, plutôt des personnes qui travaillent sur des sujets en lien avec le machine learning. J'ai aussi cofondé un meet-up qui compte 4400 membres et qui s'appelle Paris Women in Machine Learning and Data Science. Je pense qu'au fil de la conversation, vous le verrez, mais les sujets de représentation, de diversité et d'inclusion sont des thématiques sur lesquelles je me suis penchée depuis maintenant plusieurs années.

Et donc The Allyance, c'est une structure que j'ai créée il y a deux ans maintenant, qui nous permet d'aider des entreprises de la tech à recruter, à travailler sur les sujets de diversité et d'inclusion plus en profondeur avec des formations. Typiquement, il y en a une que j'adore, c'est celle sur les techniques de diversity sourcing. Et ce qui est rigolo, c'est qu'on l'avait conçue pour les équipes de recrutement. Et aujourd'hui, on se retrouve à donner cette formation. aussi à des managers, à des intervieweurs qui recrutent. Donc ça, c'est intéressant. Et pour terminer et faire la conclusion avec le thème du jour, on accompagne aussi des ingénieurs seniors dans leur recherche d'emploi. On fait ce qu'on appelle, on est agent de carrière. Et typiquement, dès que je me suis lancée, la première personne que j'ai accompagnée, c'était un développeur qui avait plus de 20 ans d'expérience, qui avait écrit un livre sur le F-Sharp. Et en fait, il avait envoyé plus d'une centaine de candidatures. Et il avait fait face à cette problématique justement de...

Aller vers le poste de management alors que ce n'était pas du tout ce qu'il n'épanouissait, ou arriver à tout un chemin de carrière vers l'expertise technique, et donc les postes qu'on va à mon avis beaucoup évoquer aujourd'hui, staff engineer, principal engineer. Et quand on a préparé l'intervention du jour, j'ai souligné une chose, c'est que moi, ça fait 2-3 ans que je vois cette typologie de poste Principal Engineer, Staff Engineer, devenir de plus en plus systématique et systémique en France, alors qu'en fait, c'était un phénomène qu'on voyait beaucoup aux États-Unis parce qu'on avait des organisations beaucoup plus matures. Donc, on aura l'occasion d'en rediscuter. Super, merci beaucoup Caroline. Écoutez, je vois une transition à nouveau parfaite pour un... Produire du coup notre dernier invité qui est Hugo. Merci pour ta question, Guionel, dans l'onglet Q&A. D'ailleurs, n'hésitez pas à poser vos questions là-bas. Lionel qui nous dit, j'aime également mesurer l'impact possible individuel, équipe transverse, entreprise, extra-entreprise.

Et justement, si on passe sur la slide suivante, il se trouve que Hugo est venu nous parler de l'impact que chacun peut avoir à quel poste. Donc, Hugo, je rappelle que tu es CTO et cofondateur de Malt. Est-ce que tu veux bien te présenter en quelques mots, s'il te plaît? Oui, bonjour. Effectivement, je suis aujourd'hui chez Malt, ça fait maintenant une petite dizaine d'années. J'ai été freelance auparavant, j'ai fait pas mal de métiers dans pas mal d'entreprises différentes et je me suis beaucoup posé la question de... Justement, comment est-ce que je progresse? Je me suis toujours considéré comme contributeur individuel, et aujourd'hui d'ailleurs en tant que CTO, je me considère comme un contributeur individuel. Simplement, l'impact, c'était l'objet de la question au début, pour moi, il a changé. Je me suis posé plein de questions sur... Comment progresser dans la boîte? Qu'est-ce que ça veut dire être senior?

Ah tiens, finalement, senior, ce n'est pas la fin. Il y a peut-être beaucoup de choses à faire. Et la définition la plus évidente que j'ai trouvée en face de ça, c'était à quelle influence j'ai? Et c'est pour ça qu'on a essayé de représenter ça sur ce petit graphique-là, pour expliquer que l'impact qu'on va avoir au fur et à mesure de notre montée en séniorité, il va se mesurer sur plein de sujets, mais l'un de ces sujets-là, c'est... l'influence que je vais avoir sur d'autres personnes, voire ma société elle-même, voire même l'industrie. Donc c'est comme ça qu'on a représenté ça. Tout d'abord, lorsqu'on débute, le premier impact qu'il faut avoir, c'est évidemment sur son... Soi-même, il faut progresser, donc il y a beaucoup de choses à apprendre. C'est, je dirais, la première étape. D'ailleurs, ça rejoint une autre des questions de la partie Q&A, c'est peut-on aborder les expertises techniques et métiers pour déterminer la séniorité? C'est effectivement quelque chose à prendre en compte jusqu'à un certain seuil.

C'est-à-dire que moi, je m'attends à avoir des personnes qui montent jusqu'à senior. D'abord parce qu'ils ont développé leur champ d'expertise. On parle souvent de profilanté dans le recrutement. Le profilanté, si vous connaissez, c'est la barre horizontale qui correspond au champ des compétences et puis la barre verticale qui correspond à la profondeur d'expertise sur une des compétences. Le fait de progresser vers la séniorité, il y a souvent cette barre verticale qui est travaillée. D'abord, on va avoir de l'impact sur soi-même, ensuite on va avoir de l'impact sur son équipe. Ensuite, on va commencer à élargir un petit peu son influence au niveau des communautés de pratique. Et c'est à partir de là où il commence à y avoir une vraie question, c'est sur le sujet justement de ce fameux Y. Je vais commencer à devoir avoir de l'impact beaucoup plus sur le produit en lui-même, ma compagnie. Quels sont les problèmes sur lesquels la compagnie doit travailler?

C'est là le... Le gros gouffre qui existe entre senior et staff, staff qui était introduit juste avant, c'est je dois changer d'attitude, je ne suis plus là pour simplement participer à la création, et l'exécution, je dois commencer à influer sur l'entreprise pour trouver les problèmes qu'il va falloir résoudre pour aller plus loin. Et puis après, je parle pas forcément du niveau de l'industrie, parce que là, on commence à parler des principals ou des philo ou distinguished. Et voilà, on pourra l'évoquer après, mais ça commence à être beaucoup plus loin déjà. Tu parlais à l'instant de recrutement. Est-ce que Caroline, du coup, c'est des choses sur lesquelles vous accordez beaucoup d'importance lors du recrutement? Comment vous le mesurez? Est-ce que ça se mesure pareil chez tout le monde? Que j'ai pour toi, Ovis, qu'Hugo vient de dire.

Déjà, je voulais rebondir sur quelque chose qui avait été évoqué par Dimitri tout à l'heure sur la partie évolution salariale. Selon moi, si on parle de ce sujet aujourd'hui, c'est parce que c'est un sujet avant tout de rétention des talents et surtout de comment est-ce qu'on peut conserver des compétences techniques qui sont précieuses pour une organisation. Et pour scinder ces deux sujets-là, il y a bien sûr une partie liée à la rémunération. Il y a aussi une partie sur l'évolution de la carrière. Et quand on recrute un, une principal engineer du développement d'une carrière, côté ingénierie, et en fait, c'est super intéressant. Vous voyez que vous pouvez commencer back-end engineer, par exemple, puis senior back-end engineer, Et ensuite, vous allez avoir une arborescence qui va partir dans trois directions. Ça va pouvoir être staff, back-end engineer, database, staff reliability engineer, etc. Et ensuite, ça me permet d'introduire les notions qu'évoquait Hugo.

Quand vous allez vouloir évoluer, alors que vous aviez trois pistes, on va arriver à ces postes de Principal Engineer, d'Instigwitched Engineer et de Fellow Engineer. Ça, c'est un peu le Graal, le dernier truc qu'on peut faire. Et en fait, ces postes-là, ils sont intéressants parce que souvent, les personnes qui ont envie d'occuper ces postes, c'est des gens qui aiment avoir de l'influence. Par exemple, participer au recrutement, faire en sorte que les bonnes pratiques de développement soient connues de toutes les équipes de développement, mais qui n'ont pas nécessairement envie de manager des individus. Et souvent, en fait, les postes qu'on vient d'évoquer, ce sont des gens qui vont continuer de coder, qui vont intervenir à l'international lors de conférences, mais qui ne vont pas avoir de direct report. Elles ne vont manager personne. Donc, si ta question, c'était... Et voilà, qui est-ce qui peut être intéressé par ce type de poste du point de vue de la recruteuse que je suis ?

C'est des gens qui aiment la technique, qui n'ont pas forcément une attirance vers le management, mais qui ont envie de continuer de bosser sur des sujets techniques, l'architecture, etc. D'accord, merci beaucoup. Et du coup, je pense qu'on revient un peu vers Dimitri, de fait, qui est de dire comment on va les orienter dans les organisations, ces personnes justement. Premier point, ces personnes-là sont vitales pour l'entreprise, parce que s'il n'y a que des managers et que des juniors développeurs, on va avoir beaucoup de mal à avoir du logiciel de qualité, de la production de qualité. Donc la question, il y a la question du salaire pour chaque personne, mais il y a aussi la question de la qualité du logiciel produit par l'entreprise et comment justement avoir des seniors. Très productif avec un impact sur l'ensemble de l'entreprise. Là, j'ai vu qu'il y a une question sur la partie stratégique versus technique.

C'est bien d'un impact stratégique au niveau de l'entreprise dont on essaye de parler, que les seniors puissent aider l'entreprise à vraiment se développer. Donc là-dessus, c'est... Comment bien utiliser les personnes? Un axe, moi, en tant que manager de Gentech, la meilleure question à se poser, c'est quelles sont les prochaines choses qu'ils ont à apprendre pour pouvoir progresser? Comment on fait progresser ces personnes? Quelles sont les parties qu'ils ont à apprendre techniquement? Mais aussi en capacité d'impact. Et je pense que Tech.Rocks est aussi là pour prouver aux gens qu'ils peuvent avoir un impact. Dans leur entreprise, mais aussi à l'extérieur. Donc d'échanger avec ses pairs, d'apprendre de ses pairs et de comprendre que leur connaissance Elles ne sont pas que pour eux, mais elles sont aussi pour toutes les personnes qui les entourent. Donc moi, en tant que manager, le vrai point sur l'impact, c'est la capacité de multiplier sa connaissance, de la transférer et d'aider toute l'entreprise à grandir.

Donc c'est vraiment ça le point. Ou est-ce qu'il veut être manager parce qu'il aime accompagner des gens dans la responsabilité, les tâches à faire, l'organisation des équipes, la structure même de l'organisation? Ou est-ce que c'est le produit lui-même sur lequel ils veulent contribuer? Très clair, merci beaucoup. Du coup, pour reprendre la question que tu as mentionnée dans le chat, c'était une question d'Alexandre qui était adressée à Hugo. Bonjour Hugo, quand vous mentionnez influer dans l'entreprise, pensez-vous seulement au niveau opérationnel ou aussi au niveau stratégique? Et du coup, elle vient d'être répondue. Merci pour cette question. Je pense que Hugo a peut-être un complément sur ça. Non, effectivement, ce n'est pas uniquement opérationnel. C'est-à-dire qu'après, il y a plein de... En fonction de l'équipe dans laquelle on travaille, on peut être amené à avoir plus d'influence sur tel ou tel sujet.

Moi, je suis dans une boîte qui fait du produit. Et dans ce cadre-là, je vais attendre des personnes qui sont en staff ou plus d'avoir une vraie vision critique aussi sur la stratégie qu'on va adopter sur le produit. Donc, traditionnellement, dans les entreprises qui font du produit, on va parler de discovery et de delivery. Sur la discovery, j'attends que les staffs et plus soient pertinents, apportent des idées novatrices sur comment est-ce qu'on va valoriser la technologie au sein du produit, comprennent le business, hyper important. Jusqu'à senior, je ne vous cache pas que déjà chez Malt, je vais demander à tout le monde, y compris en junior, etc., de comprendre le business. Mais à partir d'un certain seuil, pour moi, on ne peut plus progresser. Et si on ne le comprend pas. Parce que c'est comme ça qu'on va réussir à avoir de l'impact. Une des étapes nécessaires pour en avoir, c'est d'écouter les gens, tout simplement. Alors, quand on est dans une équipe plateforme, ça veut dire...

La terminologie d'une équipe plateforme, c'est celle qui est un petit peu au service des autres équipes. C'est par exemple la Developer Experience, etc. Quand on est dans ce genre d'équipe, on se dit« Ok, je suis loin du business». Oui, mais en fait, le business direct, ce sont les autres équipes. Nos utilisateurs, ils sont là, ils sont dans l'entreprise. Donc si je peux avoir de l'impact, Et dans les équipes qui sont, je dirais, plus entre guillemets métiers, je n'aime pas trop cette séparation, mais là c'est pareil, il faut aller voir les utilisateurs, ou même voir, il faut utiliser son propre produit quand c'est possible. Donc dans tous ces cas-là, oui, ça ne touche pas que à la partie opérationnelle, c'est beaucoup plus large. Merci pour ces précisions, Hugo. Moi, du coup, me vient une question peut-être un peu pour tout le monde qui est comment vous... Quels seraient les conseils que vous donneriez à quelqu'un qui souhaite bien comprendre son business, son métier, son industrie, justement pour progresser? Je vais me lancer.

Je ne suis pas sûre d'avoir compris la question exactement, mais est-ce que tu l'entends du point de vue métier ou du point de vue des postes qu'on évoque depuis tout à l'heure ? Je pense que ce serait vraiment un conseil général pour les gens qui commencent à se dire que techniquement, là, ça y est, il commence à être vraiment bon. Et que justement, pour pouvoir vraiment progresser et avoir plus d'impact, maintenant, il va falloir... élargir, on va dire, son champ de compétences et plus le garder uniquement sur un aspect technique, mais aussi vraiment aller chercher du coup tout cet aspect, comprendre l'industrie dans laquelle on évolue. Tu vois, par exemple, si on bosse dans les télécoms, c'est un autre monde que de bosser, par exemple, dans le cloud ou dans tout autre secteur, en fait. Il faut aussi comprendre son industrie pour pouvoir avoir plus d'impact. De ce fait, je vais me jeter à l'eau et j'espère que Dimitri et Hugo compléteront. Mais je pense que pour répondre à ta question, il y a un truc qui est essentiel et c'est chouette, parce qu'a priori, on travaille tous avec des ingénieurs, c'est de faire de la veille. C'est connaître son positionnement dans un écosystème.

Regardez aussi ce que font les autres, parce que c'est assez inutile de chercher à réinventer la roue. Il y a des choses qui fonctionnent bien dans d'autres domaines d'application ou auprès de gens qui travaillent sur d'autres problématiques. Typiquement, par exemple, si je l'applique à moi-même, en tant que recruteur, je regarde beaucoup ce que font, par exemple, des sales, des personnes qui font du growth hacking, ce genre de choses. Et quand on est sur la partie technique et qu'on avance dans le nombre d'années d'expérience, regardez ce qui se passe côté produit dans les expériences. Si on a plutôt une expertise côté infra, pourquoi pas jeter un petit coup d'œil, par exemple, sur les sujets ML Ops? Parce qu'en fait, on peut se retrouver au milieu pour faire un bel anglicisme. Je ne sais pas si vous l'avez eu, mais il était là. Mais faire de la veille et regarder aussi ce qui se fait ailleurs. Et je pense que, par exemple, une communauté comme Tech.Rocks, c'est ultra pertinent. Parce que si on n'a pas le temps, souvent c'est ça qui nous manque. Voilà, ça fait un moment où on peut entendre des idées qui nous viennent d'ailleurs. Et quand on est...

Principal Staff Engineer, il y a aussi toute la partie DevRel qui est très importante. Faire rayonner, faire connaître ces problématiques. Je pense que c'est essentiel. Merci beaucoup. Et là, je me sens un peu visée. C'est vraiment compliqué. Dimitri, je vois que tu es admis. Donc, vas-y, je t'invite à revenir. La grosse question dans les discussions qu'on a eues avec Hugo sur le sujet, c'est l'implication dans le produit. Et moi, en tant que manager de senior, c'est est-ce que vous attendez qu'on vous dise quoi faire ou est-ce que vous allez à la source des problématiques? Est-ce que vous êtes impliqué dans les discussions? Est-ce que vous suivez ou vous avez connaissance des discussions produits, justement, qui sont en cours pour votre entreprise? J'ai envie de pousser le bouchon un tout petit peu plus loin. Est-ce que vous rencontrez des utilisateurs du produit de l'entreprise? J'irais là-dessus, et en tant que manager, est-ce que vos équipes rencontrent des utilisateurs sur le contact du produit?

Alors, ce n'est peut-être pas valide pour toutes les entreprises, pour tous les cas, mais la plupart des entreprises pour lesquelles moi j'ai été impliqué, on avait des équipes de dev qui étaient un peu coupées, et des techs qui étaient coupés des utilisateurs. Un peu artificiellement, et moi j'ai envie de dire, ce n'est pas à l'entreprise de vous pousser à rencontrer les utilisateurs, vous avez le droit d'aller les voir, vous avez le droit de rentrer dans les discussions produits pour les comprendre, et de remonter un peu à la source de ce qui vous arrive pour pouvoir avoir de l'influence dessus. Donc c'est comment vous poussez vos équipes à être au plus proche de la source des problèmes. de la compréhension des problèmes. Merci beaucoup. J'ai une question qui vient d'arriver dans le chat. Une question de François qui dit, à quoi correspond la notion de pendulum sur le schéma? Merci encore pour moi. Ça fait référence à un article de Charity Majors, qui était, quoi qu'il m'a beaucoup, beaucoup influencé, qui dit qu'on peut être manager, on peut être contributeur tech, mais on ne peut pas faire les deux en même temps.

Et pour résoudre ça, on peut l'alterner. Donc c'est intéressant, y compris pour des contributeurs individuels qui veulent faire carrière en tant qu'experts, d'avoir une expérience de management pendant un moment. Et je l'ai pas mal pratiqué dans d'autres expériences, de permettre à des contributeurs individuels d'être manager pendant un temps avant de revenir en tant que contributeur individuel avec un impact majeur. Probablement plus simple à manager par la suite, parce qu'ils comprennent mieux la problématique de management des équipes tech. Donc voilà, cette partie pendulum, c'est qu'on peut passer d'une branche à l'autre, on peut avoir de la mobilité entre des équipes, entre des professions, et c'est intéressant de faire le parcours de différentes professions pour les essayer et savoir laquelle nous plaît vraiment et dans laquelle on a un impact. Ma plus grosse question, c'est qu'on ne peut pas savoir quel impact on aura, il faut essayer. Et si on a de l'impact, on continue.

Et c'est un peu la mesure intéressante en tant que manager sur les personnes que vous accompagnez. Merci. Et vous, tu as des choses à ajouter? Oui, c'était juste pour compléter. Souvent, on parle de dual leader. Donc, des barreaux d'échelle, en fait. Quand on montre les deux parties, il y a ces fameux barreaux qui permettent de passer l'un à l'autre. C'est une formulation qu'on va retrouver très souvent dans le cas où il repasse. Effectivement, qui illustre le fait qu'on puisse passer de l'un à l'autre, ce qui n'est pas toujours sain, mais qui est possible. J'ai une question qui, je ne sais pas comment la placer, je vais être honnête, donc on va la placer tout de suite et vous êtes tous invités à répondre. C'est bonjour, au-delà de la question d'évolution salariale, n'y a-t-il pas des sujets d'emploi au-delà d'une certaine tranche d'âge? Très bon sujet. Très bon sujet. Je ne suis pas si vieux que ça. C'est effectivement un très bon sujet, parce que tu le disais en introduction, Valériane,

derrière la notion de on m'a attribué une position de seigneur dans ma boîte, se cachent pas mal de choses en fait. Est-ce que ça veut dire que dans ma boîte, spécifiquement dans ma boîte, c'est la fin? c'est la fin, c'est-à-dire qu'il n'y a pas d'évolution spécifiquement en termes de titres, etc. Et donc, autrement dit, mon salaire, il n'évoluera pas. Est-ce que... Moi, j'ai vécu dans des entreprises où la moyenne d'âge souhaitée, je ne parle même pas... Des fois, on recrute et puis il se trouve qu'à la fin, on calcule la moyenne d'âge, elle est telle qu'elle est. Il y a des fois, en fait, la moyenne d'âge souhaitée, c'est en dessous de 32 ou en dessous de 31 ans. C'était ça quand j'étais... Après, en boîte dans laquelle j'ai bossé. Il y avait un vrai sujet de modèle économique. Le modèle économique, c'était, il y a des gens qui rentrent dans la boîte et on les place, je vais utiliser le terme gentil, on les place dans d'autres entreprises.

Donc forcément, à la fin, on est capé par l'argent que ça génère. C'est comme ça qu'on va déterminer le salaire. Après, il y a aussi beaucoup de modèles d'entreprise, des éditeurs notamment, mais pas que. qui eux vont baser leur évolution de salaire un peu différemment, ils ont d'autres modèles de revenus, ce qui n'est pas basé directement sur ce que va dégager la personne chez un client. Et c'est dans ces entreprises-là, très souvent, qu'on va retrouver ces échelles de progression, comme staff principal et autres. Alors là, c'est un modèle américain, comme disait Caroline tout à l'heure, il en existe d'autres, mais c'est quand même un qui commence à s'imposer. Et c'est, si on parle de salaire, Oui, il y a un plafond de verre qui existe dans pas mal d'entreprises, mais il est quand même en train de pas mal changer ces dernières années. On peut retrouver des benchmarks sur le net qui peuvent nous laisser croire qu'il n'a pas trop évolué, mais il y a quand même beaucoup d'entreprises aujourd'hui dans l'écosystème tech qui sont prêtes à aller sur des salaires...

C'est difficile de donner une fourchette exacte, mais on va dire au moins jusqu'à 100 et plus pour des contributeurs individuels qui ne font pas de people management. Je voudrais juste... La dimension salariale, elle est présente. Ensuite, il faut vraiment aussi réfléchir à quelles valeurs est-ce que ces personnes-là vont apporter. Et dans une structure, typiquement, avoir des principal engineers, des staff engineers, ça va permettre aussi aux autres développeurs et développeuses de level up. c'est que ça peut être un point de référence vers lequel on se tourne quand on a des questions un petit peu pointues, par exemple sur des systèmes distribués, etc. Donc ça, ça permet aussi d'améliorer le niveau général de ces équipes de dev. Il y a aussi toute une notion de rayonnement qu'on a mentionné un petit peu plus tôt. Et je voulais aussi mentionner une autre référence, c'est Sylvia Botros.

On en parlait juste avant qu'on commence la présentation. Elle était chez Twilio, elle vient de commencer chez Box. Et elle, elle dit bien qu'en fait, elle participe au recrutement, elle ne manage personne, elle est présente, elle est disponible pour les développeurs, développeuses plus juniors, Elle fait de la veille technique sur des sujets très pointus. Et toujours un coup d'avance. Nathalie est en train de pointer le bout de leur nez, mais en fait qu'elle les anticipe. Et tout ça, en fait, c'est aussi de la réduction de coût pour une structure. C'est qu'avoir ce type de gens, si vous gardez vos équipes en interne, du coup, il y a moins de frais de recrutement. Et là, c'est quand même une bonne nouvelle. Il y a peut-être davantage de features poussées, il y a moins de dettes techniques, et en fait, il y a aussi plein de coûts, d'économies additionnelles qu'il faut avoir à l'esprit. Et je voulais juste compléter ce que vous aviez dit tous les deux, parce que je suis d'accord avec vous. Si je peux rajouter un petit peu, moi, j'ai eu deux expériences, deux apprentissages quand j'ai mis en place cette dual ladder chez lesfurets.com.

La partie gauche n'existait pas du tout. On n'avait qu'une grille pour les managers. Et pour pouvoir augmenter et avoir des personnes qui avaient 15 ans, 16 ans d'expérience, pour pouvoir les augmenter de façon logique dans l'entreprise, parce que les grilles d'augmentation sont plutôt assez lentes dans les entreprises et il faut des promotions pour faire des sauts salariaux. Et une des façons de lire la grille, là, c'est qu'on se dit qu'il y a une promotion à chaque passage de 10-15% de salaire que les managers doivent mettre en place dans les entreprises. Et si on fait un saut tous les trois ans, là, ça fait une carrière de 20 ans sous les yeux, où on arrive à avoir une augmentation qui est celle à peu près du marché, Hugo, sans donner les chiffres, c'est moi ce que j'avais calculé en tant que manager, c'est 5% par an en moyenne sur 20 ans, te fait passer de 50 à 110, 120, 1000 euros si tu as une carrière assez linéaire.

Donc cette partie-là, c'est l'engagement du management de pouvoir augmenter de façon continue avec une perspective les personnes. Quelle que soit la structure d'augmentation de l'entreprise. Donc moi, ce que j'avais eu à faire, c'est à mettre en place ces promotions. Donc là, chaque petite flèche, c'était une promotion de 10 à 15% que les personnes et les managers avaient en tête comme une trajectoire possible dans l'entreprise. Et ça, c'est important. Et le deuxième point d'apprentissage assez important pour moi, c'est la R&D, le software dans les entreprises, c'est de l'investissement. C'est du CAPEX pour ceux qui suivent un peu les structures financières. Et c'est un investissement que l'entreprise fait sur les développeurs. Et quand on parle d'investissement, on se dit qu'une entreprise réinvestit 4, 5, 10% de sa marge en termes d'investissement. Donc, si vous avez un salaire de 100 000 euros, c'est quelque part que vous travaillez.

sur un million de valeurs pour l'entreprise. Donc ça, c'est moi une partie, alors qu'il n'est pas simple à expliquer, mais c'est si vous avez un salaire de 100 000 euros, vous avez un engagement à aider l'entreprise à améliorer la performance d'un million d'euros de marge brute qu'elle a. Et ça donne un bon référentiel de l'impact qu'on doit avoir. C'est un multiplicateur par 10 de la valeur que vous coûtez à l'entreprise. Et du coup, ce serait une valo annuelle. Oui, pour moi, si l'entreprise gagne un million d'euros brut avant les salaires et compagnie, elle peut bien investir 100 000 euros dans la tech pour améliorer cette rentabilité-là. C'est la vision que j'ai, qui est un petit peu artificielle, mais qui se dit que 100 000 euros, ce n'est pas toute la marge de l'entreprise, c'est pour les trois ans à venir. Donc, on investit notre salaire actuel dans la tech pour la rentabilité de l'entreprise à venir.

Et ce qui est très différent des autres salaires de l'entreprise qui sont directement des coûts, assez souvent, des coûts dans l'année qui vient. Donc, sujet un peu complexe, mais on est une source d'investissement dans l'entreprise. Donc l'entreprise investit dans nos salaires, donc on peut avoir, quel que soit notre âge, des salaires assez élevés, parce que ces investissements-là vont rapporter, comme disait Caroline, dans l'avenir. Le mindset, pour moi, il est dans ce sens-là. D'accord, très bien. Est-ce que ce ne serait pas l'heure de prendre une question? Du coup, on a une question qui est… Le meet-up soulève la question de la sécurité psychologique des devs. Une question de Lionel. Peur de l'obsolescence, de rupture avec le marché, de rupture avec le marché avec l'âge et le rythme de vie qui tend à épuiser les devs. Caroline, tu as peut-être quelques insights là-dessus ? Oui, c'est un sujet qui me passionne.

Tout à l'heure, je crois que c'était Hugo qui mentionnait un âge moyen de 30 ou 32 ans. Il y a eu un article, il y a un an et demi, qui avait été publié par Hacker Moon et qui nous venait... Mais Dimitri, tu peux te mettre en mute, parce qu'on frotte avec toi. Et donc, aux États-Unis, en fait, ils avaient fait un sondage auprès de la communauté technique à San Francisco. Et en fait, je vous la pose, tiens, la question. Savez-vous à partir de quel âge? On est obsolète dans la Silicon Valley. À partir de quel âge est-ce qu'on devient vieux? Si vous avez envie, vous pouvez mettre sur le chat. Sinon, je vais vous le dire tout de suite. C'est à partir de 29 ans. Donc, voilà. C'est assez violent. Et en fait, au-delà de la blague, c'est un vrai sujet en termes de perception, de stéréotypes. Et moi, je le vois au quotidien. J'accompagne des femmes, des hommes qui ont 40, 45 ans et en fait, qui rament comme des fous pour ne serait-ce que décrocher un entretien parce qu'en fait, sur la base du CV, on voit bien que la personne avait de la bouteille.

Et en fait, je pense que collectivement, on a quelque chose à... Il faut qu'on mette un coup de pied dans la fourmilière de cette espèce de biais qu'on peut avoir de« t'as plus de 40 ans, t'es obsolète, tu sers plus à rien, t'es lent». Je trouve ça d'une... Une violence, c'est costaud. Et puis, il y a aussi cette idée de plus tu avances, plus tu coûtes cher. Oui, si on a tous des carrières linéaires, pourquoi pas? Mais en fait, il y a des gens qui ont fait des reconversions, qui n'ont pas le même statut. Donc, il faut encore une fois déconstruire ses propres perceptions. Et donc, l'agisme nous guette. Et en fait, nous, on est un peu des privilégiés, tous autant qu'on est, et on a notre pierre à amener à l'édifice. Parce que franchement, Je n'ai que 32 ans, mais je n'ai pas envie de me dire qu'à 45 ans, je vais être paniquée, je vais devoir devenir coach, parce qu'en fait, je vais me dire que je ne vais pas être employable par le marché. Et dans la tech, c'est ce qui peut nous guetter. Je veux bien votre point de vue aussi aux garçons, parce que moi, ça me fait hérisser le poil.

Et on se prive de compétences, surtout. C'est ça, le problème. Je me permets juste de remonter à quelque chose que je viens de voir passer dans le chat, qui dit un peu comme le cliché, notamment en France, si tu es encore d'Ève à 35 ans, tu as raté ta vie. Et ils disent que certaines personnes trouvent que ça a un peu volé sur le sujet. Ah oui, juste pour... Vas-y, Hugo. Non, c'est juste pour l'anecdote, mais il y a... Pas mal d'années maintenant, il y avait un article de blog qui avait fait pas mal parler, qui s'appelait« À 31 ans, chauve et encore développeur». Je ne me rappelle plus le titre exact. Il y a quelques années, il y a un article qui disait« Peut-on être développeur après 40 ans? » Et puis là, j'ai vu un article qui disait« Peut-on être développeur après 40 ans? Récemment, une conférence, peut-on être développeur après 50 ? Donc, j'ai quand même la sensation que, en fait, la question, d'année en année, on repousse l'âge. Moi, en tout cas, de ce que je vois, cette limite, elle évolue, en tout cas en France. Oui, beaucoup plus que ça. C'est vraiment cette échelle qu'on met. Pourquoi on en parle? Hugo, tu as fait le travail chez Malt.

Moi, je le fais chez Back Market. Toutes les entreprises sont en train de créer cette grille-là. C'est une grille anti-obsolescence. On est en train de se rendre compte que les distinguished, les principaux, les gens qui ont un impact, qui ont prouvé, c'est une échelle de preuve d'impact dans l'entreprise. Qu'on est en train juste de donner, de dire, voilà, les entreprises qui utilisent cette échelle-là bénéficient de l'impact des gens à des salaires qui ne sont finalement pas si chers que ça. Et c'est une échelle anti-obsolescence pour moi, complètement. Et pour mon cas personnel, je repars en contributeur individuel, je n'ai plus de management et j'ai un tout petit peu plus de 45 ans. Donc, je ne me sens pas du tout obsolète en termes d'impact pour l'entreprise parce que cette échelle-là existe et parce que les managers l'ont en tête et n'ont pas de problématiques d'obsolescence. Face à eux. Justement, je me souviens de finir un peu sur les managers et j'ai une question.

Pour Hugo, c'est qu'est-ce que ça veut dire être manager aujourd'hui ? Oui, c'est un terme que je... Effectivement, on l'a beaucoup dit dans la présentation, dans la discussion qu'on a eue tous ensemble. Je vais revenir là-dessus parce que c'est... On a une certaine tendance à opposer contributeur à du lay manager de façon un peu pas péjorative, mais caricaturale. Et je trouve que c'est important de rappeler, en fait, que quand on commence à passer sur... sur des staffs ingénieurs, principales ingénieurs, etc. Pardon, ton micro, Dimitri. Merci. En réalité, le management, si on prend la définition exacte, c'est quelque chose comme l'ensemble des moyens qui permettent d'amener à terme un projet. C'est une définition qui est hyper large et qui ne veut pas forcément dire je fais du fichier Excel, je fais ceci ou je fais des one-one, etc. En fait, le management, c'est beaucoup plus large que ça.

Quand on commence à passer staff, et plus, on demande à ces personnes-là d'avoir du leadership, c'est-à-dire d'être capable de coordonner des personnes, d'être capable de convaincre, d'être capable de, quand on disait tout à l'heure avoir de l'influence au niveau de la compagnie, il va falloir aller discuter avec tous les types de postes dans l'entreprise. Pour expliquer en quoi la technologie peut avoir une valeur X ou Y. Ça veut dire que le management, ce n'est pas un truc qui est, déjà, premièrement, spatial, et deuxièmement, ce n'est pas réservé à une portion des gens. Si on veut progresser, il faut avoir des talents en soft skills aussi, communication, coordination, etc. Le management, c'est beaucoup plus large que juste l'intelligence des fois qu'on peut avoir. Mon résumé, c'est qu'il est responsable de créer... des conditions du succès.

C'est de s'assurer que les personnes de l'équipe ont tout ce qu'il faut pour pouvoir réussir et d'enlever les barrières et compagnie. Très clair, merci. Et du coup, dans les questions, on avait quelque chose qui reboute un peu avec ce que tu disais juste avant, c'était quel conseil pour passer de senior engineer à staff engineer, sachant qu'il me semble que ce sont plutôt des échelles anglo-saxonnes. C'est vrai que moi qui bosse dans une boîte américaine, je suis complètement biaisée à l'heure actuelle, donc je ne me sens pas de répondre là-dessus, mais si vous avez des cas d'usage plus franco-français, c'est le point de la question. Je suis bavard, je ne veux pas forcément monopoliser. Vas-y, Hugo. Non, mais c'est important, je pense, parce qu'on a une intention, justement, et pour moi, d'avoir poussé ce sujet-là, parce que je pense que tu l'as fortement poussé ces derniers mois en écrivant des articles, c'est de dire, si cette échelle anglo-saxonne existe, que peut-on en apprendre, qu'elle soit anglo-saxonne ou pas, en fait, elle est porteur de beaucoup de valeurs.

Dans la reconnaissance de la compétence individuelle. Et ça nous manque. Il y a des questions à se poser à un certain stade. C'est déjà accepter de dire qu'on ne fait pas forcément que de la tech pour de la tech. C'est un peu, je dirais, jusqu'à un certain stade, c'est normal de progresser sur ces compétences-là et d'être surtout reconnu pour ça. Mais progressivement, et déjà dès les stades d'avant, c'est pas staff qui fait... Staff, c'est un marqueur qui permet de dire, OK, là, mon influence, elle est beaucoup plus large et elle est systématique. Versus les positions précédentes, je peux évidemment avoir de l'influence et je peux parler d'autres choses que de la tech. La tech au service du produit, la tech au service de la mission de la boîte. Je dirais que ce qui va contribuer au fait de ne pas ses staffs, c'est cette notion de systématique, cette notion d'écouter les utilisateurs. d'aller faire partie de la discovery, de faire des interviews, d'être capable de coordonner des personnes, de convaincre des personnes sur une direction donnée.

C'est aussi un élément, c'est de ne pas être dans la position systématiquement du râleur. Parce que souvent, on se dit... Être celui qui va poser des questions, qui va challenger, etc. C'est celui qui râle. Non, c'est celui qui amène des solutions, en fait. C'est vraiment le sujet. C'est d'être celui qui amène des choses auxquelles les autres personnes n'ont pas pensé. Donc, on parle de problem solver. Je ne suis pas tout à fait d'accord, si je peux me permettre, parce que c'est plutôt... Amener les autres à se poser les bonnes questions. Parce qu'amener les solutions directement, ça va développer le mythe de celui ou de celle qui est omniscient et qui sait tout. Et c'est plutôt, voilà, comprendre la complexité. Mais je pense qu'on est d'accord sur l'idée. Non, c'est mal formulé dans ce cas. Ce n'est pas le message que je veux passer. On parle souvent du TenX Engineer. En réalité, le vrai sujet, c'est comment est-ce que je fais passer mon équipe entière, la boîte entière à TenX.

C'est une influence globale. Ça veut dire aussi, comme tu viens de le dire, il y a une notion d'influence sur les individus pour les coacher, les mentorer, etc. J'ai une question qui est de dire comment ça se passe quand on n'a pas un profil, je n'aime pas trop ce mot, mais neurotypique. Qu'est-ce qui se passe? Je sais qu'on est beaucoup dans la tech, en fait, on est sur des spectres hyper larges, que ce soit sur, du coup, à nouveau, je n'aime pas ce mot, mais la neuro-ICP, des formes d'autisme différentes, ce genre de choses. Et du coup, comment ça se passe quand on a ce genre de profil pour nous? Je vais me permettre de prendre la parole parce que je vais devoir m'éclipser dans quelques minutes. En fait, quand on est neuroatypique et qu'on occupe ce type de poste ou qu'on le brigue, il faut bien connaître ses besoins.

Pour pouvoir les exprimer et pouvoir permettre à l'entreprise de trouver des ajustements ou s'assurer en fait que vous allez occuper des responsabilités qui vont correspondre à vos aptitudes. La seule chose que j'aimerais souligner, c'est que souvent, les gens neuroatypiques vont avoir des problématiques sur l'attention, sur l'exposition. À des interlocuteurs plus ou moins bienveillants. Et donc, je pense qu'il faut faire très attention à s'assurer que les interlocuteurs seront assez cools, parce que ça peut être autrement assez pénible. Et je vais faire un tout petit virage. Je voudrais répondre de façon hyper pragmatique à la personne qui disait comment on fait passer le senior à staff. Écrire des articles, aller à des conférences, faire de la veille, appréhender son aptitude à travailler sur des sujets complexes qu'on n'a jamais rencontrés aussi. Ça, ça fait cinq points. Et après, je vous laisse peut-être boucler sur le neuroatypisme et ce type de poste, parce qu'en fait, au-delà de ces postes-là, c'est aussi un nom.

plus général que la tech doit traiter. Comment est-ce qu'on adapte le temps? Comment est-ce qu'on adapte les objectifs, etc. Merci beaucoup Caroline, c'était un plaisir de t'avoir avec nous aujourd'hui et à très bientôt, on espère. Au revoir. Merci. Si j'essaie d'apporter un petit point de vue en tant que manager sur la neuroatypie, mais aussi l'expertise finalement, parce que quand quelqu'un a décidé d'être ultra expert dans un sujet, il en perd un peu les compétences sur les autres domaines, que ce soit... Son cas intellectuel ou non, quand on est trop technicien ou trop expert, on perd un peu ses compétences de communication ou d'intégration. Et on en revient à la question du T-shaped, la capacité d'avoir...

Tout un spectre de compétences et un domaine d'expertise. Donc, pour moi, c'est aussi le rôle du manager de faire en sorte que des personnes qui sont ultra expertes puissent opérer un impact fort dans l'entreprise. Par l'association de personnes complémentaires, donc la création des équipes. Moi, je pense qu'il y a tout un panel de gens avec des profils intellectuels très particuliers qui représentent un avantage concurrentiel pour l'entreprise. S'ils sont les seuls à pouvoir résoudre un problème type qui est celui de l'entreprise, il faut que l'entreprise s'adapte à cette personne-là pour en exploiter ses compétences et que lui se sente en sécurité. Dans cette partie-là. Et pour moi, ça, c'est le rôle du manager. La personne toute seule ne peut pas forcément s'occuper de sa sécurité au sein de l'entreprise. Par contre, elle peut faire des feedbacks en disant, je ne me sens pas confiant à échanger dans l'entreprise, voilà mes problèmes.

Donc, c'est vraiment dans la discussion avec les managers. Le manager, pour moi, c'est vraiment une condition opposable. Il est là pour créer les conditions du succès, les conditions de la sécurité psychologique des personnes dans l'entreprise, quel que soit leur profil psychologique à eux. Et après, ça marche, ça ne marche pas. Mais pour moi, on est là pour travailler nos expertises et l'entreprise est là pour nous donner confiance dans notre poste et dans notre compétence. Super. Est-ce que, Hugo, tu veux ajouter un petit dernier mot? Il est 13h, on va bientôt finir. Et si ce n'est pas le cas, j'ai une question en vie ou non pour vous. Ben non, du coup. Non, non, vas-y. Justement, on va essayer de rester. C'était le timing. Alors, la question c'est, est-ce que les managers tech code, par exemple, sont-ils aussi contributeurs individuels dans vos équipes? Oui ou non? Les managers? Oui, les managers tech. Non, ils n'y arrivent pas. Après, ils peuvent avoir des hobbies à côté.

Donc, voilà. Moi, en tant que manager, les seules parties où je me suis permis de coder, c'est des outils pour l'équipe. Ok. Un petit détournement. Je partagerai dans le chat, mais j'ai fait un pied de blog sur les engineering managers, et donc non, chez nous, ils ne comptent pas. Mais c'est très dépendant de la taille de la boîte. Ce n'était pas la même réponse il y a quelques années quand la boîte était le plus. Super, écoutez, merci beaucoup, merci à tous. Ceci clôture du coup cette édition de Tech.Rocks. Je veux reprendre la parole pour vraiment close. C'est moi qui vais clore, je pense. Je vais faire la clôture, surtout pour remercier tout le monde de votre participation. Alors, c'est toujours très, très, très, très frustrant en virtuel. J'ai que des icônes face à... Face à nous, mais très très content. On sait qu'on est sur un sujet compliqué dont on doit parler de plus en plus.

Donc vos questions sont ultra importantes pour Tech.Rocks. On va vous envoyer un questionnaire de satisfaction, donc n'hésitez pas. à compléter, je pense qu'il y a la possibilité de mettre des notes et les questions complémentaires qui n'ont pas été répondues, parce qu'on essaye de travailler ce sujet sur plusieurs années au sein de Tech.Rocks. Et un énorme merci à Hugo d'avoir posé ce sujet sur la table. Parce qu'il est vraiment important. Et merci beaucoup, Valériane, d'avoir relevé ce défi de nous animer. Et à très bientôt, tout le monde. Au revoir et merci. Bientôt.