How to get started with async#
Article: https://learn.gitlab.com/coursera-remote-work/asynchronous-comms
Notes#
GitLab measures results, not hours.
Engineers have less sense of urgency to get something out as quick as possible.
Engineers need to document their thought process well, so someone else can pick it up.
Not every business can work asynchronously, for example, manufacturing must be done in a tight set of sequences.
People love to work synchronously if they are online at the same time.
Asynchronous work is less stressfull, because there’s less sense of urgency.
It’s also more inclusive, as it removes the dependency on time zones.
An asynchronous mindset means that whatever we’re doing is done with no one else online. It allows to do deep work in long uninterrupted periods of time.
Important part of being asynchronous is low-context culture. It means that communications take longer to craft. Team members forecast what questions may be asked, and include as much context as possible. The recepient may not be even working at the company yet. This allows for new hires to learn about past decisions faster.
The situational awareness of who’s doing what is important for leadership. Trying to maintain it through status update meetings, Slack messaging, or hallway catch-ups is a drag on team’s productivity. The alternative is to have teams post updates at a regular cadence of their work.
Synchronous meetings should be reserved for collaboration on complex issues. And vice-versa collaboration should be reserved for synchronous meetings.
Team members come and go, and asynchronous communication enables retaining the knowledge.
People seeking information should be able to find it without bothering anyone, or waiting for someone to come online.
This ultimately leads to the need of a strong documentation. No matter how intentional you are in communication, there’s always something left out or misunderstood. Follow-up questions may hang for hours or days unanswered. People need to be able to answer those questions by looking up existing documentation (Gitlab calls it the handbook).
Bias towards async discussions creates more space for synchronous meetings.
In Gitlab, every meeting must have an agenda. And the response must be documented as meeting notes. But if both questions and answers are written, then maybe meeting wasn’t needed, and the discussion can be done async.
Practicing iteration is the most difficult value to embrace. Asynchronous workflow feels taxing for an engineer who’s tasked to focus on a single feature and ship it as quick as possible. Every handoff is a downtime. The solution is to assign the work and set expectations differently. Let every engineer have several (5?) projects they run in parallel. After making a handoff on one task, they switch to another, avoiding downtime to wait for the response.
Examples of async activities in Gitlab:
Weekly announcements
New team member introduction
Backlog refinement / planning poker
Capacity planning
Team members who are unable to attend sync meetings
Quarterly team results recaps and celebrations
Monthly finance accruals
Project sprints and milestones
Broadening coverage during PTO
Preparing for meetings or interviews
Editing communiques and content
Weekly team kickoff/standup sessions
Missed deliverable retrospective
Blocked calendars and non-linear workdays
Alternate times for recurring scheduled meetings
Async communication with those who are not GitLab team members
Asynchronous engineering standup meetings
Conclusion#
Article explains benefits and best practices of working asynchronously.
The focus is no mental health, inclusivity, neural diversity, and work-life balance.
Working asynchronously demands continuous effort. Otherwise, people tend to slip into synchronous ways.
Delivery speed on individual projects is likely to suffer. The overall throughput is going to suffer in short-term (as written documentation takes more time to craft). But in the long-term, throughput and quality of decision-making should improve. Given that everyone reads the f manual.
Which brings me to two problems with async culture:
No one reads docs.
Engineers like to write code, not docs.