Working Async at Remote

(This was also posted in our blog here)

Introduction

Realtime (Sync) meetings on Zoom/Slack are good for SOME things, like socializing and team bonding. There are also sensitive situations that need a face-to-face interaction (emergencies, alignment, separations). But Remote is a global company with people in many time zones. This makes sync meetings/huddles inefficient for routine work. The person you need could be asleep or enjoying down time. If we waited for syncs to decide or act, we would be too slow to be competitive. The answer is to avoid sync methods for most work and use asynchronous work methods instead.

What is asynchronous work?

Asynchronous work is the stuff you do at your own pace and order, not during a meeting or huddle. This amount of freedom can be daunting. We need everyone even, swift, and nimble; in other words, able to get the right things done without waiting for others. Async methods help you focus on, document, and communicate this work to the team. We've broken our best practices into three parts - Multiplexing, Communication, and Action.

Multiplexing

Be ready to select and work on more than one project at a time.

Human beings exist in a synchronous world, we are bound by time moving forward one second at a time. The way we prioritize and organize our tasks has an insane amount of impact on the outcome of our pipeline. It's all about planning. This is especially true for a global company like Remote with employees in many time zones.

Sync planning

Typical (synchronous) planning relies on kicking off things in a bulk fashion. On its own it's not a terrible thing to do, however, a system will go as slow as its slowest element. In this case any delay will be propagated through the pipeline, as each stage depends entirely on the step that precedes it. Our business requires speed and so we prefer async planning instead.

Async planning

Async planning relies on breaking tasks in smaller tasks as much as possible and releasing Minimum Viable Changes (MVCs) as frequently as possible. This technique relies on the hypothesis that shipping less but more frequently allows you to measure success and counteract any negative feedback as fast as possible. It also allows a more fine-grained control of resource allocation as we'll be able to perform more tasks in the same amount of time (due to their reduced size).

In this example at the end of the 9 hours we may end up with the same amount of features deployed, however, multiplexing our tasks with async task distribution we were able to release subsets of our tasks, thus being able to validate their impact, and rollback or reassess the next steps. We've reduced the iteration time to a third of the original planning.

This methodology allows us to multiplex tasks, combining them to produce results faster. This is how we ship features and updates to our core products.

For internal work, multiplexing involves asking what is important to address quickly and what can wait? This may be the single most vexing question related to Async work. The answer is not simple, but not a big mystery either - Remoters prioritize our individual scopes of work in the following order:

1. Customer/Business Impact - Is a customer/partner waiting for anything now? We're a remote-first, but also a customer-first company. When a customer has a problem, speed and responsiveness are paramount. If something breaks, we want our end-users calm and trusting in our ability to make things right quickly.
2. Urgent Matters (also known as Blockers) - Are your deadlines met? Are there projects with logical dependencies, i.e. decisions or deliverables that must take place before further work can continue? Are you helping or is your inaction in the way? Which tasks will have the most positive impact for the rest of the team when completed? Five minutes of your time right now might enable ten additional team members down the chain to complete their portions of the work. This includes communication loops!
3. Everything Else - Self-selected from established backlogs after the first two criteria are addressed.

Communication

Use the right tool at the right time. Include the right people at the right time.

Good communication is key to the success of any system (human or machine). There are many types of communication, an email, a message, a voice call, video call or even a "let's go get a coffee". Each has a totally different impact on productivity and picking the right one is as important to the production pipeline as any other task we can perform.

The diagram below depicts the relationship between our internal communication products and how much bandwidth (both in data and cognitive effort) they require. On the left side, you will see modes and tools that need less bandwidth (this very page is an example of low-bandwidth pull documentation at work). As you move right, you will see other modes that require additional bandwidth. Notice that sync communication always requires more than async.

The other data point in the diagram is the relative opportunity cost (the expense in time/resources of actually doing the thing) associated with each mode. If time is money, sync communication will also always cost more in labor and flow disruption to arrange. This makes it easy to see why we prefer one mode over another for certain use cases.

Async Communication - The Little Sips

When should you use it? Most of the time. Async is preferred for:

1. Learning and onboarding
2. Project/product updates
3. Request for Commentary(RFC)
4. On-demand (Pull) Training
5. Assigning tasks to other team members

Sync Communication - The Enriched Uranium of Comms

Meetings are the most expensive tool your company has, use them properly. Why? Take a look at the workflow in the example below. Two developers are working on their own and need to complete set of tasks (A,B and C) to ship on time:

We want to avoid working like this and so we use multiplexing and async as much as possible:

In this example communication is performed through messaging and well written documentation. In these cases, even if the end-goal of the message exchange is spread throughout the time, the impact on the work flow is negligible and often means more execution.

When we do use sync meetings, we use them sparingly and only when the conversation is complex, nuanced, or requires richer emotional content:

1. Interviews
2. 1:1 sessions
3. Team and all-hands meetings
4. Hard problems (many moving parts, emotionally fraught, time sensitive)

(mostly for fun and hanging out)

Unique to Remote - We Use Some Tools Differently!

You should already be familiar with many of the usual office productivity tools, but you might not be familiar with how we use them here at Remote. Please note:

1. EMAIL - 99.99999999% For External Use Only!!! The yourname@remote.com email is excellent for business between Remote and the outside world. It is also the primary security token for many of the software tools we use. Internally however, we prefer Slack threads for the kinds of work previously conducted via email. This method provides greater transparency and avoids holding important conversations between two systems.
2. CALENDARS - If you need a sync meeting with someone, don't ask, just schedule, then let them know in Slack. If your attendee needs to move the time around, they will. Read more about scheduling meetings with a global team here.
3. GROUP CHAT - We use Slack as our group chat workspace, however there is no expectation of an immediate response unless the conversation is urgent and occurs in one of our monitored slack channels (like TechOps). This can be quite jolting for Remoters coming from organizations that demanded realtime responsiveness in group chat. We work differently. It is essential to close communication loops, but only as urgently as required. So relax!
4. WEB CONFERENCING - We use Zoom and Slack's Huddles for all-hands meetings, team huddles, but mostly for socialization. By limiting the use of face-to-face video, we limit the fatigue and make sync meetings bearable again.
5. UPDATES & NOTIFICATIONS - Most of our software tools have collaborative features like change notifications, comments, callouts, etc. To avoid missing anything, Remoters must keep track and manage these. You can enable/disable and adjust the way notifications are triggered.

Why do we do it this way?

Humans aren't very good at going from a state of total focus on task A to total focus on task B without loss (as depicted in the following image). For example, when you're deep in a book and get interrupted with something. It'll take you a moment to get back into the book.

In Example 5 we see a time-based chart, where Time and Productivity are the axes. This example depicts the timeline of a backend developer that gets interrupted twice, first by a frontend developer about the payload of an API request and second time from a new team member about setting up the project's database locally.

The backend developer spent some time focusing on the task at hand (1) and later transitioned to a state of focus (2). This (2) is what we want to maximize and where we get the best out of our super creative and powerful brains. Then, when interrupted, the developer spends some time to address the question from the frontend developer (3) to then get back to the task (1). Unfortunately as the developer was focusing again (2), a new interruption occurs (3).

If you read this far, I'm sure this is all very familiar to you.

Now, the cherry on top is the concept of "Flow" (2). Wikipedia's definition (more here):

In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting loss in one's sense of space and time.

If being totally focused is hard, getting into the Flow is even harder. The more you stay focused, higher the probability of getting into the Flow, however if you have trouble keeping focus, then forget about Flow.

Async communication shines with great power here, as it shields everyone's time and focus while reducing meaningless time sinks. When you're communicating async, this types of interruptions happen much less. And the total time that you're able to do deep work is longer, the chance of achieving Flow much higher.

Action - "Always Default to Action!"

This is the very last tenant of going Async. It's not about procedure, it's about attitude.

There are many times when work isn't ready for us to tackle, tasks aren't planned, decision makers aren't online, etc. In these times, successful teams execute, even if they later have to refactor and adapt, they don't waste time "waiting".

"Always default to action" is a mantra we keep on repeating at Remote. This means that if you need to do something and no one is there to help you out or to point what to do next, then you use your common sense and pick something up yourself.

Imagine there are 3 tasks, and only 2 are perfectly described, so you need to wait for a product manager be available to define precisely what's required.

In Example 6 we show that example through Dev 1 being someone that defaults to action and Dev 2 someone that defaults to waiting. In what we just described as "always default to action", Dev 1 will pick up something else, even if not as important as the task he was hoping to tackle. Dev 2 however decided to wait for the PM to be back to help describe such task.

At Remote, we expect you to plan for these async delays and use your time wisely.

Summary

Async work is a way to organize how to get stuff done with less interruption and higher efficiency based on a few ideas:

1. Async work should be used more often than sync work, it provides better resource management, reduces waste and therefore optimizes productivity.
2. Multiplexing your tasks and reducing scope allows you to deliver faster, test your hypotheses sooner and achieve success with higher confidence
3. Communication should be async most of the time and only here and there be sync with things that definitely require you to do so. Keeping this as a rule of thumb allows people to focus on their tasks longer and concentrate on best practices like documentation and writing proper procedures.
4. Always defaulting to action (within reason) helps the whole team move faster, reduce wasteful times and increase ownership.

This is inspired in the Toyota Production System 3Ms methodology; more information about that here.