Engineering Empathy: Deepki’s Blueprint for Collective Intelligence
Ceci est la retranscription (partielle) d’un podcast auquel j’avais participé. Avec les outils actuels j’ai pu extraire ce que j’y racontais au sujet des équipes de développement.
Cela date de 2019 et c’est du langage parlé.
L’importance de l’intelligence collective
Une des choses qui m’a le plus marqué dans ma carrière de développeur passée, c’est à quel point l’intelligence collective a des effets vraiment extraordinaires sur la productivité, sur la confiance en soi, sur comment on apprend et comment on progresse. Je pense qu’à titre personnel, je ne serais pas le développeur que je suis devenu sans cette démarche en équipe.
Quand je suis rentré chez Deepki, un des sujets qui m’intéressait beaucoup, c’était comment mettre en place des équipes avec un environnement idéal pour apprendre, progresser et collaborer. Pour nous, les mots-clés quand on recrute dans nos équipes de développement, c’est : comment est-ce qu’on se met au service de l’intelligence collective au sein de nos équipes ?
Organisation des équipes : Autonomie et Responsabilité
Nos équipes sont autonomes, auto-organisées et responsables.
- Auto-organisées, cela signifie que les équipes choisissent leur mode de fonctionnement. Il y en a qui sont en Scrum de 2 semaines, il y en a qui sont en Scrumban (en flux tiré), cela correspond plus à leur mode de fonctionnement.
- Autonomes, cela veut dire qu’au sein de l’équipe, toutes les compétences sont réunies. Chez Deepki, il n’y a pas d’équipe séparée de type Prod. L’équipe de dev est là au design des écrans et des fonctionnalités, et aussi en cas de problème en production pour le déploiement. C’est vraiment très important pour qu’il n’y ait pas ce mur qu’on constate parfois entre le développement et la production. Ici, chacun possède la responsabilité d’aller au bout de la production et du service rendu.
- C’est aussi pour cela qu’on dit que les équipes sont responsables. Elles s’engagent d’une part à respecter ce qu’elles ont dit qu’elles feraient (sur ce sprint-là, on fait X points, l’équipe est responsable de l’objectif), mais elles sont également responsables de la tenue en production et de remonter les problèmes. C’est quelque chose qui me tient à cœur.
L’agilité et la culture de l’apprentissage
On entend surtout parler du terme “agilité”. C’est un terme très utilisé, très galvaudé. À titre personnel, cela fait 10 ans que je travaille dans l’agilité, j’ai connu l’émergence de l’Extreme Programming sur Paris. Ça a beaucoup changé depuis, c’est devenu un mot vendeur, donc on essaie de ne pas trop l’utiliser. Cela dit, c’est vraiment cette démarche d’apprentissage permanent, d’auto-évaluation, de remise en question permanente que j’essaie de mettre en place et de déployer ici.
Cela a des effets positifs : on a pour l’instant peu de turnover par rapport à d’autres entreprises. Les gens qui collaborent au sein de l’équipe sont heureux d’être là et restent. On sait qu’un développeur va avoir tendance à bouger tous les 2-3 ans ; ici, on arrive à limiter cela. Les gens prennent des responsabilités et c’est très confortable en tant que CTO d’avoir confiance à ce point-là.
Il y a quelques semaines, j’étais en vacances très loin et on a eu un incident. Tout s’est bien passé. Les gens ont réagi comme il faut, ils ont mis en place les actions correctives et les développements futurs à faire pour que ça ne se reproduise pas. Tous ces réflexes, qui peuvent prendre du temps à acquérir, sont là grâce à la culture des équipes. C’est une belle réussite de Deepki.
L’humain au centre du développement
Je trouve que cet aspect humain, remettre l’humain au centre du développement, c’est quelque chose qu’on a parfois oublié dans d’autres entreprises. On développe un logiciel pour des gens qui vont s’en servir et ce sont des êtres humains qui le font. J’ai eu des exemples dans ma carrière passée où on oubliait un peu les deux côtés : on faisait du logiciel pour faire du logiciel et il fallait fouetter les équipes de développement pour que ça marche. Je ne suis pas d’accord avec cette façon de procéder. J’avais vraiment à cœur en venant chez Deepki d’établir une culture du développement et de la prise de responsabilité pour qu’on puisse durer. C’est un aspect qu’on présente à chacun de nos futurs employés et qui reste une réalité aujourd’hui. Quand je suis arrivé, Deepki s’est rendu compte qu’ils n’étaient pas qu’une boîte de conseil, mais que ça devenait une boîte de software, ils ont donc recruté quelqu’un dont c’était le métier.
Mais il y avait déjà dans l’ADN de Deepki, par les fondateurs Vincent Bryant et Emmanuel Blanchet, cette envie d’avoir une entreprise dans laquelle il fait bon vivre. Quand on leur demande individuellement quel sera leur critère de réussite, une des premières choses qui remonte c’est : “Est-ce que les gens sont heureux de travailler chez nous ?”. C’est une des premières choses, avant même l’impact écologique.
Diversité et pérennité de la culture
Pour moi, établir une culture de développement, c’est faire en sorte que lorsque je pars, cette culture soit toujours là, qu’elle ne tienne pas qu’à ma tête. Désormais, ça l’est, et je suis assez confiant sur l’avenir. Il y a un effet intéressant : on a tendance à recruter des gens qui ont une forte appétence pour ces sujets de communication et de travail collectif.
Cela évite d’autres biais et nous oblige à nous diversifier. On a la chance d’avoir 30 % de femmes dans nos équipes de dev. Je n’ai jamais travaillé avec autant de femmes en développement. On a aussi une grande diversité de profils et de pays. Dans tout Deepki, il y a une culture de s’ouvrir à la différence et aux autres. C’est un des gros points positifs, outre notre projet auquel on croit : cette culture de l’autre, du progrès et de l’autonomie.
Le rôle du leader : “Lead by example” et droit à l’erreur
La grande question… Déjà, il faut avoir envie de le faire, il faut l’avoir en soi. Ce que j’ai voulu faire, c’est le “lead by example” : être un leader plutôt qu’un chef. Par l’exemple de son comportement face aux problèmes et aux défis du quotidien. Il faut donner tous les outils et très vite dire : “Je suis le CTO mais ce n’est pas moi qui tranche. Si vous êtes quatre contre moi d’un avis opposé, c’est vous qui avez raison.” Mon avis ne sert qu’à trancher quand il y a une égalité ou sur un sujet de sécurité très important.
Ce qui est important, c’est d’avoir une position d’humilité, d’être là en support et de laisser la place aux gens pour s’exprimer et se tromper. Le plus difficile, c’est de laisser l’équipe se tromper et de la voir aller un petit peu dans le mur. C’est très difficile de ne pas intervenir, mais je ne vois pas comment on apprendrait sans se tromper. Le corollaire, c’est de ne pas avoir une culture du reproche. Il faut que les gens fassent des erreurs pour apprendre et rebondir. Si on est dans une culture du blâme, on ne va pas y arriver. Par contre, si on dit “OK, on a fait une erreur, comment peut-on apprendre et rebondir ?”, cette culture va s’infuser naturellement.
Réactions