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:

    1. No one reads docs.

    2. Engineers like to write code, not docs.