We believe the best work is done on your own time. So we made Slite, by and for remote teams.
Discover Slite

Async doesn't have to be slow

Link your docs, discussions, decisions, and meetings to create a workflow that keeps on turning even when you sign off.

Async doesn't have to be slow

Link your docs, discussions, decisions, and meetings to create a workflow that keeps on turning even when you sign off.

Last updated
April 20, 2022
Written by
Melanie Broder
Artwork by
Clara Rua

We talk a lot about async best practices on this blog. But there are some misconceptions about transitioning your remote team to async-first communication.

  1. Async-first doesn't mean "abolish meetings altogether."
  2. On your own time doesn't mean "whenever you feel like it."

In other words, async doesn't have to be slow. In an ideal world, async communication creates a wheel of feedback, discussion, and decisions that's more efficient than in-sync communication. But it also is flexible enough to make room for sync communication when you need it.

In Slite, we've created a link between Docs and Discussions that supports a flow of steady communication that ends in action. Here's how it works, more or less:

Our async workflow is an async flywheel, with breaks for sync catch-ups

What does it look like in action? How about a thought exercise?

The async flywheel in action

A (fake) case study

Team member #1 in Jakarta wakes up at 7am, makes coffee and starts a new doc outlining a pitch for a short project that will involve Team member #2 (Cologne) and Team member #3 (Milwaukee). They open a discussion alongside the doc asking for feedback. They then move on to other tasks.

6 hours later, #2 signs on and sees the doc and discussion they've been tagged in. They answer #1's questions, then respond with a few questions in response, and gives #3 some action steps for when they sign on. The doc populates with some data that #2 has pulled.

45 minutes later, #1 responds to #2 in the doc and makes amendments before wrapping up for the day.

6 hours later, #3 signs on and sees the doc and discussion. #3 messages #2 on Slack to mention that their data might be out of date. #2 calls #3 over Zoom, they fix the error live with screen-sharing, and comment on what they did in the doc, so #1 can see. #2 logs off. #3 completes remaining tasks, leaves one comment about expanding the project's scope, and then sums up the work that's been done at the end of their day in the discussion.

The next morning, #1 logs on again, sees the work that's been done and the message from #3 about expanding scope. #1 adds to the discussion about why they think the limited scope is preferable for now, but expansion is something to keep in mind for the future. #1 closes the discussion with a decision, and the project is done.

Maybe this 100% async scenario is too idealistic. Too ideal.

Another example

How about a mix of async and live communication? And, action.

INT. JAKARTA, COLOGNE, MILWAUKEE

TEAM MEMBER #1 wakes up at 7am, makes coffee and starts a new doc outlining a pitch for a short project that will involve TEAM MEMBER #2 and TEAM MEMBER #3. They open a discussion alongside the doc asking for feedback. They then move on to other tasks.

TEAM MEMBER #2 signs on and pings #1 on Slack.

#2: Hey, #1, you got a min to explain this? Let’s hop on a call.

#1: Sorry, not right now. Leave some questions in the doc or discussion and we can debrief when #3 signs in.

#3 Signs in, sees a doc and a discussion, reads over materials and leaves some additional comments.

#1 [pings #2,#3 on Slack]: Hey, thanks for the questions, let’s go through the project live while we’re all online, then you two can take it from there.

#2,#3 [simultaneously]: Sounds good.

INT. JAKARTA, the next morning

#1 sees that progress has been made but the project isn’t finished. #1 takes a few hours to close the project.

[END SCENE.]

Closing the loop

Now, ticking boxes and getting stuff “done” doesn’t really mean anything.

When we think too hard about it, the word “project” doesn’t mean anything, either. The problem that async solves is not “getting shit done,” or even “collaboration.” It’s about removing the stop-and-start, or alternatively, go-go-go nature of work. It’s about creating a flow of work that’s flexible and fits in with your life, no matter who you are and where you live.  And then when the moment comes to close that loop, you’re ready to feel a sense of accomplishment and start a new one.

Drop us a line

Hey I'm Mel,
Publishing online sometimes feel like shouting into a void so I want you hear what you'd like to read about! How do you want to improve remote work? Drop us a line.
Thank you for sharing
Something went wrong, try again.
Written by

Melanie Broder is on the Marketing team at Slite, where she works on all things content. She helps Slite users gain new skills through guides, templates, and videos. She lives in New York City, where she likes to read novels and run loops around Central Park.

Artwork by

Clara Rua is on the Design team at Slite. She juggles with all the Slite's brand codes to make our values and beliefs come to life in illustrations, projects, and visuals, amonst other things. You can find her cycling, surfing, pottery making, jump-roping, yoga-ing from the south of France to the Moroccan west coast.

Share this story
Preview
slite.com
Async doesn't have to be slow
You
Document, discuss, decide, do. All in Slite.
Discover Slite