Engineering — 2 min
Asynchronous (async) work is a way for workers to organize the order in which tasks are executed to align with their own timetable. In asynchronous work, communication is not expected to be immediate, meaning workers can fine-tune work to reduce pressure on themselves and their colleagues. Asynchronous work relies on three main tenets: Multiplexing, Communication and Action.
Asynchronous work refers to the practice of working on a team that does not require all members to be online simultaneously. When you work asynchronously, individuals can maximize their productivity without waiting for others to complete tasks. The key to asynchronous work is creating processes that allow employees to work autonomously and providing employees with the trust they need to do so.
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.
Asynchronous work maximizes production by decoupling work from synchronous communication. Synchronous work tethers progress to communication, forcing teams to halt progress on projects when one of the team members is unavailable due to different work hours or time off.
From a results perspective, asynchronous work demonstrates massive benefits compared to synchronous work. Companies that embrace async are able to move projects forward much more quickly than their competition. In addition, businesses with async workflows tend to have higher employee morale, thanks to the trust and increased communication and documentation practices necessitated by an async approach.
Managing async workflows requires companies to rethink what it means to measure productivity and trust employees. To that end, async work relies on three main tenets: Multiplexing, Communication and Action.
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.
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 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.
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.
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 two people. An engaged conversation can take multiple forms:
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 communication, 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.
Asynchronous communication empowers independence. It focuses on making sure that a task and its effects are independent of whoever planned or executed it.
Asynchronous communication brings/enforces some of the long-sought best practices, such as:
Example 4 with the same two people (as example 3) developing a set of tasks but resorting to asynchronous 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.
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.
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.
Async work is a way to organize how to get stuff done with less interruptions and higher efficiency based on a few ideas:
Subscribe to receive the latest
Remote blog posts and updates in your inbox.