In an all-remote setting, where team members are empowered to live and work where they're most fulfilled, mastering asynchronous workflows is vital to avoiding dysfunction. It also enables team members to be on equal footing as other team members globally.
According to McKinsey & Company in-depth analysis, remote work potential is primarily concentrated among highly skilled and highly educated workers in a handful of industries, occupations and geographical locations.
Finance and insurance, management, business services, and information technology have the highest potential for remote work without a loss of productivity, all with more than half of time spent on activities that could effectively be done remotely.
As everything work related, remote work (especially in IT and telecommunications) has its numerous pros and cons, but most can be summed up to a couple of them:
One of the biggest challenges facing this remote age is effective remote team communication and distribution of work. One of the relevant solutions to this particular challenge is asynchronous work.
Asynchronous (async) work, in short, is "a way to organize the order in which tasks are executed in the pipeline of work". Although remote work in its nature often involves a lot of asynchronicity, these two terms are different but intertwined. Async work tries to benefit from balance in terms of efficiency and speed, resulting in no waste of time or resources, and in that manner should be the preferred way of getting things done where possible.
Asynchronous working requires some forethought and planning. But what does it actually include? Here are 3 main principles of async working: Task division, Communication and Action.
A simple example would be a car factory where raw car parts are placed on the input of the process and a finished car comes out on the output end. Factory assembling the car can either assemble a car fully and continue on assembling another one (called sync planning) or it can assemble multiple partial structures of the car more quickly before passing it further down the assembly chain (called async planning).
In the image below, we can see a pipeline with 3 tasks, waiting to be finished in a synchronous manner. If we want to deploy a feature consisting of tasks A, B and C, we need to wait for 9 hours for each task to be finished before deployment, if each task takes 3 hours. For smaller tasks, this is the preferred way, but in other cases we will be able to deploy every so often.
Async planning relies on breaking the above-mentioned tasks to smaller chunks (A1, B1, C1) representing Minimum Viable Changes, and deploying them as frequently as possible. By doing this, we rely on the assumption that shipping smaller chunks and more often allows us to measure success and jump more quickly on any negative feedback.
In the example above, we managed to deploy a feature 3 times more frequently than in the previous example. Dividing the tasks into smaller and meaningful chunks allowed us to release parts of our tasks and because of it, we were able to validate their impact and rollback/reassess the next steps.
We humans are not very good at going from "full focus on task A" to "full focus on task B" without loss of focus and concentration. Below is an image of a chart consisting of Time (x-axis) and Productivity (y-axis), displaying how a developer working on a new endpoint implementation gets interrupted by a less experienced developer vs his time being focused at development.
As observed, it takes time to enter the zone, and takes time to stay in the zone. If "the zone" is a mental state where we are productive the most, interruptions add to the time wasted to focus and refocus, thus reducing the time where can we be productive.
Asynchronous communication is defined by messages that aren’t shared or received in real-time. Most common ways teams implement asynchronous communication and collaboration are through these methods and its tools:
With reduced reliance on synchronous meetings and messaging to get work done, workforces see increased productivity, time for deep work, and thoughtful responses, while enabling a more seamless employee experience regardless of location and time zone. These benefits create a more inclusive and supportive environment allowing for both introverts and extroverts to contribute equally and allows individuals to optimize their workday for their own personal efficiency preferences.
Action is all about attitude, about caring, where you are heading as a person - both privately and professionally.
In theoretically perfect world, there would be no process, no meetings, no forms, no reporting. Instead, there'd be the creation of exactly what customer wants, even if the customer didn't know they wanted it yet.
Reality? Imagine working on 3 highly prioritized tasks, of which 2 are well described and the last is not described that well at all - missing some requirements, UI work waiting on backend team to finish an endpoint, product manager being busy and having no time to describe it better.
How to act in this not-so-imaginary situation? Should one just wait for the tasks to be planned well?
Successful teams always default to actions and waste no time, even if they have to refactor or adapt later on. This idea is highly aligned with Deming's PDCA cycle: Plan so to avoid wastefulness, Do tasks evenly and with a sense of balanced work, Check for irregularities, Act with the will, motivation, and determination to do all that.