Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Arnaud le maire, Arnaud bonjour.
Hello !
Ravie de t'avoir sur le podcast, on avait parlé en fait de la performance d'équipe et je te proposais ça comme sujet.
Et tu m'as sorti une étude que j'ai trouvée assez stupéfiante de la part de Google sur quelles étaient les critères qui faisaient qu'une équipe était vraiment performante.
Est-ce que tu peux nous en dire plus ?
Oui oui, en fait je pense que c'est une étude, Arnaud qui commence à être un petit peu connu mais malgré tout pas assez à mon sens.
Et en fait c'est une étude qui a fait Google parce qu'il voulait se poser la question de pourquoi, en fait, qu'est-ce qui fait qu'une équipe réussit mieux qu'une autre ?
Pour eux c'est quand même un élément important vu la taille de l'entreprise.
Et là en fait, où ils s'attendaient à avoir une corrélation assez évidente entre l'expérience de quelqu'un sur le niveau d'étude.
Et donc au niveau d'une équipe, le niveau d'étude ou l'expérience moyenne des développeurs et la performance de cette équipe,
ils se sont rendus compte que cette corrélation n'était pas du tout présente, ce qui est en soi déjà un premier résultat assez étonnant.
Mais surtout, ils se sont rendus compte que le facteur avec lequel ils avaient le plus de corrélation, c'était un élément qu'ils appelaient la sécurité psychologique.
C'est-à-dire en fait, le fait que les gens au sein d'une équipe se sentent à l'aise et libres de pouvoir dire « là je ne sais pas faire quelque chose, là je suis dépassé »
parce que l'on me demande de faire « là j'ai besoin de poser une question, j'ai besoin de l'aide de mes collègues ».
C'était en fait l'élément principal qui allait faire une équipe performance et pas du tout des éléments qu'on aurait pu penser plus évident,
comme le niveau d'études, comme le style de management, comme la structuration d'équipe.
Et donc en ça effectivement, je trouve que c'est malheureusement pas assez mis en avant parce que c'est un enseignement que je trouve quand même très très intéressant.
Ah c'est juste un... enfin quand tu prends un tout petit peu de recul, d'abord quand j'ai vu quand tu m'as parlé de cette étude, tu allais jeter un œil.
Le premier truc que je me suis dit « tiens c'est cool, dans mon travail avec Artisan Developer, je ne suis pas complètement à côté de la plaque ».
Et puis juste après, je me suis dit « c'est quand même dingue, comme ça nous ramène à l'humain ».
J'ai trouvé ça génial parce que, tu vois, j'entends souvent dans les entreprises ce rêve un peu de « factories », de « digital factories »
où l'usine représente qu'il y a de plus un personnel, de plus inhumain au sens où il n'y a plus de lien,
les gens sont reliés par un enchaînement de tâches et là cette étude vient juste de nous dire « non, non, mais en fait ce qui est essentiel,
c'est l'interaction qui est entre les humains qui sont derrière ».
En fait, moi j'aime bien utiliser le terme « usine logicielle » quand on parle de vraiment fabriquer, à partir du code source, des binaire,
parce que là effectivement, on est en phase d'une usine, après, sur la partie effectivement « équipe », « gestion des équipes », etc.
Et effectivement là je pense que c'est une grosse grosse erreur.
Mais c'est quelque chose que l'on retrouve pas mal, notamment en anglais, on a un peu cette question du « software developer as a commodity ».
En gros, je peux remplacer n'importe quel développeur Java par un autre développeur Java,
et ça effectivement c'est cette vision très ressource qui rend les membres d'une équipe interchangable,
parce qu'on a besoin de trois développeurs Java, deux développeurs TypeScript, un DevOps et on a notre équipe.
Alors qu'on se rend bien compte, et n'importe qui qui a un petit peu d'expérience, que dans la réalité ça marche pas du tout comme ça.
On a souvent un petit peu cette idée que j'aime beaucoup de dire,
une équipe elle est immutable, dans le sens que dès qu'on la modifie en ajoutant ou en supprimant ou en changeant un des membres de cette équipe,
ça n'est plus la même équipe. L'équipe n'est plus celle d'origine, et elle va devoir réapprendre en fait à fonctionner en tant qu'équipe.
Et je pense que c'est très important effectivement d'avoir vraiment cette idée que le développement logiciel, c'est avant tout un travail de groupe.
Enfin, dans la majorité des entreprises, maintenant ça l'est devenu.
C'est un travail qu'on fait à plusieurs, c'est maintenant des dizaines, voire des centaines de personnes qui collaborent ensemble sur un objet technique.
Et en tant que telle, les premières problématiques que ça entraîne, ce sont des problématiques humaines avant d'être des problématiques techniques.
C'est-à-dire que les problématiques techniques peuvent être présentes, mais très souvent, c'est les problématiques humaines qui vont les amplifier,
ou au contraire qui vont permettre de passer outre ces problématiques techniques.
Et du coup, si on en revient à ça, comment est-ce que d'après toi on peut nourrir cette sécurité psychologique ?
C'est quoi les pratiques que tu as pu voir ? Qu'est-ce que tu conseillerais ?
Tu as un auditeur qui se dit « tiens, ça c'est vraiment important ».
Comment est-ce que je fais pour mettre un point d'attention là-dessus, pour améliorer ce point, pour même simplement faire un diagne,
de se dire « est-ce que je suis dans une équipe où c'est vraiment développé ou pas ? » tu crois ?
En fait, il y a...
Alors déjà, dans l'étude qu'on peut trouver sur le site, c'est Work with Google, ou quelque chose comme ça, le nom du site,
il donne justement quelques points.
Déjà, savoir si on est dans une équipe où il y a de la sécurité psychologique, ça se détecte assez facilement,
en gros, c'est de se dire « est-ce que je suis à l'aise pour indiquer que je ne suis pas à l'aise avec quelque chose ? »
Voilà.
C'est « est-ce que je n'ai pas peur des conséquences si je dis « ça, je ne sais pas le faire, j'ai besoin d'aide ».
Il y a plein plein malheureusement d'équipe où il y a des gens qui n'osent pas, en fait,
et donc ils vont prétendre que tout va bien et qu'ils vont s'enfoncer dans un développement qui va devenir douloureux pour eux,
en fait, parce que justement, ils ne se sentent pas à l'aise, ils ne se sentent pas en sécurité pour pouvoir juste dire « j'ai besoin d'aide ».
Donc ça, c'est vraiment le premier facteur pour savoir si on a cette sécurité psychologique,
c'est d'être capable, en fait, et d'avoir ce ressenti, que poser cette question, pouvoir dire « là, je dois avoir de l'aide de la part de mes collègues ».
Ça n'est pas quelque chose qui va être retenu contre la personne.
Qu'est-ce qui est de l'ordre ? Tu vois là, je me pose la question « qu'est-ce qui est de l'ordre de ce qui m'appartient, de ce qui est de l'ordre du groupe ».
Parce qu'il faut avoir travaillé un tout petit peu sur ses émotions et sa capacité ne serait ce qu'à identifier ça.
Tu peux arriver dans un endroit hyper bienveillant, qu'il acceptera très bien et ne quand même pas oser.
Tu vois, je me demande.
Alors justement, mais c'est là par contre où arrive la partie qui est de la responsabilité de l'équipe et aussi du management.
Parce que, bien sûr, ce n'est pas inné.
Et notamment, comme je disais, si quelqu'un arrive dans une équipe, ce n'est plus la même équipe.
Donc l'équipe doit réapprendre à avoir une sécurité psychologique.
Et ça passe notamment par les profils seniors, par les profils plumatures qui sont souvent des profils, on va dire, qui guident la conception ou le développement.
Et en fait, c'est à eux de montrer qu'ils ne sont pas des gens omnisciants, que ce ne sont pas des gens qui réussissent parfaitement du premier coup à développer une version sécurisée sans bug très performante.
Mais qu'eux aussi, ils ont des connaissances qui peuvent leur manquer, qu'eux aussi, ils peuvent avoir besoin d'aide, qu'eux aussi, il y a des moments où ils ont besoin du reste de l'équipe pour pouvoir avancer.
Et donc c'est vraiment, en fait, et là, c'est plus effectivement quelque chose qu'il faut réussir à mettre en place en tant que personne.
Si on est dans des postures de l'IDEV, notamment, c'est de réussir à dire au reste de l'équipe, au fait là, moi j'ai besoin d'aide.
Et de cette manière, montrer que c'est autorisé, en fait, dans l'équipe, en tant que rôle de l'IDEV, je montre que c'est possible et que c'est bien venu d'aller demander de l'aide au reste de l'équipe.
Tu vois, c'est drôle parce que je me dis, c'est un peu contre-intuitif, en fait, quelque part.
Ça serait facile de penser, tiens, je suis l'IDEV, on attend de moi d'être un peu exemplaire, de guider, de montrer le chemin.
Je me dois d'être parfait, irréprochable, de tout savoir.
Et en fait, ce que tu dis, c'est tout l'inverse. En fait, c'est en montrant ses failles, en acceptant, évidemment, un peu, ça part d'humanité, de...
Bah, je suis un humain comme les autres et il y a des trucs que je... Voilà, j'ai des limites aussi.
C'est en osant l'afficher, clairement, qu'on crée ce... qu'on envoie le message.
Bah ouais, c'est possible, en fait. Et c'est pas un problème.
En fait, c'est un petit peu ce que l'on qualifie d'égolesse programming.
Ne pas avoir son ego, en fait, qui vient, justement, polluer, en fait, sa pratique du développement.
Parce que très souvent, quand on se dit, je dois montrer que je suis le meilleur, etc., c'est des problématiques d'ego.
Et il faut vraiment réussir à les laisser au placard.
Pour moi, en fait, et j'en ai très rapidement parlé, je suis dans un article que j'avais écrit, ça plaît, ne mettez pas la poussière sur le tapis.
Mais en fait, c'est que, en tant que développeur, pour moi, ce qui fait un développeur mature dans sa pratique, c'est le fait qu'il sait qu'il ne sait pas.
Et qu'il est capable de demander de l'aide quand il ne sait pas.
Un développeur omniscient, ça n'existe pas.
Notre fil est tellement complexe.
Les applicatifs sur lesquels on travaille sont quand même très souvent d'une complexité assez conséquente.
Et donc, on ne peut pas demander à une personne d'être omnisciante sur l'ensemble de notre champ industriel et sur l'ensemble des applicatifs.
Donc, ça n'existe pas.
Un développeur qui est même extrêmement brillant avec énormément d'expérience, qui n'aurait jamais besoin d'aide.
Ça ne n'existe pas.
Donc, à partir de là, c'est juste réussir à expliciter et à être capable de dire, ok, là je sais que je ne sais pas.
Et là, je sais demander de l'aide quand je ne sais pas.
Et j'ai pas mon ego qui vient me dire, oh mon Dieu, qu'est-ce que vont penser mes collègues de moi, quoi.
Oui, écoute, c'est génial, je te propose que ce soit la conclusion.
Et je me rends compte que j'ai dérogé à la règle, je ne t'ai pas demandé de te présenter.
Alors, en guise de conclusion, est-ce que tu peux nous dire en 30 secondes ce que tu fais
et où est-ce que les auditeurs peuvent venir en savoir plus sur toi et ton travail ?
Alors, moi, je suis à la direction technique d'une boîte qui fait du logiciel pour la finance de marché,
qui s'appelle LGO.
On retrouve le site suelgeo.group.
Et derrière, j'ai aussi un blog sous l'ilo-basali.lobase.m, sur lequel on peut retrouver pas mal d'articles.
Et je pense que, d'ailleurs, je ferai un article sur cet épisode de podcast quand il sera publié.
C'est cool.
Eh bien, écoute Arnaud, merci.
Merci à toi.
Quant à toi, cher auditeur, j'espère que tu as apprécié ce podcast.
Si, c'est le cas, je pense que c'est typiquement l'exemple d'épisodes qui se partagent et qui s'écoutent en groupe.
Donc, si tu l'as écouté seul, je pense que c'est une occasion excellente de proposer une écoute à ton équipe.
Tu peux faire ça autour d'un café, autour d'un...
On ne peut faire ça autour de quoi ?
D'une tarte, d'un bon gâteau.
Et de partager cette écoute et de débriefer de ça.
Ce sera l'occasion de revisiter votre propre sécurité psychologique.
Et est-ce que vous vous sentez à l'aise pour dire quand les choses ne vont pas ?
Je te remercie, je te dis à bientôt.