Comment prendre des décisions dans un environnement de travail asynchrone : Notre méthode chez Alan

Personne n’arrive préparé, ça commence en retard, et la personne avec la voix qui porte aura toujours le dernier mot, à tort ou à raison. Une heure plus tard, vous avez l’esprit encore plus confus qu’avant d’entrer dans la salle et vous vous demandez s’il vous reste du paracétamol. Mais vous avez l’habitude, après tout, la réunionite, c’est la marque de fabrique de toute entreprise qui se respecte, non ?

Et si l’on vous disait que l’on pouvait faire différemment ? Chez Alan, on a détecté les limites et les risques des réunions très tôt. Nos réunions étaient pensées pour être courtes (pas plus de 15 minutes), bien organisées (un ordre du jour clair) et donc produire des décisions. Le hic, c’est que souvent, on dérapait — c’est difficile de maîtriser les discussions. Résultat : on était souvent déçus, on avait du mal à se rappeler ce qui s’était dit, c’était compliqué avec les personnes absentes et celles à distance.

Alors, on a décidé de passer ce que l’on faisait traditionnellement à l’oral… à l’écrit !

Résultat : nous prenons de meilleures décisions, car l’écrit oblige à prendre le temps de la réflexion. La discussion est plus nuancée, mieux documentée et argumentée. Bref, il ne s’agit plus d’un concours d’éloquence. Et, cerise sur le gâteau, remplacer les réunions par un forum interne écrit, permet d’accroître l’autonomie de chacun : en rendant l’information accessible publiquement, la possibilité de contribuer à la discussion a augmenté et la collaboration s’est facilitée.

Envie de connaître notre méthode ? On vous explique tout.

Maintenant, quand on a besoin de l’intelligence de l’équipe pour résoudre un problème, approfondir un sujet, valider des solutions, au lieu de programmer une réunion, on ouvre une conversation (ou “issue”), sur notre forum en ligne. Ce forum est hébergé sur une plateforme nommée “Github”.

Initialement, il s’agit d’une plateforme collaborative pensée pour des développeurs web. L’idée étant de partager et centraliser des feedbacks sur le code qu’ils créent.

On a trouvé le compromis entre plateforme sociale et gestion du feedback structuré intéressant, alors on a décidé d’en détourner l’usage pour y héberger toutes nos conversations liées à la prise de décision chez Alan.

1. On a créé un compte sur Github.

2. On a créé un faux répertoire de “code” et l’avons rendu “privé” (on l’a nommé “Topics” chez Alan pour décider des sujets de la vie courante 😇)

‍3. On a créé un système d’étiquetage pour distinguer plus facilement chaque sujet de conversation.

‍4. On se rend sur l’onglet “Issues” de notre répertoire pour retrouver toutes nos discussions en cours “open” — et les décisions prises “closed”.

‍💡On a aujourd’hui dépassé la barre de 17 000 issues. Autant de réunions qui n’ont pas vu le jour et d’heures de gagnées ! Cet historique de notre savoir est précieux : il suffit de faire une petite recherche sur notre Github pour comprendre les tenants et aboutissants de chaque décision. Et si on veut la remettre en question, on sait déjà quels sont les arguments qui l’ont emporté dans le passé.

“Ouvrir ou ne pas ouvrir une discussion, telle est la question”. Efficience oblige, on sait que toute prise de décision ne justifie pas systématiquement d’ouvrir une issue. Si certaines peuvent être solutionnées en quelques jours, d’autres peuvent prendre plus d’une semaine... Alors, pour s’assurer de prendre de meilleures décisions, plus vite, on a mis au point un système (on les adore chez Alan).

Généralement, une issue est ouverte lorsque le degré d’impact et de réversibilité d’une décision sont jugés importants. Pour schématiser, voici les cas de figure dans lesquels nous privilégions une discussion sur notre forum plutôt que sur Slack :

Nous utilisons le modèle LOCI (acronyme de “Lead, Owner, Consulted, Informed”) afin de clarifier la responsabilité et la répartition de nos interlocuteurs de manière équilibrée sur chacune de nos discussions.

Le Lead est responsable du succès d'une décision. Il s'assure que le contexte derrière chacune d'entre elles est correctement compris et réparti au sein de l'équipe. 

Au début de la discussion, il précise dans quelle mesure il souhaite être impliqué dans la décision afin que le responsable (Owner) ait toutes les cartes en main pour arbitrer. 

Lorsque le Lead n’est pas le responsable de la décision finale (Owner), il doit : 

➡️ S’assurer d’être en accord avec la décision envisagée.

➡️ Faire confiance au “Owner” et accepter de rester responsable de ce qui est produit par l’équipe. 

➡️ Exprimer son opinion en cas de fort désaccord.  

Il ne doit y avoir qu’un seul “Lead” par discussion.   

Le Owner est responsable de la décision finale et mène à bien le projet pour atteindre l'objectif fixé.  

S’il venait à rencontrer un problème qu’il ne saurait résoudre, il doit se référer au Lead. 

En tant que chef d’orchestre, il doit : 

➡️ S’assurer que chaque contributeur est informé de la discussion (et contribue dans les temps)

➡️ Investiguer le problème, recueillir des réponses et assurer le suivi du projet

➡️ Ouvrir et clôturer la discussion. Prendre et partager la décision finale.

Il est recommandé de se limiter à un seul responsable par décision.

Les Alaners “consulted” sont ceux dont l’opinion compte dans la prise de décision. Leur contribution est jugée essentielle pour effectuer le meilleur arbitrage possible.

Ils cèdent le contrôle au responsable de la décision (Owner). En cas de fort désaccord, ils doivent tirer la sonnette d’alarme, et dans le pire des scénarios, remonter l’information jusqu’au Lead.

En tant que contributeurs actifs à la discussion, ils doivent obligatoirement contribuer en temps et en heure, même si c’est simplement pour confirmer qu’ils n’ont rien à ajouter à la discussion. 

Il est recommandé d’éviter de notifier plus de 6 Alaners “consulted” par discussion. Bien que leur contribution soit clé, cela pourrait engendrer du retard sur le calendrier.

Il s’agit d’Alaners tenus au courant du progrès, souvent une fois que la décision est prise.

La communication avec ces Alaners est à sens unique.  

En tant qu’Alaner “informé” , aucune contribution n’est attendue de leur côté. 

Le responsable de la décision doit tenir compte des répercussions possible de sa décision et notifier les Alaners concernés en conséquence. 

D’accord, mais comment évalue-t-on ce seuil d’importance ? Chez Alan, on distingue deux types de décisions :

Il s’agit de décisions qui demanderaient trop d’efforts ou de frais importants pour faire marche arrière.

Exemple : la mise à jour de nos tarifs revue à la hausse (bien qu’on l’ait déjà revu à la baisse)

Il s’agit de décisions qui ne portent, à priori, pas de risques trop importants. Un imprévu pourrait résulter en une perte d’énergie, c’est acceptable.

Cadrer un projet ou une discussion nous aide à prendre de meilleures décisions.

Les frameworks sont des outils de travail, ils n’interdisent pas de penser. Au contraire, ils permettent de structurer et de clarifier notre point de vue.

Pour nous aider à communiquer notre réflexion sur un problème ou une prise de décision le plus efficacement possible, chaque issue propose un modèle identique. Cette structure permet d’aller un niveau plus loin tout en enseignant à des personnes plus « junior » comment décomposer un problème.

Nous ajoutons des liens vers toutes les discussions ou documents qui permettent d’établir le contexte.

Nous partageons ici nos attentes : délai limite pour contribuer, date de fermeture de l’issue, date à laquelle une solution devra être trouvée.

Nous décrivons ici une potentielle solution au problème ou proposons quelques solutions parmi lesquelles il faut choisir.

Sont convoquées ici toutes les personnes dont l’avis et la participation seront utiles pour prendre une décision bien informée. Afin de faire avancer le débat dans le bon sens, le responsable de la discussion pose des questions précises à des contributeurs clés afin de confirmer ou d’infirmer des hypothèses — et d’éviter de jeter une bouteille à la mer.

Pour éviter que le débat entourant une prise de décision ne traîne en longueur, nous adoptons quelques règles pour concentrer la discussion sur l’essentiel.

Nous croyons à l’écriture utile : « Ce que l’on conçoit bien s’énonce clairement » disait Boileau. Si nous ne parvenons pas à écrire quelque chose de manière simple, cela signifie que nous ne sommes pas sûrs de l’exactitude de notre affirmation.

À chaque fois que nous écrivons quelque chose, nous le relisons en nous demandant « Et alors ? ». Cela permet de mieux comprendre les implications ou les arguments de notre message. Si la réponse est évidente, cela aide à répondre plus clairement aux potentielles questions posées.

Recueillir de nombreuses opinions divergentes peut être confusant, se concentrer sur LA question la plus importante ou le point bloquant aide à se focaliser sur la priorité, recentrer les contributions de ses pairs — sans se perdre dans l’océan de détails.

Clarifier les points convenus collectivement et ceux qui doivent encore être discutés est une pratique commune pour l’owner d’une conversation sur Github. Il s’agit d’un moyen de donner une meilleure visibilité sur les axes de contribution à ses pairs, c’est aussi un moyen d’éviter des aller-retours concentrés sur des problèmes de moindre priorité — l’objectif de la conversation doit toujours rester l’étoile polaire à suivre.

Nous limitons le nombre de relances sur Slack. Deux exceptions : lorsque les contributions se font attendre ou que l’urgence requiert d’agir vite. Pour s’assurer de respecter l’agenda, lorsqu’un “owner” a besoin de confronter les points de vue pour prendre une décision éclairée, une relance sur Slack peut être opérée.

Certains fils de discussion peuvent accueillir de nombreux commentaires. En tant qu'owner, il peut être utile de ne conserver que les contributions faisant avancer la conversation.

Quand il s’agit de transmettre un point de vue à l’écrit, le fond compte autant que la forme. Voici comment nous tirons au mieux parti de notre forum Github.

Pour gagner du temps, voici la liste complète des raccourcis clavier Github.

Ajouter des titres (H1, H2, H3), des notes de bas de page ou encore des tableaux pour donner du corps à vos idées, c’est possible sur Github. Voici la liste complète des instructions.

Avec notre système d’issues, tout le monde peut participer à toutes les discussions. Pas de bruits de couloir, pas de secrets, pas de politique : tout le monde a la même information — certes, mais il y a certains pré-requis à garder en tête pour éviter des déconvenues.

Chez Alan, chaque décision débattue sur notre forum a un unique “propriétaire” désigné (ou “owner) responsable de trancher en “despote éclairé”.

Son rôle est de prendre la meilleure décision possible pour l’entreprise, sans chercher le consensus et sans politique. Pour y parvenir, elle doit investiguer des idées innovantes, mesurer les risques, analyser les données, interroger ses pairs, sans pour autant devoir appliquer tout ce qu’on lui dit.

Chez nous, la prise de décision n’est pas consensuelle, nous ne sommes pas “une démocratie”. Tout le monde est actionnaire et donc propriétaire d'Alan. Chaque Alaner fait passer les intérêts de l’entreprise avant ceux de l’équipe ou de l’individu. Pour autant, nous ne voulons pas non plus d’une prise de décision isolée, hâtive ou non / informée.

Lorsque l’owner d’une décision est raisonnablement sûr du bon pari que nous devons prendre, il décide et nous tentons. Par la suite, à mesure que l’impact commence à se dessiner plus nettement, nous réfléchissons à la décision prise, et regardons comment faire encore mieux à l’avenir.

Une décision efficace est celle qui se limite aux points de vue de contributeurs clés. Vous connaissez la règle des “deux pizzas, sinon rien” de Jeff Bezos ? Son idée repose sur un constat connu de tous, s’il y a trop d’intervenants à une réunion, elle est inefficace. La prise de décision en asynchrone n’échappe pas à cette règle : en général, plus on est nombreux, moins on contribue. À distance, cet “effet de spectateur” inhibant la participation générale — et altérant, de fait, la qualité de la participation a tendance à se produire quand le nombre de contributeurs à une issue n’est pas maîtrisé (au-delà de 6 personnes, cela devient compliqué).

En créant du bruit, les notifications rendent difficile le discernement entre l’important et le futile. C’est pourquoi, nous appliquons la règle de la notification progressive chez Alan : nous nous faisons confiance les uns les autres. Nous partons du principe que chaque Alaner a correctement paramétré son compte Github pour être notifié. Nous restreignons donc le nombre de tag de personnes dans la rubrique “Questions” de chaque issue.

Même avec la meilleure volonté du monde, il est difficile d’expliquer tout ce qui s’est passé dans une réunion à quelqu’un qui n’y était pas. Or, dans une équipe, tout le monde peut se sentir concerné par une décision.

Évidemment, notre système de prise de décision à travers un forum n’est ni la meilleure, ni la seule solution possible pour adresser ce problème : c’est simplement celle qui nous ressemble le plus car :