How to make decisions in an asynchronous work environment: Our method at Alan

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 our culture of transparency, asynchrony and writing. Mastering the conversational mechanics of this forum is key for every Alaner. Here's how we do it.

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 we told you that we could do things differently? At Alan, we detected the limits and risks of meetings very early on. Our meetings were designed to be short (no more than 15 minutes), well organized (a clear agenda) and therefore produce decisions. The problem was that we often got off track - it's hard to control discussions. As a result, we were often disappointed, we had trouble remembering what was said, and it was complicated with people who were absent or at a distance. So we decided to put what we traditionally did orally... in writing! The result: we 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 our method? We explain it all to you.

Now, when we need the intelligence of the team to solve a problem, to deepen a subject, to validate solutions, instead of scheduling a meeting, we open a conversation (or "issue"), on our 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.We found the trade-off between social platform and structured feedback management interesting, so we decided to divert its use to host all of our decision making conversations at Alan.

In concrete terms, how was this done?

1. We created an account on Github.‍

2. We created a fake "code" directory and made it "private" (we 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. We go to the "Issues" tab of our directory to find all our 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 our knowledge is valuable: just do a little research on our 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.

"To open or not to open a discussion, that is the question. Efficiency requires, we 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 we make better decisions, faster, we have developed a system (we love them at Alan).

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 we prefer a discussion on our forum rather than on Slack:

Key contacts

We use the LOCI (Lead, Owner, Consulted, Informed) model to clarify the responsibility and the distribution of our interlocutors in a balanced way on each of our 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 we 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 our rates revised upwards (althoughwe 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.

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 our point of view.

To help us communicate our 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

We 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 ‍‍‍

We share our expectations here: deadline to contribute, date of closure of the issue, date by which a solution must be found.

Share a solution proposal

We 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.‍

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

Write more effectively

Be concise and articulate

We 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 our statement.

Apply the "So what?" test.

Every time we write something, we reread it and ask ourselves "So what?" This helps us better understand the implications or arguments of our 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

We 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 anowner, it can be helpful to keep only those contributions that advance the conversation.‍

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 our 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.

With our 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 our 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 our company, decision making is not consensual, we 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, we 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 we try. Afterwards, as the impact begins to become clearer, we reflect on the decision we made, and look at how we 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 we apply the progressive notification rule at Alan: we trust each other. We assume that every Alaner has correctly set up his Github account to be notified. We 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

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, our 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 :

• We limit the interruptions: bye bye the untimely meetings and the flood of associated notifications.

• We reduce the spectator effect: bye bye inhibited participation and presenteeism.

• We improve the quality of our decisions: welcome to step back and be factual.