Original Article here

In most companies, to make a decision, you have a meeting. At Alan, we open a written conversation, called an “issue,” in an online forum. These conversations are the cornerstone of the culture of transparency, asynchrony, and writing. Mastering the conversational mechanics of this forum is key for every Alaner. Here’s how they do it.

Introduction

#

Everyone hates meetings

#

No one comes prepared, it starts late, and the person with the voice will always have the last word, rightly or wrongly. An hour later, your mind is even more confused than before you entered the room and you wonder if you have any paracetamol left. But you’re used to it, after all, meetingitis is the trademark of any self-respecting company, right?

What if they told you that they could do things differently? At Alan, they detected the limits and risks of meetings very early on. The meetings were designed to be short (no more than 15 minutes), well organized (a clear agenda) and therefore produce decisions. The problem was that they often got off track - it’s hard to control discussions. As a result, they were often disappointed, they had trouble remembering what was said, and it was complicated with people who were absent or at a distance.

So they decided to put what they traditionally did orally… in writing!

The result: they make better decisions, because writing forces us to take the time to reflect. The discussion is more nuanced, better documented and argued. In short, it’s no longer an eloquence contest. And the icing on the cake is that replacing meetings with a written internal forum increases everyone’s autonomy: by making information publicly available, the possibility of contributing to the discussion has increased and collaboration has become easier.

Want to know the method? they explain it all to you.

1. Hijacking a platform into an online forum

#

Now, when they need the intelligence of the team to solve a problem, to deepen a subject, to validate solutions, instead of scheduling a meeting, they open a conversation (or “issue”), on the online forum. This forum is hosted on a platform called “Github”.

What is Github?

#

Initially, it is a collaborative platform designed for web developers. The idea is to share and centralize feedbacks on the code they create.

they found the trade-off between social platform and structured feedback management interesting, so they decided to divert its use to host all of the decision making conversations at Alan.

In concrete terms, how was this done?

1. Created an account on Github.
2. They created a fake “code” directory and made it “private” (they named it “Topics” at Alan’s to decide on the topics of life 😇)
3. A labeling system was created to more easily distinguish each topic of conversation.
4. They go to the “Issues” tab of the directory to find all the current discussions “open” - and the decisions taken “closed”.

💡We have now passed the 17,000 issue mark. So many meetings that didn’t see the light of day and so many hours saved! This history of the knowledge is valuable: just do a little research on the Github to understand the ins and outs of each decision. And if we want to question it, we already know what arguments have won in the past.

2. Define the rule: when to open an “exit”?

#

“To open or not to open a discussion, that is the question. Efficiency requires, they know that every decision does not systematically justify opening an issue. If some can be solved in a few days, others can take more than a week… So, to make sure they make better decisions, faster, they have developed a system.

Ask yourself the right questions

#

• Who will be affected by the decision?
• How reversible is the decision?
• Is this an urgent decision to make?
• Do I need more context to decide?

Determine the degree of impact

#

Generally, an issue is open when the degree of impact and reversibility of a decision is deemed important. To put it simply, here are the cases in which they prefer a discussion on the forum rather than on Slack:

Key contacts

#

They use the LOCI (Lead, Owner, Consulted, Informed) model to clarify the responsibility and the distribution of the interlocutors in a balanced way on each of the discussions.

Lead

#

Description

#

The Lead is responsible for the success of a decision. He/she ensures that the context behind each decision is correctly understood and distributed within the team.

Special feature

#

At the beginning of the discussion, he specifies to what extent he wants to be involved in the decision so that the Owner has all the cards in hand to arbitrate.

Mission

#

When the Lead is not the final decision maker (Owner), he/she should:

➡️ Make sure you are in agreement with the decision being considered. ➡️ Trust the “Owner” and accept responsibility for what is produced by the team. ➡️ Expressing opinion when there is strong disagreement.

Distribution

#

There should be only one “Lead” per discussion.

Owner

#

Description

#

The Owner is responsible for the final decision and leads the project to achieve the set objective.

Special feature

#

If he encounters a problem that he cannot solve, he must refer to the Lead.

Mission

#

As a conductor, he or she must:

➡️ Ensure that each contributor is informed of the discussion (and contributes in a timely manner) ➡️ Investigate the problem, gather answers and follow up on the project. ➡️ Open and close the discussion. Make and share the final decision.

Distribution

#

It is recommended that only one person be responsible for each decision.

Consulted

#

Description

#

The “consulted” Alaners are those whose opinion counts in the decision making process. Their input is considered essential to make the best possible trade-off.

Special feature

#

They hand over control to the decision maker(Owner). In case of strong disagreement, they must sound the alarm and, in the worst case scenario, escalate the information to the Lead.

Mission

#

As active contributors to the discussion, they are obliged to contribute in a timely manner, even if it is just to confirm that they have nothing to add to the discussion.

Distribution

#

It is recommended to avoid notifying more than 6 Alaners “consulted” per discussion. While their input is key, this could cause a delay in the schedule.

Informed

#

Description

#

These are Alaners kept informed of progress, often once the decision is made.

Special feature

#

Communication with these Alaners is one-way.

Mission

#

As an “informed” Alaner, no contribution is expected from their side.

Distribution

#

The decision-maker should consider the potential impact of the decision and notify the affected Alaners accordingly.

Useful definitions

#

Okay, but how do they evaluate this threshold of importance? Alan distinguishes between two types of decisions:

• One-way decision (difficult to reverse)
  • These are decisions that would require too much effort or significant expense to reverse.
  • Example: the update of the rates revised upwards (although they have already revised it downwards)
• Two-way decision (easily reversible)
  • These are decisions that do not, at first glance, carry too much risk. An unforeseen event could result in a loss of energy, this is acceptable.

Adopt a “problem solving” approach

#

Framing a project or discussion helps us make better decisions.

Frameworks are working tools, they do not forbid thinking. On the contrary, they allow us to structure and clarify the point of view.

To help us communicate the thinking about a problem or decision as effectively as possible, each issue offers an identical template. This structure allows us to go one level further while teaching more junior people how to break down a problem.

The typical architecture of an issue

#

• “Scope” - Define the scope and clarify the “why” of the discussion
  • “The purpose of this outcome is…”
  • “This issue is NOT about…”
• “Context & materials” - Provide context and useful resources
  • They add links to any discussions or documents that provide context.
• “LOCI” - Clarify responsibility and distribution of contact persons
  • Lead
  • Owner
  • Consulted
  • Informed
• Set a deadline
  • They share the expectations here: deadline to contribute, date of closure of the issue, date by which a solution must be found.
• Share a solution proposal
  • They describe here a potential solution to the problem or propose some solutions to choose from.
• Addressing questions
  • All those whose opinions and participation will be helpful in making a well-informed decision are invited to participate. To keep the debate moving in the right direction, the discussion leader asks specific questions of key contributors to confirm or refute assumptions - and to avoid throwing a bottle into the sea.

    

Asserting yourself in writing

#

To prevent the debate surrounding a decision from dragging on, they adopt a few rules to focus the discussion on the essentials.

Write more effectively

#

• Be concise and articulate
  • They believe in useful writing: “What is well conceived is clearly stated” said Boileau. If we can’t write something down in a simple way, it means that we are not sure of the accuracy of the statement.
• Apply the “So what?” test.
  • Every time we write something, they reread it and ask ourselves “So what?” This helps us better understand the implications or arguments of the message. If the answer is obvious, it helps to answer potential questions more clearly.

Follow-up

#

• Focusing on the “Million Dollar Question
  • Gathering many differing opinions can be confusing, focusing on THE most important issue or sticking point helps to focus on the priority, refocusing the contributions of peers - without getting lost in the sea of details.
• Regularly recap points of agreement
  • Clarifying what has been collectively agreed upon and what still needs to be discussed is a common practice for the owner of a Github conversation. It is a way to give better visibility on the contribution lines to one’s peers, it is also a way to avoid focused back and forth on lower priority issues - the goal of the conversation should always remain the North Star to follow.
• Relaunch on Slack as a last resort
  • They limit the number of reminders on Slack. Two exceptions: when contributions are overdue or when urgency requires quick action. To ensure that the agenda is respected, when an owner needs to compare points of view in order to make an informed decision, a reminder on Slack can be used.

    

Hide irrelevant comments

#

• Some threads may have many comments. As an owner, it can be helpful to keep only those contributions that advance the conversation.

Master the formatting

#

• When it comes to conveying a point of view in writing, substance matters as much as form. Here’s how we make the most of the Github forum.
  • Keyboard shortcuts
    • To save time, here is the complete list of Github keyboard shortcuts.
  • Page layout
    • Adding titles (H1, H2, H3), footnotes or even tables to give body to your ideas is possible on Github. Here is the complete list of instructions.

Avoiding the pitfalls: deciding asynchronously

#

With the exit system, everyone can participate in all discussions. There’s no whispering, no secrets, no politics: everyone has the same information - but there are certain prerequisites to keep in mind to avoid disappointment.

Avoiding consensus decision making

#

At Alan’s, every decision discussed on the forum has a single designated “owner” responsible for deciding as an “enlightened despot”.

Her role is to make the best possible decision for the company, without seeking consensus and without politics. To do this, she must investigate innovative ideas, measure risks, analyze data, and question her peers, without having to implement everything she is told.

In the company, decision making is not consensual, they are not a “democracy”. Everyone is a shareholder and therefore owner of Alan. Each Alaner puts the interests of the company before those of the team or the individual. However, they do not want isolated, hasty or uninformed decision making either.

When the owner of a decision is reasonably sure of the right bet to make, he decides and they try. Afterwards, as the impact begins to become clearer, they reflect on the decision they made, and look at how they can do even better in the future.

Limit the number of contributors

#

An effective decision is one that is limited to the views of key contributors. You know Jeff Bezos’ “two pizzas or nothing” rule? His idea is based on a well-known fact: if there are too many people in a meeting, it is inefficient. Asynchronous decision making is no exception to this rule: in general, the more people there are, the less they contribute. At a distance, this “spectator effect” inhibiting general participation - and altering, in fact, the quality of participation - tends to occur when the number of contributors to an issue is not controlled (beyond 6 people, it becomes complicated).

Adopt a progressive notification approach

#

By creating noise, notifications make it difficult to discern between the important and the trivial. That’s why they apply the progressive notification rule at Alan: they trust each other. They assume that every Alaner has correctly set up his Github account to be notified. They therefore restrict the number of people’s tags in the “Questions” section of each issue.

Set up your account to receive notifications

#

• Go to the “Settings” page
• Check the “Web and and Mobile” boxes in the “Participating” and “Watching” sections

The last word

#

Even with the best will in the world, it is difficult to explain everything that happened in a meeting to someone who was not there. But everyone in a team can relate to a decision.

Obviously, the system of decision-making through a forum is neither the best nor the only possible solution to address this problem: it is simply the one that is most like us because:

• They limit the interruptions: bye bye the untimely meetings and the flood of associated notifications.
• They reduce the spectator effect: bye bye inhibited participation and presenteeism.
• They improve the quality of the decisions: welcome to step back and be factual.

Proposal Template

#

Scope

#

• The goal of this issue is …
• The issue is NOT about …

Why I am opening this issue

#

Timeline

#

Context and Materials

#

Proposal

#

Questions?

#