Vivre dans une équipe tech sans chef·fe

Il y a quelques années, j’ai eu l’occasion d’enregistrer une interview réalisée par une plateforme de formation en ligne.

C’est avec cette plateforme que j’ai réalisé ma reconversion en tant que développeuse. Lors de ce tournage, je me souviens avoir dit qu’un jour, je serai lead-dev. Comme si cela pouvait prouver que j’avais réussi ma reconversion.

Et pourtant après quatre ans, je pense que je ne serai sûrement jamais lead-dev et que le titre ne m’apporterait pas grand-chose. Certains diront que ce poste permet d’avoir un meilleur salaire et d’autres qu’il permet de prendre une part de management intéressante.
On pourrait croire qu’un·e lead ne fera que les tâches qui lui semblent les plus intéressantes ou à haute valeur ajoutée.

Et si on pouvait avoir un salaire qui nous convient, être autonome dans nos tâches, choisir nos projets et choisir la direction que l’on souhaite prendre, tout en restant dev ? Sans avoir d’étiquette ? Et sans avoir de chef·fe pour nous guider, car qui de mieux que nous-même pour le faire ?

Aujourd’hui, j’ai trouvé une alternative au lead-dev et au système de management hiérarchique avec une méthode de gouvernance partagée et une organisation bien définie. Je trouve ma place dans une équipe sans chef·fe, sans lead-dev, sans manager.

J’ai l’intime conviction que nos métiers du numérique nous permettre de nous adapter très rapidement, d’être « agiles » comme on l’entend souvent. Nous avons pour habitude d’itérer, de changer, de remettre en question nos développements. Pour moi, il est donc beaucoup plus facile de mettre en place une gouvernance partagée dans une équipe de ce domaine.

Mais avant d’expliquer comment nous pouvons nous organiser seuls, sans manager, je vous propose deux définitions qui me semblent importantes pour débuter.

Chef·fe et équipe, définition

Chef·fe

Au sens le plus courant, c’est un dirigeant, la personne qui dirige un groupe de personnes, au-dessus de celles-ci en termes de pouvoir de décision et de responsabilité ; ou de façon plus imagée ce qui est supérieur qualitativement.¹

Équipe

Une équipe est un petit groupe d’individus partenaires dans un but commun.²

L’articulation autour de la raison d’être

En prenant au sens strict du terme le mot « équipe », je pense qu’il n’est pas nécessaire d’aller plus loin, non ? Nous avons une équipe tech sans chef·fe, car c’est une équipe.

Quelle nécessité donc, d’avoir quelqu’un pour diriger ? De manière pragmatique, sûrement pour assigner la responsabilité à une seule personne, pour ne pas partager la charge mentale, pour des raisons simples d’organisation, parce que nous avons toujours travaillé de cette façon ? Et s’il existait des alternatives plus saines, plus efficaces, plus épanouissantes ? C’est ce que nous avons développé chez Toovalu, en s’organisant autour d’un but commun : la raison d’être des devs.

Dans cette équipe, nous n’avons ni chef·fe, ni manager, ni lead-dev, ni architecte. Nous sommes toutes et tous identifié·es comme dev, ce qui ne veut pas dire que nous ne sommes pas organisé·es, bien au contraire.

La raison d’être du cercle dev, notre but

Développer Toovalu Impact de manière éco-conçue, accessible et évolutive.
Réaliser une veille expérimentale afin d’imaginer des opportunités techniques et contribuer à la communauté.

Une des règles fondamentales dans notre fonctionnement, c’est que tout ce qui n’est pas interdit est autorisé tant que la raison d’être est respectée. On change le paradigme à la manière de l’entreprise libérée ; fini les « Je demande à mon supérieur si je peux », « Est-ce que mon manager trouvera cela pertinent ? », « Est-ce que cela va jouer sur ma demande d’augmentation ? ».

Cette règle permet une prise d’initiatives alignée avec la raison d’être qui nous anime, notre leitmotiv.

C’est bien elle qui guide nos choix et influence nos prises de décisions.

Pas de manager, mais comment assurer les fonctions du manager ?

Mais que doit faire un manager ? Quelles sont ses missions ?

Henri Fayol est considéré comme un pionnier dans le management. Il détaille les cinq fonctions essentielles du manager dans les années 1900.

• Prévoir : anticiper et planifier, savoir où l’on va.
• Organiser : munir l’entreprise de tout ce qui est utile pour son fonctionnement : ressources humaines, financières et matérielles.
• Commander : indiquer les tâches et instructions aux membres du corps social.
• Coordonner : mettre l’harmonie entre tous les actes d’une entreprise de manière à en faciliter le fonctionnement et le succès.
• Contrôler : vérifier que tout se passe conformément au programme adapté aux ordres donnés, aux principes admis et signaler les fautes et les erreurs afin qu’on puisse les réparer et en éviter le retour.

En complément Mary Parker Follet tourne ses travaux sur la différence entre pouvoir et autorité. Elle sera connue comme étant une pionnière du management libéré et défendra notamment :

L’idée d’une autonomisation des individus, des groupes sociaux et des institutions locales pour une démocratie ouverte et dynamique.

L’importance de la formation aux compétences non techniques, le besoin d’appartenance et de reconnaissance et le rôle des réseaux pour y répondre, l’équilibre personnel des travailleur·euses indispensable à leur engagement dans le projet commun, la prise en compte des diversités et leur inclusion créatrice de valeur pour le collectif.

Que ce soient les méthodes d’Henri Fayol, de Mary Parker Follet ou d’autres, aucun de ces pionniers dans l’écriture de leurs concepts, méthode ou philosophie n’a la même vision du management. C’est ce qui persiste aujourd’hui dans nos entreprises et dans nos équipes. En fonction de nos histoires personnelles, de nos expériences professionnelles, nous nous sommes créé une image du management et du rôle que doit avoir le chef.

Si vous faites quelques recherches sur les offres d’emploi de management dans le numérique, vous verrez rapidement qu’elles sont toutes très différentes et en même temps, toutes se ressemblent.

Sur chaque fiche de poste, on peut retrouver les compétences demandées, appréciées ou souhaitées. Généralement, ce sont les compétences humaines qui seront listées. Par contre, pas de détail pour ce qui est des autres missions du management ou du moins pas de façon claire et c’est à ce niveau-là qu’elles sont similaires. Elles manquent de précisions.

Le risque est relativement élevé pour une entreprise de ne pas clairement définir les tâches, étant donné que chaque individu a sa propre vision du management. Et si la personne n’a pas la même vision que son entreprise, il y a fort à parier que la période d’essai n’aboutira pas ou que l’équipe connaîtra une phase de turnover importante.

Depuis les années 70, de nouvelles méthodes sans management apparaissent. Que ce soit la sociocratie et son mode auto-organisé, l’entreprise libérée ou l’holacratie dont nous nous inspirons chez Toovalu. Toutes ces méthodes incitent à une organisation sans contrôle.

Cela ne veut pas dire que nous faisons confiance à tout le monde, que chacun fait exactement ce qu’iel souhaite et que personne ne pourra rien dire ou que rien n’est attendu.

Ces méthodes servent à autonomiser les individus, prendre des responsabilités s’ils le souhaitent et nous permettent d’être flexibles, de prendre en charge des missions transversales. Cela paraîtrait étrange dans une organisation classique qu’un·e dev travaille sur la grille de rémunération des salarié·es et pourtant je fais bien partie du groupe de travail sur la rémunération de toutes et tous les salarié·es (commerciaux et commerciales, consultant·es, RH, dev, designer, product owner…).

Vous allez me dire, mais comment fait-on sans contrôle ?

Dans notre cercle (le cercle est une équipe structurée par compétences), chaque rôle devient son propre manager, car chaque rôle sera autonome dans son fonctionnement et dans ses prises de décision. Pour arriver à ce résultat nous devons expliciter ce que peut faire chaque rôle et ce qu’il doit faire. Il n’y a pas de place à l’à‑peu-près. Nous travaillons en équipe sur la définition de ces rôles.

Nous définissons ce que chaque rôle doit faire en redevabilités et nous détaillons son pouvoir décisionnel en domaine. C’est ce qui va être différent des autres modes de gouvernance. Dans ce système, nos tâches et notre pouvoir de décision sont explicites et visibles par toutes les personnes et à tout moment.

Il faut également savoir que ces rôles ne sont pas gravés dans le marbre. Chaque mois, nous avons la possibilité de challenger ces rôles lors de nos temps de gouvernance. Que ce soit le fait d’ajouter des redevabilités, d’en retirer ou de créer de nouveaux rôles, notre cercle fonctionne de façon organique. Il est en perpétuel mouvement en fonction de notre équipe et du projet.

Ce n’est pas une direction ou des rôles en particulier qui vont influer sur ces changements. Ce sont bien les individus qui composent un cercle qui le feront évoluer. Qui mieux que l’équipe pour savoir de quoi elle a besoin ?

Comment être sûr que l’on respecte la raison d’être et que tout le monde fait son travail ?

Pour s’assurer que la raison d’être est toujours au centre de notre travail, nous avons quatre rôles structurels. Ce sont eux qui vont remplir la fonction managériale et qui seront énergisés³ (comprenez « pris en charge ») par les membres de l’équipe.

Aucun n’a besoin d’un temps plein et aucun n’est au-dessus des autres. Ils sont côte à côte. Les personnes qui énergisent ces rôles sont également des membres de l’équipe et des devs et ce, pour ne pas avoir une personne qui endosse le rôle de chef.

Nous avons donc établi des règles pour interdire qu’une seule personne énergise tous ces rôles. Ils sont forcément énergisés par plusieurs personnes de l’équipe.

Le facilitateur

C’est ce rôle qui va animer les temps de réunions, s’assurer que tout le monde a eu l’espace nécessaire pour pouvoir s’exprimer et que le temps prévu pour la réunion soit respecté. Cela évitera de subir des réunions à débordements et que les profils dominants prennent toute la place. Il permet également aux profils introvertis de pouvoir s’exprimer. Le rôle de facilitateur devra donc, par moment, mettre fin à des débats et proposer des solutions pour que le sujet ne se cristallise pas.

Ce rôle a un devoir de neutralité, il ne devra pas influer sur les votes lors des prises de décisions. Il devra proposer le mode de prise de décision qui lui semble le plus adéquat à la situation.

Le secrétaire

Ce rôle va programmer les temps de réunions récurrentes de l’équipe et celles sur demande des membres, s’assurer que tout le monde soit disponible à la date et l’heure prévues, et il aura donc une vision des agendas de l’équipe pour l’y aider. Il aura également dans ses redevabilités le devoir de consigner les échanges dans un rapport de réunion et sa publication au reste de l’entreprise pour la transparence des échanges. Cela permettra de garder un historique des prises de décisions.

Le porte-parole

Il devra porter au cercle plus large, composé des autres porte-paroles de l’entreprise, les tensions qui n’auraient pas pu être traitées dans son cercle. Cela peut être une question liée au budget ou un besoin de créer et lancer un nouveau projet avec, comme parties prenantes, d’autres membres de l’entreprise.

Le porte-parole rendra également compte au cercle plus large des informations importantes de la vie du cercle dev, comme, par exemple, les objectifs du cercle ou les nouveaux rôles.

Le leader

Le leader regarde l’intérieur de son cercle et n’en sort pas, car son objectif et sa mission sont de pouvoir garantir la raison d’être du cercle et de mettre tout en œuvre pour qu’elle soit respectée. Il devra définir les rôles dont le cercle a besoin, et s’assurer que ce sont les bonnes personnes qui énergisent ces rôles.

Les domaines des devs

• Langages et bibliothèques utilisées pour les développements
• Le prestataire d’hébergement

Cela veut dire que personne dans l’entreprise ne peut prendre la décision de signer un contrat avec un prestataire pour l’hébergement de nos outils et produits sans avoir consulté les devs et que personne, en dehors d’elleux, ne pourra changer les technologies que nous utilisons sans leur accord explicite. Cela implique également que chacun et chacune a son mot à dire concernant ces choix, notamment grâce au rôle de facilitateur.

Les redevabilités

• Maintenir la documentation technique du projet et de l’infra
• Livrer à la fin de chaque cycle de développement
• Réaliser une démo de nos fonctionnalités à la fin de chaque cycle de développement
• Envoyer l’enregistrement au rôle Ambassadeur du cercle produit
• Réparer les crises de production
• Proposer des fonctionnalités
• Démontrer ses développements aux autres devs

Ceci représente la liste de tâches à réaliser en tant que dev. C’est ce que nous devons faire lorsque nous énergisons ce rôle. Ni plus, ni moins que ce qui est décrit dans cette liste.

Personne ne gère l’infra ? Qui fait le front ? Le back ? L’accessibilité ? La liaison avec la gestion de projet ? Le staging des projets ?

Qui a dit que nous n’avions pas d’autres rôles dans notre cercle et dans les autres cercles ?

Nous n’avons pas souhaité avoir de rôle spécifique back et front, car dans l’équipe, tout le monde développe et est capable de faire les deux. Même si nous avons des préférences, nous sommes tous et toutes capables de changer de technologie. Les jours où nous voudrons créer des rôles distincts, nous en avons la possibilité.

Parce que tant que ce n’est pas interdit, c’est autorisé. Et pour rappel, nous avons nos espaces de gouvernance régulière, qui nous permettent de faire évoluer notre cercle et nos rôles.

Les types de réunions pour animer ce cercle

Une fois tous ces rôles explicitement décrits et énergisés, il faut créer des espaces pour permettre la prise de décision et l’évolution de ce système. Il faut imaginer que notre fonctionnement est organique. Il vit et évolue en fonction des individus, de leurs compétences et de leur appétence.

Les réunions de triage

C’est notre réunion opérationnelle hebdomadaire, qui nous permet de prendre des décisions rapides pour évoluer et de faire avancer nos projets. Ce format de réunion est structuré en plusieurs étapes et les échanges sont animés par le rôle de facilitateur et organisés par le rôle de secrétaire. Chaque rôle y apporte ses propositions.

Nous pouvons proposer une nouvelle bibliothèque, un nouveau pattern, une convention à ajouter au guide, un processus, une documentation, etc. Pour faciliter, chaque rôle doit pouvoir préparer en amont sa demande. Il va devoir la construire, que ce soit suffisamment précis pour que les autres membres du cercle n’émettent pas d’objection par manque d’information.

Nous essayons autant que possible de respecter la prise de décision par consentement. Cela signifie que tant que personne ne s’oppose, alors la proposition est validée. Contrairement au consensus où l’on va souhaiter avoir le « oui » de chaque personne.

Lors de ces réunions, nous ne cherchons pas la solution parfaite. Nous cherchons LA solution qui peut être mise en place par et pour le rôle. Elle pourra évoluer de semaine en semaine si besoin.

Pour pouvoir objecter sur une proposition, il faut des arguments valables. Une objection de la forme « Je ne suis pas d’accord, point barre » n’est pas valide.

Et si personne ne refuse, alors la proposition est validée et c’est à celui ou celle qui a porté cette tension de la mettre en œuvre.

La gouvernance

Nous avons explicité certains des rôles structurels plus haut, mais nous avons également besoin d’une instance dédiée pour pouvoir créer ces rôles, les modifier et les supprimer. Chaque membre du cercle peut donc proposer les améliorations qui lui semblent nécessaires dans l’accomplissement de son travail et de la raison d’être de son ou ses rôles. Nous avons également la possibilité de proposer des améliorations pour tous les autres rôles du cercle.

Au fur et à mesure, cela nous aide également à prévoir nos recrutements. Lorsque nous n’arrivons plus à énergiser les rôles présents dans le cercle, nous pouvons donc remonter un besoin de recrutement au cercle plus large.

Mais ça vient d’où ce fonctionnement ?

Vous l’avez sûrement compris au travers de ces quelques lignes, notre fonctionnement sans chef·fe dépasse les développeurs et les développeuses. L’entreprise entière fonctionne de cette façon. Nous avons entrepris cette bascule il y a deux ans, après huit ans d’existence.

Cette méthode que nous utilisons au quotidien est inspirée de l’holacratie, une méthode de gouvernance partagée.

Cette dernière promeut l’autonomie, la communication et permet à chacun de s’engager au mieux dans l’entreprise. Nos rôles sont des rôles élus pour la plupart, ce qui permet de positionner les personnes qui nous semblent les plus compétentes pour réaliser les tâches nécessaires au bon fonctionnement de l’entreprise.

Remerciements

Sans elles et sans eux, l’article n’aurait jamais vu le jour. Merci à toute l’équipe Toovalienne de partager cette gouvernance, en commençant par le cercle Dev : Hortense, Flavien, Leny, Aurélien. Le cercle Produit avec Meghann, Mélodie, Laura, Florian et Maud. Le cercle Vision et Esprit pionnier avec Nicolas, Caroline et Marie et le cercle Écosysteme avec Élodie, Maxime, Jean, Jeanne, Baptiste, Renelle, Stéphanie, Sandhya, Quentin, Dorine, Sonia et Benjamin. Enfin, il y a également le cercle Humain & Collectif qui rassemble tous les membres de notre organisation.