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.

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

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.

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

"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).

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:

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.

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. 

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. 

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

There should be only one "Lead" per discussion.   

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

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

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.

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

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.

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.

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. 

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.

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

Communication with these Alaners is one-way.  

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

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

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

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)

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.

We add links to any discussions or documents that provide context.

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

We describe here a potential solution to the problem or propose some solutions to choose from.

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.

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.

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.

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.

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.

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

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.

To save time, here is the complete list of Github keyboard shortcuts.‍

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.

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.

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

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.

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 :