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:

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.