RAIS (Regular Asynchronous Information Sharing)

Summary

• Information is held by managers, but they tend to hoard it
• If you want to run organizations or projects more smoothly, you should share information regularly
• To do this, sharing information "regularly" and "asynchronously" is effective

Background

Information is held by managers

I read Will Larson's "Staff Engineer" book (the Japanese edition with expanded interviews for Japanese readers). In one of its supplementary chapters, it states that organizational information is designed to revolve around managers, and I found this to be very true.

Organizations like GitLab that share all information asynchronously and via a SSoT (Single Source of Truth) are rare. Usually, confidential meetings are held among higher-ups, and decisions are passed down to middle or ground-level workers as needed. The reliance on meetings—primitive methods—inevitably makes communication word of mouth, which is a structural issue.

The key players in this structure are the managers, or you might call them middle managers. They are key because they connect the executive level with the operations level. In decision-making processes not involving executives, they virtually act as kings. Unless they release information, the ground-level workers cannot access it.

Managers tend to hoard information

Not every manager, but most do tend to hoard information or sometimes don't share it at all.

This is also a structural issue, leading to the belief that information sharing is equivalent to conveying it in meetings. Meetings entail costs. If there are 5 members, are you going to set up a meeting with all 5 people every single time?

Managers often claim, "I'm open because I answer when asked," but that is far from openness. Openness is achieved only when information is available to anyone, at any time, without having to ask.

About This Article

This article will teach managers, including engineering managers, how to release information.

By adopting this approach, as a manager, you'll be able to share information regularly without burden, gaining trust from your team members. In turn, members will be able to act based on the shared information, making projects easier to manage. While the effort of sharing regularly may initially seem burdensome, it is undoubtedly worth it.

Regular Asynchronous Information Sharing

Regular Asynchronous Information Sharing (RAIS) is about sharing information regularly but asynchronously, as the name suggests. We'll abbreviate it as RAIS.

Examples of RAIS

• Once a week, share the summaries of decisions made in management meetings via chat
• Once a week, distribute summaries of meetings held among managers or senior engineers via a mailing list
• Daily, write an overview and summary of meetings attended that day in a wiki, and also share the URL in chat

How to Implement RAIS

Simply define the parameters and put them into practice.

There are 3 parameters:

1. Frequency
2. Content to share
3. Audience

Let's delve into each.

1: Frequency

When it comes to frequency, there are options like daily, weekly, or monthly.

I refer to it as DWMY. You organize your notes daily and then use that organization for the weekly review. Then use weekly notes for the monthly report, and similarly, use the monthly summaries for the annual review. By building it up this way, the workload becomes manageable.

Consider the alternative: if you were to compile a monthly report without doing daily or weekly reviews, you'd be looking at summarizing 30 days of information all at once. That's overwhelming. However, with DWMY, you only need to review 4-5 items from your weekly summaries.

2: Content to Share

Essentially, it's everything you've gathered from meetings. Think of it as subtracting from that total.

It's hard to determine what will be useful to whom, so instead of filtering based on your own judgment, aim to divulge information as broadly as possible.

For creating content, DWMY is recommended. Especially on a daily basis—summarizing what you learned from meetings daily. Even just a 5-minute slot to jot down bullet points is enough. Don't stress if you can't document every meeting.

For example, if you attended 7 meetings in a day, ideally, you'd have a list like this:

- Meeting 1
    - Summary
    - Summary
    - ...
- Meeting 2
    - ...
- ...

Perhaps you can't disclose meetings 4 and 5 due to privacy concerns—which is fine (sharing confidential meeting details is problematic). A few lines are totally acceptable.

For sharing content, weekly is a good balance. However, it's easier to create a weekly summary if you have daily tasks to work with. Some may find it easier to compile retrospectives weekly. Tailor the operations to your preference. It's something you are doing, so do it in a way that suits you best.

3: Audience

Share where the team naturally communicates. This is likely in a chat tool like Slack, but some projects may use mailing lists.

If it's hard to write in chat, feel free to use a wiki, notes, or a repository (Markdown), but don't forget to circulate the URL to the channels where communication flows.