The Covid-19 pandemic showed the world that it was possible to be productive in a remote work setting. Some folks have taken things further by fully embracing asynchronous work, some even did this way before 2020.

A few things I’ll note before we move on:

  • Working remotely does not necessarily mean working asynchronously.
  • Working asynchronously usually means you’re working remotely. I suspect it would be difficult to do so in a non-remote work setting.
  • I believe that there are various async work principles that you can adopt without fully going async by default like some companies have (e.g. Doist, GitLab). This is essentially the point I’m attempting to make in this post.
  • I’ll share some learning resources on async work that helped me at the end of this post.

What is async work?

Preston Wick sums it up this way:

“Asynchronous work is a simple concept: Do as much as you can with what you have, document everything, transfer ownership of the project to the next person, then start working on something else.”

Another summary from Lattice:

“Async work, collaboration, and communication simply means that employees work on their own time without the expectation of immediately responding to others.”

What are these principles you speak of?

Note: This is not an exhaustive or perfect list. I’ve come to learn that these principles are & can be valuable in any work setting. I had to learn the hard way when I was at a company with a distributed workforce across 3 main timezone groups: North/Central/South America, EMEA (Europe, Middle East & Africa) and APAC (Asia Pacific). My team, which was based in the Americas, was essentially brand new and had to get up to speed quickly to start delivering on some initiatives. We were in many situations where there was no one else online that could help us. So we had to reverse engineer context, or perform an “archeological dig” for context and then build a library of knowledge as we went.

Assume low-context by default

We have to remember that all of us move in and out of contexts constantly; new hires join a company, people go on vacation, people join a project midway, etc. We need to be considerate of the people in our audience who may have no prior knowledge of what we’re talking or writing about. This principle extends to all interactions you have with your colleagues, e.g. in documentation, meeting agendas, questions/messages on Slack, etc.

Some examples in reality:

  • Business context of new projects/initiatives should be documented in written format. New folks who join a project/initiative midway can read about it after the fact and get up to speed. This democratizes context and hopefully prevents the cycle of people repeating themselves over and over in meetings, not to mention the high probability of knowledge leaks because certain people have context that others don’t.
  • When writing any content (e.g. incident playbook, how-tos, onboarding docs, project contexts), assume your audience has zero context and spell everything out.
  • Meetings should include information on why it’s being held and an agenda so the audience knows what to expect.

Schedule meetings with focus & intention

Full async work culture discourages excessive meetings because it takes time away from focused work. There is definitely a time and place to meet with your colleagues and we should do so with intention.

Some examples in reality:

  • All meetings must have an agenda.
  • Agendas should include, at minimum:
    • Information your audience needs to review beforehand to gain context and meaningfully participate in the meeting.
    • The reason(s) why this meeting is happening.
    • The goal(s) of this meeting.
    • Link to the recording of the meeting (after the fact). Recording a meeting is optional but highly encouraged.
  • Avoid sending out next day early morning meeting requests/invites late in the previous day.
  • In situations when an ad-hoc discussion happens, we should create a written record of significant decisions/outcomes/next steps and the necessary context that led up to it.

Curate your content

It should not be a surprise that remote and async work settings rely heavily on written communication. However, how you write, what you write, and how you organize what you write will influence whether or not it will be usable after you write it. Curation of content is not an easy thing to do successfully, which is why you hear people say things like “Documentation becomes stale as soon as you write it”.

A few things on content that I think is important:

  • Documentation is a subset of content in general. How you treat documentation should be how you treat the content you generate.
  • Clearly differentiate between point-in-time documents and “living” documents so that a reader can tell whether something is or should be outdated or not. Consider creating an archive for content that is no longer current but still valuable in providing context.
  • Keep root-level pages under control. If you use Confluence, the root-level pages are the ones you see on the left-hand navigation when you open a Confluence Space. Too many root-level pages will cause a lot of confusion, especially if they’re not categorized in a way to help with navigation.
  • Ensure there is a single source of truth. If content lives in multiple sources (e.g. Confluence, Google Docs, Notion, etc) and not linked back to a single source, this will cause a lot of friction and confusion and make things impossible to find.
  • Consider creating well-known spaces for types of content that you create new versions of on a frequent cadence, e.g. monthly All-Hands recordings, RFCs (Request For Comments), team discussion notes, demos, etc. Use templates to make the creation of new versions easier and keep the format consistent. Having well-known spaces for these types of content will hopefully make them easier for folks to find after the fact.
  • Whatever you do, do not use Slack as an information repository. It is a real-time communication tool, and “real-time” is the opposite of “asynchronous”.

Essentially, you want your content to be easy to add to, easy to modify, easy to find, easy to navigate. Properly curated and organized content can be life-savers in certain urgent situations, level the playing ground for all team members by helping them gain the context they need and foster an environment where everyone is empowered and equipped to do their job.

Some resources on async work that helped me

GitLab’s All-Remote Guide has been the main source of a lot of my learning, specifically:

GitLab also has a course on Remote Team Management on Coursera that repackages a lot of the information from their All-Remote Guide and presents them in an easily consummable format.

The folks at Twist have a newsletter solely dedicated to the topic of async collaboration that you can subscribe to.