- Speaker #0
Imaginez que vous êtes un développeur ou une développeuse passionnée, travaillant dans une équipe soudée, respectée par vos pairs et écoutée par vos managers. Tout semble parfait. Jusqu'au jour, votre responsable vous demande de mesurer la productivité de votre équipe avec des KPI. Pourquoi ? Ce simple mot KPI fait-il frémir tant de lead tech, de développeurs et de développeuses ? Avec Uber, nous avons rencontré Geoffrey Graveau en marge de la J2 Montpellier pour plonger au cœur de cette question. Geoffrey possède plus de 15 ans d'expérience professionnelle. Il a accompagné de nombreuses organisations en tant que CTO, coach agile et formateur. Il est également speaker et coach d'orateur. Nous avons discuté avec lui de sa conférence intitulée « Au secours, mon manager me demande des KPIs » . Dans cet épisode, Geoffrey nous dévoile les défis et les perceptions des devs face aux KPIs. Nous discutons de l'impact de ces KPIs sur la performance et le bien-être au travail et partageons des stratégies pour les mettre en œuvre efficacement. Si vous vous êtes déjà demandé comment transformer la peur des KPI en un levier de performance et de motivation pour votre équipe, cette conversation est faite pour vous. Je vous laisse en compagnie de Geoffrey. J'ai une question simple pour démarrer. Alors pourquoi ça fait peur aux devs des KPI ?
- Speaker #1
Très bonne question, très très bien. En général, les managers ou des directeurs vont arriver avec des KPI cibles. ce qui peut faire peur déjà c'est le seuil à atteindre par exemple on peut dire aux développeurs je prends souvent cet exemple parce qu'il est courant et connu avoir 80% de couverture de code ça peut faire peur ça peut mettre la pression et des fois ça peut même ne pas faire sens parce que c'est pas forcément un KPI qui va aider l'entreprise et donc ce mix de tout ça fait que ça peut être mal vécu, mal perçu et l'autre point aussi qui est Pour moi, le plus dur, c'est qu'il y a peu ou pas d'accompagnement sur la mise en œuvre. Et derrière, c'est aux devs de subir quelque chose qu'ils n'ont pas demandé. Et c'est relativement désagréable.
- Speaker #0
Moi, il y a un truc qui m'a toujours fait peur dans le KPI. C'est qu'on peut faire dire ce qu'on veut à des stats.
- Speaker #1
Exactement.
- Speaker #0
Et en fait, la même stat, ça peut dire tout et son contraire. Et je ne sais pas, il y a toujours dans les grandes organisations qui sont très driveées par des KPI, il y a ce côté... comment avoir des indicateurs qui sont objectifs quand même, quelque part.
- Speaker #1
Je suis d'accord. C'est un vrai sujet. Il faut déjà... Il y a plein de questions à se poser. Une fois que le KPI est adopté, c'est se dire comment on l'alimente. Déjà avec une data fiable. C'est souvent peu travaillé. Très souvent, on essaie de trouver une première solution technique, sans se poser plus de questions. Ça marche, ça résout temporellement le problème. Mais derrière, la data n'est pas super permise. pertinente, elle peut être biaisée. Ça a un premier problème. La deuxième, c'est l'interprétation aussi. Comme tu disais, la statistique, on l'interprète comme on veut. Un management, un directeur, un chef de projet, un PO et des devs ne vont pas interpréter la donnée de la même manière. Il y en a qui vont trouver sa performance, d'autres non. Il y a une superbe loi dont je vais parler, d'une variante qui s'appelle la loi de Goudart, un économiste. Il dit que quand une mesure devient un objectif, elle cesse d'être pertinente. Par exemple, la couverture de code, ça fixe à 80%. qu'est-ce qui se passe ? Il y a des développeurs qui vont un peu tricher sur la rédaction des tests pour que ça fasse 80%. Donc la statistique, en elle-même, il faut vraiment la rendre pertinente et c'est un travail de longue haleine. Ça demande de l'industrialisation, de l'outillage et pour certaines entreprises que j'ai accompagnées, juste mettre en place des KPI pertinentes, ça pouvait prendre 5 mois pour 2 KPI.
- Speaker #2
J'ai une question là-dessus, c'est que souvent, au lieu de mettre des objectifs chiffrés comme ... Comme indicateur, une tendance demandée aux gens en leur expliquant, on voudrait que ça s'améliore. Parce que l'agilité, c'est l'amélioration continue. Qu'est-ce que tu penses de ça ?
- Speaker #1
Je pense que c'est une très bonne approche. Si on était sur du trends, vraiment expliquant, on est vraiment sur de la tendance A et pas un objectif en soi à atteindre, ça déjà, ça permettrait de lever un peu le poids de la chose. Mais malheureusement, ça revient au discours qui va avec l'accompagnement, qui va auprès des développeurs, qui n'est pas fait parce que, j'ai envie de dire, C'est un peu mésestimé, je pense, au moins dans les entreprises françaises que j'ai observées. On ne va pas dire qu'il y a quelqu'un qui va être dédié à ça et le faire proprement dans l'état de l'art, avec des règles bien comme il faut. C'est ça qui pêche un peu. Mais la tendance, le trends, c'est super intéressant. On pourrait dire qu'on voudrait aller autour de 80%, mais on se donne une marge avec une marge d'erreur. Ça, ce serait déjà plus cool.
- Speaker #0
Du coup, je suis dit dev. Je commence par quoi ? C'est quoi mon premier pas, mon premier step ?
- Speaker #1
Très bonne question. C'est la question d'ailleurs que j'ai eue après le truc. C'est compliqué parce qu'on peut se retrouver à... Est-ce qu'on dit la vérité à l'équipe ou pas ? Est-ce qu'on dit qu'on va avoir des KPI à peu durer ou pas ? Il y a un peu cette envie de protéger l'équipe versus la transparence. C'est dur. Je pense qu'il faut se mettre autour d'une table et en parler, amener ça tranquillement, et montrer qu'on n'est pas obligé de se mettre la pression. Récolter la voix des équipes. Et derrière, c'est surtout... Aujourd'hui, il faut prendre conscience que le manager, il veut faire tourner son système. Il a besoin de challenger, c'est son rôle. Et il a besoin d'aide aussi. C'est-à-dire qu'en tant que leader, je te dirais déjà, va vers ton manager. Va le manager. Ça fait partie de Harvard Business Review. Ils préconisent justement d'aller manager les managers parce que ça crée une confiance, ça crée de l'aide, du partenariat et ça permet d'avoir des mandats différents. Ça, c'est la première chose. Donc, ne pas avoir peur. On n'est pas sur un côté très... Je suis irrationnellement au-dessus de toi, donc tu écoutes ce que je te dis. Il faut créer ce lien avec le manager, c'est la première chose. Et après, avec l'équipe, je pense qu'il faut être transparent, mais sans effrayer non plus. C'est-à-dire qu'il faut être intelligent de la communication. Il faut que ce soit une communication qui soit sans déguiser la pensée, mais dans un esprit d'avancée, de changement. Et c'est inévitable de changer dans une entreprise. Aujourd'hui, la concurrence est très, très dure, les marchés sont tendus, etc. Donc, la performance, c'est clé. Maintenant, pour l'amener, il ne faut pas effrayer, il ne faut pas faire peur. Donc, voilà le rôle du leader que je trouve très dur. Parce qu'aujourd'hui, on forme beaucoup les managers, mais aujourd'hui, est-ce qu'il existe vraiment des formations de leaders ? Je ne suis pas persuadé. On devient leader, on apprend leader, mais dans la souffrance.
- Speaker #0
Du coup, j'aimerais bien des exemples. Est-ce que tu peux me donner un exemple d'une mauvaise KPI et un exemple d'une bonne KPI ?
- Speaker #1
Je crois qu'il n'y a pas de bon ou de mauvais KPI. Je crois avant tout que c'est ça.
- Speaker #0
C'est une histoire de valeur.
- Speaker #1
Non, blague à part. Non, mais blague à part, il n'y a pas de bon ou de mauvais KPI. Non, si. La KPI qui est imposée. Le KPI qui est imposé, en général, c'est un peu douloureux pour les équipes. Ils n'ont rien demandé, on leur demande ça, c'est peut-être pas atteignable et c'est vraiment dur. Moi, ce que j'aime bien, et en me parlant de plus en plus avec d'autres experts, c'est que c'est l'équipe qui choisit ses métriques ou ses KPI. Et là, on est vraiment sur un autre angle. C'est-à-dire qu'on va dire, c'est vous qui savez comment mettre en valeur ce que vous faites. Ce n'est pas un manager ou un directeur qui est loin du terrain. Et derrière, qu'est-ce que vous proposez pour montrer qu'on est performant et que ça peut s'accorder avec la stratégie de l'entreprise ? Et je pense qu'on y gagnerait parce que de remonter ça, ces données du terrain, et petit à petit de combiner avec ce qui a été demandé par la direction, on pourrait voir qu'est-ce qui en accroche, qu'est-ce qui est... cohérents qu'est-ce qui ne l'est pas. Et je pense que c'est la meilleure technique. Et c'est là où le middle management ou d'autres strates managériales doivent être importantes parce qu'eux, ils vont devoir avoir ce travail de concilier le top-down avec ce qui arrive au niveau équipe. Et donc pour moi, si je devais faire un choix, je dirais aujourd'hui qu'un bon KPI, c'est les KPIs qui ont été écrites, définies et mises en place par les équipes.
- Speaker #0
La difficulté que je vois, c'est souvent bien le comprendre le KPI. C'est-à-dire réussir à l'expliquer. Ça reste technique. Un bon KPI reste très technique quand même.
- Speaker #1
Il peut,
- Speaker #0
oui. Et tu peux avoir, à un moment donné, au niveau du management, des difficultés à comprendre vraiment ce KPI techniquement. Est-ce que si tu as un bon KPI qui est technique, est-ce que tu le gardes et tu passes du temps à essayer d'expliquer, même si c'est hyper compliqué, ou de temps en temps, un KPI un peu moins technique, mais vachement clair pour le management et peut-être meilleur ? Comment tu... Comment tu fais ton choix par rapport à justement ça ?
- Speaker #1
Très dur, c'est très dur. Aujourd'hui, je constate un truc dans les organisations, c'est que le temps d'attention et d'écoute des directeurs de managers est relativement réduit. C'est pas leur faute, ils enchaînent des réunions, ils enchaînent des sujets, voilà. Et donc, quand je vais être face à un CTO, je vais avoir 15 minutes. Et quand je vais être face à un manager, je vais en avoir 20, 30. Et donc, je suis obligé de faire un travail de vulgarisation, et donc quand je ne dois pas donner une définition d'un KPI, je suis obligé d'être bref et peu synthétique. Et donc, très synthétique pardon et donc ce qui est compliqué c'est que on va perdre de l'information et c'est pas grave parce qu'eux leur but c'est de savoir à quoi ça aide à faire tourner le système et après au niveau équipe là par contre je suis obligé d'entrer dans des définitions très claires j'en parlais tout à l'heure la couverture de code on peut encore rentrer dans ce que c'est une couverture de code dans une équipe est-ce que c'est le nombre de lignes est-ce que c'est le nombre de caractères qu'on veut mesurer est-ce que c'est des parties critiques etc c'est vraiment c'est contextuel oui c'est ça Donc aujourd'hui, il faut les rendre clairs. Et après, il faut avoir cette clarté en fonction des personnes à qui on s'adresse. C'est-à-dire que ce que je vais présenter à une équipe de dev ne sera pas aussi détaillé et technique qu'un manager. Par contre, à chacune des personnes, ils auront la finalité et le pourquoi, le sens, la création de sens. Et sur ça, la création de sens, il y a plein d'orateurs et d'oratrices qui ont déjà parlé de ce sujet. Et sur le sujet KPI, je crois que c'est très négligé et c'est ce qui apporterait vraiment une énorme valeur dans les entreprises pour créer une dynamique et ça c'est du retour d'expérience dans des organisations que je ne peux pas citer il y avait les Dorametrics qui ont été imposés Dorametrics c'est très mainstream en ce moment imposé aux équipes et les équipes avaient des tâches à faire sur des outils pour mesurer ces fameuses KPI ils disaient je ne comprends pas l'intérêt de faire ça Et donc, en fait, on s'est posé autour d'une table, on a pris deux heures, et pendant deux heures, j'ai expliqué ce que c'était, d'où elles étaient issues, comment elles s'en aient, à quoi elles servaient, comment on pouvait les impacter en tant que technicien, ingénieur, chef de projet, ce qu'on voulait, et ça a créé du sens. Et là, j'ai eu un verbatim, je m'en souviendrai toute ma vie, qui m'a dit « Ah, mais je comprends enfin ce que je fais » . Et donc, en fait, je ne dis pas que ça a révolutionné sa vie, mais au moins, sa vie professionnelle, mais au moins, ça a créé quelque chose en lui et ça a permis de débloquer des choses et d'être moins contre le système qu'on lui impose. D'où l'importance d'accompagner et de créer du sens au niveau des équipes. Parce que sans eux, ton KPI, il ne vaudra rien. C'est juste des compteurs. Et comme je disais, des compteurs sans moteur, ça ne vaut pas grand-chose.
- Speaker #2
C'est sûr que ce n'est pas en 2020 qu'on a... on a commencé à faire monter du ciel et ces 4 capillaires de Diodora ils sont sortis du ciel ils sont tombés du ciel mais il y a eu des bouquins avant etc et c'est juste la concentration au fait de plein de choses qu'on faisait qu'on faisait avant avec le nombre de pannes etc et comment t'as réussi cette explication avec l'équipe à leur faire comprendre tu as un exemple par rapport je sais pas au nombre de livraisons la fréquence de livraison par exemple des fois moi je sais que quand j'explique qu'il faudrait livrer plus souvent C'est une des valeurs agiles où il faut limiter l'impact, avoir du code le plus petit possible pour éviter des pannes et tout. Comment tu as réussi à convaincre les équipes sur ça ?
- Speaker #1
Alors, c'est très drôle parce que j'ai pas réussi à les convaincre. J'ai juste montré un autre angle et après, ça a créé du sens en fonction des personnes. Là, on est vraiment dans une stratégie d'adoption. Donc, si vous connaissez le Crossing the Chasm de Geoffrey Moore avec la loi d'adoption, on est vraiment sur une adoption. Donc, je savais qu'il y a des gens qui seraient contre, des gens pour, des gens motivés. Je me disais... je voulais faire émerger les innovateurs et les adopteurs de l'adoption. Et pour ça, j'ai choisi de vulgariser la compréhension du livre, notamment Accelerate, d'où sont issus, dont on parle des quatre premières Dorametrics au début. Et si je prends la fréquence de déploiement, en fait, je n'en ai pas parlé tout de suite. Il ne faut pas oublier que dans ce livre, il y a 257 pages. Il n'y a que deux pages sur les Dorametrics. Et on en a gardé que ces deux pages aujourd'hui au niveau réseau social, ce qui est bien dommage. et pourtant les 255 autres pages sont très intéressantes. Et parmi cela, il y a le fameux, ce qu'on appelle le core model, c'est le modèle d'étude de... Comment dire ? Ils ont pris un modèle avec des compétences DevOps, Lean, Agile, et ils ont essayé de prouver via une investigation à l'échelle que ça avait un impact, notamment sur la fréquence de déploiement. Et ce core model, moi, est représenté en forme de schéma à jouer. Et des personnes techniques, je leur ai dit, toi, en tant que personne qui est QA, si tu te lances dans les tests automatisés, tu peux, et je dis bien tu peux, c'est une probabilité, avoir un impact sur ta fréquence de déploiement. Et on allait découper cette théorie en pratique sur le terrain. Ce qui est utilisé notamment, c'est le value stream mapping pour faire ça, cartographier chaque étape, chaque step, et dire pourquoi tu peux avoir un impact. Et après, on prend une autre pratique DevOps qui est mise en évidence, une pratique Lean Agile, etc. Et la combinaison, la synergie de toutes fait comprendre que oui, effectivement, si on met ça en place et dans ton contexte, avec ce point de détail, ce point de détail, ça peut avoir un impact sur ta fréquence de déploiement. Mais à la limite, la fréquence de déploiement, ce qu'ils s'aperçoivent, c'est qu'on s'en fiche. En fait, c'est juste une conséquence de la mise en action et d'une mise en action collective. C'est beau, hein ?
- Speaker #0
J'interromps cet épisode 30 secondes pour vous présenter Exambrica, l'entreprise derrière ce podcast. Votre projet est-il tournant rond ? Les silos se multiplient et votre feuille de route reste floue ? Il est temps de passer à l'action. Chez Exambrica, nous sommes convaincus que votre projet a besoin de deux choses pour réussir. La première est d'adopter une approche produit. La deuxième est d'avoir un binôme tech et produit aux commandes. Notre secret, des équipes ou architectes, développeurs et designers collaborent en parfaite symbiose avec le product manager, transformant chaque contrainte technique en levier pour votre business. Que ce soit pour lancer un nouveau produit digital, refondre une application existante ou moderniser votre IT, contactez Exambrica et confrétisons ensemble vos projets les plus ambitieux. Allez, on y retourne ! Il y a d'autres points qui échappent à tout le monde dans Accelerate ?
- Speaker #1
Oui. La première, c'est que tout le monde est focus sur le résultat. Et en fait, on est plutôt sur une approche un peu plus systémique. C'est-à-dire qu'il faut faire émerger les choses plutôt que se dire qu'il va y avoir ça à la fin. Donc, on n'est pas sur du output, mais sur outcomes. Et en fait, les outcomes, c'est que ça tend vers... Cette notion de tendance, on la retrouve ici. C'est qu'à force d'utiliser un peu tous les jours, amélioration continue, un peu tous les jours, À force, je peux, et je dis bien, je reste prudent, ce n'est pas de la causalité. On peut avoir un impact sur la suite et créer cette outcomes, par exemple, une meilleure livraison continue qui devient plus durable, sécure et rapide, par exemple. Mais ce qui est intéressant aussi avec Accelerate, ça peut être aussi l'amélioration de la qualité, ou encore, et ça, ils l'ont démontré, le bien-être au travail. Donc, ça peut être aussi sur comment l'équipe perçoit les choses, est-ce qu'elles se sentent bien, et du coup, ces trois points... identifie la notion de performance. La performance n'est pas que business dans Accelerate, c'est aussi le bien-être au travail. Il y a quand même 7 outcomes orientés bien-être au travail, 2 business et 2 ou 3 orientés qualité. C'est énormément oublié aujourd'hui ça. Aujourd'hui les entreprises s'en focus sur le résultat, le net. Je peux comprendre aussi pourquoi c'est concurrentiel, il faut survivre, c'est très compliqué, j'entends, ce n'est pas une critique. Mais derrière il y a d'autres choses aussi à capter. Parce que derrière, on sait que le bien-être au travail va être aussi le facteur. La satisfaction au travail, c'est le facteur majeur qui impacte la performance de votre organe. Ça, ça a été prouvé. Et donc derrière, c'est cette tendance, elle est à comprendre en temps vert. Il ne faut pas s'attendre à des résultats sur trois mois, six mois. Donc la vision court terme, il faut avoir une vision plutôt moyen, long terme, deux ans, cinq ans. De toute façon, on est sur des changements culturels, une transformation. Donc forcément... Si on reprend les écrits de Cotter, on va être plutôt sur du 5 ans au moins, minimum. Voilà, donc ce que je dirais, c'est qu'il faut prendre en compte aussi d'autres signaux, et notamment les signaux faibles, qui sont très oubliés aussi dans les organisations. Je disais tout à l'heure, pour rigoler, il n'y a pas que les chiffres, il y a les lettres, les chiffres et les lettres, pour faire souffrir les gens. Mais le moindre verbatim est très important. Je l'ai vu, ça je m'en souviendrai, c'était extraordinaire, on était en train de parler de découpage des user stories. Et un verbatim qui est arrivé, il me dit, moi, je n'ai pas besoin de quantifier. Moi, j'ai juste besoin de me dire dans ma tête, je vois déjà comment terminer cette tâche. Si j'imagine dans ma tête comment terminer cette tâche, en fait, je sais qu'en fait, c'était fini et ça rentre dans le sprint et c'est fini. Et donc, en fait, on était sur un autre modèle qu'on ne peut pas appliquer, c'est propre à chaque développeur et développeuse, mais qui était intéressant. Les verbatims, c'est très souvent oublié. Il faut capter aussi les signaux faibles. Et c'est marqué dans l'accélérate. tellement de choses qui sont... Les bases de la psychométrie sont aussi dans Accelerate. Aujourd'hui, je vois beaucoup de formulaires qui sont créés from scratch par des gens de bonne volonté, mais sans prendre les règles de la psychométrie. Donc, ça va dévier, avoir des données qui sont biaisées.
- Speaker #0
Détail un peu plus, les règles de la psychométrie.
- Speaker #1
Oui, il y a trois règles dans la psychométrie. Ma référence, c'est Albert Moukébert, qui en parle. C'est un docteur en neurosciences. Et sur la psychométrie, tu as trois règles. La première, mon test mesure ce que je veux tester. Alors c'est bizarre, on se dit mais pourquoi un dissent ? Mais en fait c'est très facile de se louper. Je te donne un exemple, c'est celui du talk. J'ai vu une enquête faite à des internes pour connaître, mesurer la satisfaction au travail des internes. Première question, êtes-vous satisfait dans votre organisation ? Oui ou non ? Est-ce que vous recommanderiez votre organisation à un ami ? Oui ou non ? Eh bien, tu n'as pas de garantie d'anonymat, tu sais que les données sont traitées par la directrice RH qui est amie avec d'autres directeurs. que ces directeurs ont un pouvoir d'influence sur tes managers. Donc, en gros, si tu as envie d'être tranquille, de ne pas avoir de problème, de te dire que tu vas avoir ton salaire, etc., une augmentation de salaire, pardon, tu as tendance à répondre oui. Et donc, ton test ne mesure pas ce que tu voulais tester. C'est la première règle. La deuxième règle, c'est que ton outil de mesure doit être fiable. Et la fiabilité, c'est quoi ? C'est que tu n'as pas ou peu d'interprétation. L'exemple que je prends, c'est est-ce que la couverture de code est un bon indicateur de notre équipe ? Le mot bon indicateur, on est trois, on va avoir peut-être trois définitions différentes. Multi-interprétation, c'est fichier. Donc il faut un petit peu rentrer un peu plus dans la précision. Et ça, ce n'est pas forcément simple. Ça peut demander beaucoup de travail, de clarté, de définition, de précision. Et la dernière règle, c'est d'avoir un cadre théorique scientifique minimum. Ici, aujourd'hui, si je parle des échelles de Likert, c'est qu'une échelle de Likert, au lieu de dire oui ou non, vous allez mettre un peu de granularité. Donc ça va faire tout à fait d'accord, plutôt d'accord. pas du tout d'accord on a envoyé cette granularité elle est très bien l'échelle de l'hiker pour démarrer sur des formulaires t'as pas trop de neutres au milieu en fait moi j'aime pas le neutre ah mais c'est normal alors sur l'échelle de l'hiker t'en as parce qu'en fait tu vas avoir des à l'état de l'art c'est soit 5 réponses de granularité 7 ou 9 et si t'en as 5 par exemple au milieu c'est je suis ni d'accord ni en désaccord moi j'aime pas parce que j'aime bien le positionnement ouais moi aussi donc moi je passe sur des échelles de 6 j'aime bien 6 ça suffit ouais d'accord
- Speaker #0
J'étais très 4 notes par le passé.
- Speaker #1
Oui, 4.
- Speaker #0
Ceux qui me connaissent savent pourquoi je parle de 4 notes. C'est un truc...
- Speaker #1
Je suis passé à 6 et je suis très content de la précision sur laquelle j'arrive. Oui,
- Speaker #0
peut-être. 3 plutôt en dessous d'un moyenne et 3 au-dessus d'un moyenne.
- Speaker #1
Oui. Je crois que j'ai démarré à 6 pour avoir plus de précision et j'en suis très content. Parce que... Alors, pourquoi ? Effectivement, dans l'organisation où j'étais. J'ai mis le formulaire basé sur l'échelle de Likert. Alors à l'époque, les règles de la psychométrie, je ne les connaissais pas aussi bien. Donc il y avait encore des biais possibles sur mes formulaires. C'était il y a deux, trois ans. J'ai récolté, là où c'est très fort, c'est que je suis assez content de ça. Je ne l'ai pas fait tout seul, on était un groupe. On a récolté les données à l'échelle. C'est-à-dire que je n'ai pas fait une équipe. C'est qu'on avait fait les 11 équipes qui étaient dans le département. Et on a récolté, je ne sais pas, tu avais en moyenne 5 à 10 personnes par équipe. Tu avais des grosses équipes, des plus petites. Et donc ça fait un volume extraordinaire de données, plus des verbatims, etc. Et donc en fait, avec l'échelle de 6, on avait des pourcentages qui commençaient à être intéressants et précis. Et donc à l'échelle, quand on donnait ça au first line manager, lui il se régalait parce qu'il avait une donnée hyper intéressante. Il avait des arguments pour aller auprès de son responsable, son hiérarchique, en disant « Bon, c'est pas moi qui le dis, mais c'est juste 70% du département. » Et en fait, l'effet de masse l'aide à convaincre, etc. à mettre en évidence des vrais problèmes.
- Speaker #0
Et puis passer de 4 à 6, ça te permet de ne pas forcément avoir besoin de dizaines de milliers de résultats pour avoir quelque chose qui est probant. Sinon, à 4, il faut avoir beaucoup plus de valeur si tu veux avoir une vraie tendance, une vraie moyenne.
- Speaker #1
C'est plus dur. Non,
- Speaker #0
c'est intéressant. Imagine, je veux mettre en place ça dans mon organisation. C'est-à-dire, en gros, commencer à avoir des KPIs qui ont du sens et commencer à amener ça, en fait.
- Speaker #1
Quand tu dis ça, tu parles de quoi ?
- Speaker #0
Justement, à la limite, souvent, ça part d'une demande top-down, à l'origine. Et l'idée, c'est de réagir pour dire, ok, je comprends la demande, mais on va l'accompagner, on va essayer de faire quelque chose mieux. Tu déploies... Ma question est plus en termes de déploiement. Déploiement au sens large. Tu mettrais plutôt en place d'abord dans une équipe pour essayer de voir des résultats ou des outcomes, idéalement. et de commencer à réfléchir après comment tu généralises ou est-ce que tu généralises un premier level à tout le monde et après tu en as certains qui vont aller plus loin et c'est eux qui vont tirer. Cette transformation n'est jamais facile. Tout est transformé un peu de ce type-là.
- Speaker #1
C'est très clair. Si on a des KPI qui font sens et que derrière j'ai le mandat de faire cette approche, je vais avoir deux stratégies. La stratégie, Par défaut, le mot que j'ai le plus employé, c'est en suivant le pattern suivant. Pensez grand, démarrez petit pour apprendre vite. Donc ça, ça vient d'un bon bouquin qui est dans ma bibliothèque. Et ça, j'aime bien parce que penser grand, on le fait tous très facilement. Par contre, démarrer petit, on le fait moins. Et justement, travailler sur une petite unité, alors peut-être, on peut dire au niveau atomique, donc c'est une petite équipe où on peut faire le POC, qui est motivé, etc. Très souvent, comme ça, qu'on démarre avec les clients. on met en place des choses, on voit comment ça prend et petit à petit c'est toujours dans la stratégie de la courbe d'adoption eux ça va être un peu mes innovateurs mes early adopters le but c'est de commencer à mettre en place des outils avoir du retour d'expérience et ensuite c'est de présenter ça à l'échelle on voit qui est intéressé, donc là ça veut dire qu'on a notre early majority qui commence à s'exprimer, on capte des choses et après petit à petit on réplique le modèle ça c'est la première chose, après si on a une coalition directrice très soudée, très forte On peut tenter de manière plus parallèle ce genre d'initiative, si on est bien organisé. Très souvent, je ne le vois pas, mais on n'a pas forcément accès directement tout le temps à toute la direction, mais juste à certaines personnes qui voient d'une autre manière les choses.
- Speaker #0
Génial. Est-ce que tu as des ressources à partager ?
- Speaker #1
Des ressources ?
- Speaker #0
Ce que tu veux. Bouquins, livres, vidéos, autres. forcément ta conf, mais est-ce que tu as d'autres ressources pour si on veut creuser ce sujet ?
- Speaker #1
Ouais, bien sûr. Moi, évidemment, je dirais de lire les 255 pages autres de Accelerate et de s'y attarder. Non, mais c'est vraiment parce que c'est une énorme souffrance dans les équipes en ce moment, je le vois énormément. On nous impose ça, on ne comprend pas, ça ne sert pas, ça ne sert à rien. Je crois que si on veut être dans une stratégie de rétention, une stratégie où on veut vraiment qu'il y ait de la performance qui s'installe, le temps que l'équipe se forme, qu'elle devienne nature entre personnes de l'équipe, je pense qu'il faut déjà travailler sur ça et je pense qu'une bonne compréhension de ce livre est la première démarche parce que comme c'est mainstream, Accelerate il faut absolument comprendre un petit peu l'essence de ça et pourquoi ce n'est donné du sens. Donc ça c'est la première référence, je sais qu'on n'est pas beaucoup on a une vulgarisation et j'ai fait un talk dessus justement à présent à la découverte d'Accelerate que j'ai fait au Devox qui donne une première couche C'est vulgarisé, mais ça donne la première couche pour comprendre un petit peu. Ça résume un peu l'atelier que j'avais fait avec des équipes chez les clients. Et après, je dirais, mais il faut lire, lire, lire. Plein de choses différentes. C'est ça qui permet de diversifier notre compréhension de notre culture. Je déplore un truc, et toujours, je ne blâme pas les managers, mais ils n'ont pas le temps de cultiver, de voir ce qui se passe de nouveau. Ils n'ont pas le temps. c'est dommage parce que les engineering managers commencent on voit qu'ils vont plus loin du team topology on va parler de unfix, on va parler d'accelerate, on va parler de flow engineering, l'activité qui cartonne en ce moment, mais derrière on a une strat managériale qui pour moi n'a pas le temps de travailler sur des visions systémiques une compréhension systémique pour bien appliquer ce qu'ils veulent dans leur système, on dit qu'ils managent un système mais ils n'ont pas de connaissances systémiques c'est quand même dommage.
- Speaker #0
Génial Génial. Merci Geoffrey.
- Speaker #1
Avec plaisir. Merci à vous.
- Speaker #0
Je vous mets le lien en description de la conférence de Geoffrey. Abonnez-vous à la newsletter Empare en Prod sur le site empare-en-prod.fr pour découvrir les nouveaux épisodes et des ressources tech et produits sympas. Si vous voulez plus de contenu, allez voir l'épisode 10 avec Dimitri Bali sur le Continuous Delivery pour découvrir ou mieux comprendre le flux tiré. Allez, ciao !
