The Covid pandemic forced many companies to unwillingly transition to remote work, thinking of it as a temporary necessity. However, at least in tech, remote work has become the new normal.
But… Is switching to remote work just a matter of working from home and using Zoom? Simply replacing the physical meeting room in the office with a virtual one? Or is it deeper than that?
Many first-timers working remotely fail to realize that the key paradigm shift which remote work enables is “async work”; beyond the distributed, “remote” aspect itself.
This means that not only working from the same office is not needed, but also, that we don’t even need to work at the same time (for the most part).
However, since this async bit is less obvious, we will dig further into it in this article.
Overcoming physical limitations
Of course, enabling remote work is a prerequisite to async work. And working remotely has some minimal requirements on its own, which are worth reviewing quickly first.
Those of us working in the digital realm have no physical constraints to our work, apart from the very minimal ones: table, chair, computer and internet connection. Beyond that, we only have the artificial constraints that some companies (or ourselves) impose, either consciously or unconsciously.
If you work in software development, or, really, in any other knowledge-intensive job that doesn’t require specific physical elements to it; you don’t have to work from a particular location. This has been the case for quite a few years now, but collectively we seemed to need a pandemic to fully realize.
So, what do digital workers and companies really need?
- Computers, meeting the hardware requirements of the work, including a webcam and a microphone.
- A tool to chat, which should also allow grouping conversations in channels / topics and threads, to make them manageable.
- A tool to meet, supporting both video and audio; and with the ability to record meetings.
- A tool to organize and track work (to create to-do lists / backlogs; set status to items: pending, in progress, completed; etc.).
- A tool to keep and share work-related knowledge.
Some useful enhancements
- A good microphone, camera and headset, beyond the built-in ones in your computer:
- Video and audio quality are very important for a successful remote communication. Especially audio when you have many non-native speakers in the team. But also video, since non-verbal cues are a key part of human communication.
- Enough screen real estate:
- To me, screen real estate is never too much.
- Personally, I have two 28” monitors that I use constantly (e.g. one with the chatting tool and another one with a browser; or one with a browser and another one with the IDE). I use big font sizes, as my sight is not my greatest strength. So having two large screens really helps me.
- Also, I find my 2 big screens very useful for remote meetings. I can keep the general participants’ view in one of my 28” screens (letting me see all, or most, faces); while also keeping another screen either for whoever is speaking at a certain point or, especially, for the shared screen of whoever is presenting.
- Additionally, I also keep my 16” mac screen on a side, for secondary things such as music (Spotify), for instance.
- In meetings, I also benefit from having this third monitor, to keep our chatting tool (Slack) handy there; or a browser window, useful if I have to search for something while in the meeting.
But, even though this minimal setup is important, some people focus too much (or solely) on tools, and often forget the essential (and more complex) process changes. These are really the key to make the most out of distributed, asynchronous team collaboration.
So, what are the best practices to work effectively as a fully distributed, asynchronous team?
Beyond the minimal setup described above, some of the key practices to really be effective as a fully distributed and asynchronous team include:
- Minimizing sync times, and planning meetings ahead. Letting people have time to organize. Also, being mindful of the best overlapping hours of the attendees (as they are likely to be distributed across multiple timezones).
- Recording meetings by default, as they are a great source of documentation later on.
- Moving to written and async communication by default:
- Written communication forces us to think more about the ideas that we want to convey; and also to be more careful expressing them, since our words are going to remain there, readable for a long time, and often visible to many.
- By using channels and threads properly, in our chatting tool, we can avoid unnecessary noise, while also creating a great searchable knowledge-base for all coworkers, automatically.
- Using digital-native tools to cover all aspects of work.
- E.g. in Software Development:
- Github, or an equivalent advanced application built on top of SCM tools:
- These are also tightly linked to written communication; e.g. in the form of PRs and their reviews, where a lot of async collaboration happens organically.
- Jira + Confluence; Notion, or similar:
- For a more formal organization of work, planning and documentation.
- Slack / Microsoft Teams / Email:
- For direct, mostly async, communication; per teams, topics or 1:1s.
- Github, or an equivalent advanced application built on top of SCM tools:
- E.g. in Software Development:
What is the minimum number of synchronous meetings needed?
Assuming you are an individual contributor (IC), a minimal set of synchronous meetings could be defined by:
- A planning session of 1-2 hours held once every 2 weeks (or whatever the duration of cycles that best suits your team is).
- A 1-2 hours check-in meeting in the middle of every cycle.
- A 1-2 hours review + retrospective session at the end of the cycle, one or two days before the new planning session.
- Honest retrospectives are extremely valuable; especially if all team members feel free to speak their minds, and all are trying to collectively improve processes and align, constructively.
The previous list is really what I consider to be the minimal set of sync meetings necessary, but some useful additions could be made, such as:
- A 1-2 hours meeting, at some point during the cycle, used as a longer-term planning session, in which to refine upcoming work; to keep a “ready” backlog and thus ease upcoming cycle-planning sessions.
- 1:1s with your manager, every other week or once a month, for 30 mins. And maybe similar meetigns with some other key team members as well.
- Some less frequent meetings such as:
- Quarterly planning meetings.
- Yearly planning meetings.
- Some especial, focused meetings, that might be required when starting a new initiative / project.
Also, I am a big fan of open, transparent companies; and I’ve been lucky to work at both CloudBees and Turo recently, which fit that category. In these cases, so-called “all-hands” meetings are held every other week (or every month), typically lasting less than 1 hour every time. And I find them extremely valuable, to align the whole org (e.g. engineering) and/or the whole company. But in these meetings, which are usually recorded, the average IC is most likely going to be a listener. So they don’t really qualify as a “sync meeting”; even though attending these sessions live has many benefits, including being able to participate (either commenting or asking questions).
So, summarizing: If we take a quick look at the list above, necessary sync time translates to a range that goes from 3 to 10 hours per week.
Assuming the regular 40-hour work week, that means that only between 7.5% to 25% of the time has to be synchronous; while 75% to 92.5% of our work time can be fully asynchronous.
What about the social or human side of work?
This is a key aspect to take into account. Working remotely and asynchronously doesn’t mean we become robots. Making the workplace more “human” and developing some social ties with coworkers doesn’t require being in an office setting; and it doesn’t even require working synchronously.
Having said that, spending some synchronous time in social events is definitely good, maybe just a couple of hours a month. And even seeing each other in real life one or two times per year is definitely very positive.
Let’s try to summarize my take on the social side of remote and async work.
Include some remote-friendly social activities
Some that I’ve been part of and consider valuable include:
- Social synchronous meetings, maybe 1-3 hours per month:
- They should definitely be optional for team members, but I highly encourage everyone to participate.
- You might also consider recording them, so that those that were not able to attend can watch the recording and feel integrated, keeping the social context of the team.
- In our case, we currently have 2 remote-but-synchronous social activities per month (both optional):
- One casual social meeting. In this one-hour meeting we can talk about anything other than work. We often bring 2 topics beforehand, as placeholders, but discussion can move away from those topics entirely. We have also had meetings in which we have formed teams to play online light games, such as GeoGuessr.
- A two-hour Coding Dojo session, where a team member proposes and facilitates a code kata (or architectural kata) and we work together on solving it. We might break the group down into multiple ones depending on the number of attendees. At the end we share learnings, comments, suggestions, etc. This is applicable to us as an engineering team, but I’m sure other teams can find equivalent types of activities.
- Social channels in your chatting tool about common interests:
- E.g.: board-games, cooking, travel, series, you name it…
- Have regular, short 1:1s with your different teammates; just to chat a bit and discuss things other than work, to keep a human connection. Even spending half an hour per month on an individual call with each of your closer teammates can already make a big (although subtle) difference in the daily work.
- In a remote setting, most of the casual conversations that often happen in an office are lost, so forcing them a bit via 1:1s helps compensate for the loss, and lets us build human relationships with our colleagues.
Spending some in-person time periodically is a good idea
In my last two companies I’ve been working fully remote, and in both cases we have usually had at least 2 opportunities per year to meet face-to-face. In my experience, those events tend to be very energizing, and make me feel much more connected to both my peers and the business. I always come back home highly motivated.
So, meeting for a week or two, every six months or so, even though it is not really essential, I would say is highly recommended. Or at least once a year, to keep the human connection with colleagues. These in-person events can range from simply spending some time working next to each other, to having a company-wide event with talks from different areas. The latter has the additional benefit of breaking silos, letting us learn more about other teams and meet people we don’t often work with. Plus, spending some company-wide, in-person social time, is a great way to devirtualize (and humanize) people with whom we may have chatted (or even met in a virtual call), but who we have never seen in real life.
The benefits of distributed and async work
Ok, so far we have covered the needs remote teams have. We have also discussed the minimal time needed in synchronous calls. And we have gone through some tips on how to promote a healthy remote and async work environment.
But, why would we want to do all this? Are there any real benefits to it?
A productivity booster
Interruptions are a real productivity killer. I’ve suffered this in the past, working from an office setting. There is often the classic coworker that comes to your desk to ask a not-that-important question, every now and then; interrupting your flow (which maybe took an hour to get going), and now causing you to put extra effort, for the next 20 minutes, trying hard to get back to where you were.
And since there are many of such interruptions during a work day, several hours per day are wasted daily in offices, on average, due to interruptions. With the cost it has both directly (wasted time) and indirectly (negative effect on morale and, as with any other distraction, increased mistakes).
In contrast, by switching those questions to whatever chatting tool you use remotely, they become asynchronous, so you can keep your focus and then reply whenever you finish what you were doing (or whenever you voluntarily decide to switch focus).
If you want to learn more about the cost of interruptions, you can read some articles on it, including scientific research. Interruptions are definitely a big deal.
Another productivity-related benefit of remote and async work is that it forces us to schedule meetings beforehand. This typically leads to time optimization, preparing an agenda and agreeing on the need for the meeting to be held; avoiding unnecessary meetings and spending the minimal time required in the call, with the minimal number of people necessary.
Also, when meetings are recorded, people can decide to skip them if they don’t feel their presence is needed; and can always watch the recording if they feel something relevant was discussed. Recording also allows viewers to skip sections of the meetings that are not relevant to them, or play them at a faster speed, while maybe doing something else (especially when the meeting is not critically important and they only want to have an idea of what was discussed). This also leads to saving time, and being more efficient at work.
Access to a wider talent pool
This one is rather obvious. If you are hiring people that will need to go to your office every day, you are limited to people that live in your area and are willing to commute to the office daily (or most days). And / or to some people that might be willing to relocate.
When you switch to remote work, though, you expand significantly. At least to people that work in similar time zones but are far enough to not be able to commute, or people that, for different reasons, have issues getting to the office (not having a car, avoiding traffic jams, etc.). However, if you require synchronous presence of team members despite being remote, you are still imposing a big restriction on your candidates pool.
But when you go one step further, from remote to async work, then you can expand anywhere, despite having almost-incompatible timezones (provided the minimal sync time can be arranged). This switch lets you access the global talent pool almost without restrictions.
Real flexibility to separate or blend life and work
As a parent, I really value the flexibility that remote and async work brings to me. I can arrange my work day so that I can take my kids to school / day care, and/or pick them up; working in between. I can also have a quick walk with them in the afternoon while there is still sun; and then I can work a bit when they are asleep and it is quiet at home.
Your preferences might vary, and you might prefer to have a clear separation between your work and personal time. But the key here is that remote and async work lets you decide how you organize your professional self in the way that best fits your life.
Some interesting resources
Of course I’m not the first person to write about this, by any means. I’m simply sharing my experiences and views on this, to me, important topic.
Having said that, you might find other experiences and views useful. So I’m adding below some related articles, from relevant voices:
- Asynchronous Communication and Why It Matters For Remote Work, from Buffer
- How to embrace asynchronous communication for remote work, by GitLab
- What Is Asynchronous Work? Here’s Everything You Need to Know to Implement It at Your Organization, from Lattice
- A Twitter thread by Sahil Lavingia, on Gumroad’s transition to fully asynchronous work
- One article on “Why you should be working asynchronously in 2022”, from remote.com
Convinced?
Did I manage to convince you? Or not at all? Or were you already convinced?
What has your experience been with remote and async work so far?
I’ve probably missed some relevant points; and you might have encountered challenges that I’ve failed to mention (and which might be interesting to discuss). You may also have discovered better socializing approaches in these remote and async settings, or you might know about other tools/tips/processes that ease the transition for more traditional companies.
So, please, join the conversation in the comments and let’s keep discussing this interesting topic, remotely and asynchronously!
Significant revisions
2023, Jan 02: Some general style improvements.
2022, Dec 31: First version published.