4 steps to achieve Asynchronous zen

Asynchronous work is not new, but it has found widespread adoption in the wake of the pandemic. Here are some steps you can take to ace it.

I was in a painful meeting last week, the host was very well prepared but many others were not. The host had to spend time explaining the complex detail before anyone could make a meaningful contribution. It was quite painful to do via video conferencing. I couldn’t help but feel a little disappointed. The audience should have been more mindful about the basic premise of asynchronous remote work. Empathy!

Let’s discuss some levers that will make asynchronous work, work 😇.

1. Commit as a team to asynchronous practices

Whenever I hear “asynchronous”, I go back 17 years (!) to my computer networking class at University. I remember being fascinated by TCP and UDP protocols. In case you are not familiar, these are communication mechanisms at the heart of the internet. TCP is used for accurate, reliable and relatively slow connections, whereas UDP is used for relatively fast but lossy connections. The key thing to note here is that UDP is fast, because it is asynchronous i.e. does not need to establish a connection with the receiving computer.

asynchronous protocol
Crude but effective description of an asynchronous protocol

In a remote setting, you need to reduce handshakes with others and achieve an “independent” state of productivity similar to a device using a UDP protocol. This is what I mean by asynchronous work. Let’s unpack this a little.

“Communication stress grows exponentially the larger or more distributed you are. With that, it’s significantly easier to mis-communicate or misinterpret. It’s important to create clear processes with clear intentions, which will reduce the amount of additional stress you feel internally.”

Threads CEO Rousseau Kazi

Imagine that you are a solution designer working on an app. In an office setting, you could gather around a whiteboard with engineers, product managers, and come up with design options. You might have multiple meetings until you agree parts of your design and then work on putting it all together. Remotely, this process would be cumbersome to replicate. Instead, you could use a collaboration tool to “build” a design artefact and then share it. Your engineering and product stakeholders can then review it at their own convenience and leave comments on different parts of your design. Your next iteration would take those into account and so on.

In my experience, this way of working if done right, is more efficient.

Think about it, your initial focus is on producing an artefact. You can get it to a higher standard as your work was relatively distraction-free. Also, since you are not forcing a time constraint of a meeting, people can review a more complete vision of your design at their leisure. Your focus as a solution designer then is iterating your design artefact rather than trying to get everyone on the same page.

People often do not play their part in asynchronous work (this is not necessarily malevolence) and they would rather wait for the next meeting before raising concerns. This introduces delays and stressors in the system. Key takeaway is to commit as a team to asynchronous. Otherwise, it just doesn’t work.

2. Leverage multiplexing

Let us go back to computer networking for a minute. Multiplexing is a technique in which more than one signal can be sent over a single medium, and the bandwidth of that medium can be utilised effectively. Multiplexing avoids the scenario of each signal having to wait its turn and therefore reduces delays.

With asynchronous time division multiplexing, time slots are flexible, and assigned when connected devices have data that is ready to send.

Asynchronous Time Division Multiplexing in Computer Networks

Now, let us apply this concept to asynchronous work. Imagine that you are the Lead UX designer for a mobile app, you are also completely remote. You need to design the next generation experience for this popular app. Fortunately, you and the product team have done a good job at defining features, user stories, personas, and you also have good research at hand. You allocate user stories to your team members and they work together in a design sprint. While this is typical for an agile team, your remotely distributed team demands more.

UX Design
Source: Unsplash, Author Amélie Mourichon

You have limited bandwidth together, and therefore, meeting time is very expensive and you have tight timelines. What you need, is a very effective way to break down your user stories into minimum viable changes (MVC’s), this gives the most autonomy to the designers working on your team, and allows them to ship small but frequent changes to experience design. For instance, when a designer is ready with their MVC, they can asynchronously review, iterate with product teams and ship.

To summarise, you can break down and then can combine (multiplex) multiple MVC’s to deliver greater complexity using the same bandwidth.

3. Call upon your deepest sense of empathy

The whole concept of asynchronous is not possible without deep empathy. Imagine that you are a product manager trying to convey a new feature to an engineering team. If you do not make an effort in articulation and you do not put yourself in the shoes of your engineering colleagues, you will not achieve your work objectives. You might miss critical scenarios or edge cases or worse assume a feature as feasible when it’s not. Also, you will then need to use the most expensive currency of your remote team – a meeting.

So, you need to anticipate, prepare in advance, and make an effort to write better, speak better and work in a way that is easier for others to understand.

If you are responsible for planning, or co-ordination, ask yourself a question. Is something really urgent? Most of the times the answer is no. In such cases, it is better to resort to asynchronous, thoughtful communication. If you communicate non-urgent things in an urgent manner e.g. via workplace chat tools, you induce unnecessary anxiety that your colleagues can do without.

The person working with you asynchronously does not always know it all. Try to make your communication as contextual and complete as possible. If you commit to review something in a week, do it. Leave helpful comments when you anticipate something, perhaps a new feature decision explained via a pro-active comment on Figma.

Asynchronous work puts the responsibility on you as an individual so think about how your performance is affecting the whole setup.

Have a deep sense of empathy towards your coworkers, humanise the process.

4. Know when to switch to synchronous working

There are things that should not be done asynchronously. Areas where judgment is involved are good candidates for start. For instance, think about a performance review. There are so many ways in which this conversation can go wrong if done via Google docs. You need to use that expensive currency (meetings). Other things include interviews, 1-1s, strategy decisions etc.

Another key thing to call out is mental health. Let’s face it – widespread asynchronous work is a relatively new territory. When you work for extensive periods of time this way, it can get incredibly lonely. In addition, lack of immediate feedback can induce anxiety. It is also upon you now to stay up-to-date, and effectively communicate. Some asynchronous communication can be taken out of context and exasperate misunderstanding.

It is so important to spend meeting time on building teams, address issues, and protect mental health of yourself and your teams.

If it’s not working for you, don’t push it.

Asynchronous work precludes water-cooler moments, and spontaneous group creativity.

Not that I am expert in this area but I’d like to spend quality time together with my team every now and then, in person. Bonding with them, perhaps arguing with them or better playing with them. I’d like to be able to discuss serious issues together, face to face with a cup of coffee!

To summarise, asynchronous helps the whole team progress faster, reduce waste and increase deep engagement with their work. My initial thoughts are to jump in, slowly explore and experiment. What are your thoughts?


  6. A whole section could be written about asynchronous tools but I’ll leave it to your better judgement to explore.

I'd be excited to know what you think?