by Marcelo on

Asynchronous (async) work is a way to organize the order in which tasks are executed in the pipeline of work. It allows you to fine-tune work, so that pressure is even, tasks are completed swiftly and you stay nimble.

An even, swift and nimble pipeline produces exactly the right quantity of output for its requirements, and all its stages are balanced in terms of efficiency and speed. Resulting in no waste of time or resources. This is inspired in the Toyota Production System 3Ms methodology, more about that here.

Async work relies on three main tenets: Multiplexing, Communication and Action.

Multiplexing

Human beings exist in a synchronous world, we are bound by time moving forward one second at a time. However the way we do things (or put things together) has an insane amount of impact on the outcome of our pipeline. It’s all about planning.

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.

This image represents a three terminal software development pipeline organized with sync planning. To deploy a feature we need tasks A, B and C to be completed. Given the way that these tasks were planned for and distributed we will require a cycle of 9 work hours per deployment. This is great for atomic tasks, but very slow otherwise as we’ll only be able to deploy every so often.

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 representation, by separating Tasks A, B and C in (A1, A2, A3, B1, etc.) we achieved three times as many deploys as in the previous example (M1). 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.

Communication

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.

Sync communication

Synchronous communication is the one we are most inclined to because it’s easy and more comfortable in a way.

A conversation (usually) requires at least 2 people. An engaged conversation can take multiple forms:

A meeting

A video/voice call

Getting a coffee

Chatting at lunch

Messaging someone and expecting an immediate response

All these are great options for things that can’t be done in any other way, or are way harder to do asynchronously. For example, a performance review, strategy discussion, interviews, 1-1s.

Most meetings can be replaced by proper documentation, well-written emails or messages.

Meetings are the most expensive tool your company has, use them properly.

In Example 3, two devs working on their own tasks and needing to complete set of tasks (A,B and C) before deploying:

This example happens so many times, in this case a meeting about a tech requirement interrupts both devs for a fixed amount of time, and soon after another call about what someone should do next.

This is definitely not the best use case for sync comunication, the interruptions delayed all work and no deploy was done.

If we think about the efficiency of our pipeline, it was definitely uneven and everything but swift.

Async communication

Async communication empowers independence. It focuses on making sure that a task and its effects are independent of whoever planned or executed it.

Async communication brings/enforces some of the long sought best practices such as:

Good documentation

Written procedures

Messaging over calls

Respect for interruption-free work slots

Example 4 with the same two people (as example 3) developing a set of tasks but resorting to async communication.

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.

Why though?

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 comunicating 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

This is the very last tenant of going Async. It’s not about procedure, it’s about attitude. It’s about caring about where you’re going as a whole and yourself as a professional.

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.

This example is anecdotal and I wish I would say it’s an exaggeration, but it’s not, it’s a very common place.

At Remote, if you really need someone to help you with your next task and you really can’t pick up anything else, well, it’s better to use that time to take care of yourself like going to the gym, walk the dog or watching your favorite show (yes even throughout the day).

This implies a bit of better judgement, of course, some tasks are very sensitive and if you’re not sure about those, then you can pick up something else. It’s not about ignoring risk, it’s about taking charge in a controlled way.

In summary

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

Async work should be used more often than sync work, it provides better resource management, reduces waste and therefore optimizes productivity

Multiplexing your tasks and reducing scope allows you to deliver faster, test your hypotheses sooner and achieve success with higher confidence

Communication should most of the times be async 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.

Always defaulting to action (within reason) helps the whole team move faster, reduce wasteful times and increase ownership.

If you have a different opinion or thoughts on this I’d love to hear about it! You can find me on twitter @marcelo_lebre or e-mail marcelo at remote.com