I once heard that a “book worth reading is worth reading twice”, and I’ve found this to be true about other things as well. There’s a documentation page that’s been with me for the majority of my professional career; a page that I keep coming back to and that I’ve read from start to finish, without skipping a word, more than a few times in the last few years. This document is GitLab’s Embracing Asynchronous Communication guide, a section of GitLab’s public handbook that goes over their approach to asynchronous communication as a business.
To provide you with some context, as of writing this blog post, my role at SingleStore is Engineering Manager and I work with teams that are geographically distributed across a few countries (mainly the US, UK and Portugal). I have direct reports across these 3 countries as well, and prior to the COVID-19 pandemic, I was traveling to San Francisco a few times a year.
I started at SingleStore around four and a half years ago in San Francisco, but ended up deciding to relocate to Portugal and work there for the last three years. Being based eight hours away from the California time zone, I’ve learnt a lot about working across time zones, but mainly about how to work asynchronously, and all the principles behind async work are things that I apply and will apply in the future whether working across time zones or not.
Efficiency and inclusiveness
I fundamentally believe asynchronous communication leads to a more inclusive working environment because it allows individuals to work more flexible hours. Whether it’s because folks have to take their kids to school in the morning, or because a health condition prevents them from working continuously for 8 hours, working async allows us to more easily choose our working hours (and these may even change day-to-day).
Moreover, working asynchronously also allows an organization to more easily hire people in different countries and regions, which is key for diversity and inclusion. By not limiting hiring to a specific city or even country, it’s much easier to hire people with different backgrounds, races and nationalities. My colleague, Carl Sverre, discusses our own successful approach to building a team for remote work and additional considerations regarding asynchronous communication in this talk on geo-diverse team-building.
The added efficiency from asynchronous communication comes from various aspects. Perhaps the first one that comes to mind is allowing knowledge workers to block out “focus time” on their calendars to do things like preparing slides, writing and reviewing code, going through applicant resumes, etc. A great book on this subject, which I also recommend, is Cal Newport’s Deep Work. Focused work time is an invaluable tool toward getting things done and moving faster.
Another added benefit of asynchronous work is easier access to information (which also brings further transparency to the workplace), since more things should be written down in public as opposed to communicated 1:1 between 2 individuals.
Applying this in my day-to-day
The main principle of asynchronous communication that I apply in my day-to-day is not making assumptions about coworkers’ working hours. I may do a 9 AM to 5 PM in my time zone, but somebody else might prefer a very different schedule, even if they’re on the same time zone as I am. To help me not make any assumptions about the working hours of others, I do all of the following (and assume others do as well):
- Disabling any type of email or Slack/IM notifications
- Not having Slack or work email on my phone
- Not having an “online” status in your IM tool (i.e., setting yourself as permanently “Away” or permanently “Online”)
- Avoiding communication that feels synchronous in Slack such as “Busy right now, I’ll check this later”. In most situations, I prefer to just reply whenever I can properly reply.
These mechanisms encourage us to prioritize asynchronous communication and also to plan ahead to avoid needing quick or immediate unplanned feedback/help. More and better planning means less urgent things coming up throughout the week. Whenever I file tasks or write documents/emails, I put an emphasis on making sure that people don’t need to ask follow-up questions by including all needed information, and making communication as clear as possible. Writing well is one of the most important skills that one needs to develop when working in a mostly asynchronous environment.
Notice, however, that I do check Slack regularly (more often than email), especially due to the nature of my role and size of the team, but I check it when I want to, thus allowing me to focus on my deep work. Keep in mind that for certain positions (software engineering, site reliability engineering, etc.), an on-call rotation should be set-up with a tool such as PagerDuty to address urgent issues.
Another principle that I apply in my day-to-day is making sure that meetings are very well organized (which also helps with the aforementioned “better planning”):
- Never holding meetings without an agenda (with some exceptions) and sticking to it
- Taking notes alongside the agenda usually works great
- Having participants go through required reading beforehand, if there’s any
- Scheduling meetings only when necessary and not when they can be replaced with an asynchronous workflow
- Recording as many meetings as possible (Google Meet and Zoom make this quite easy)
Moreover, it’s very important to be able to fallback to synchronous mechanisms when it makes sense (and once again, this is really explained in the linked documentation page). For example, when new hires join our team, I shift towards a more synchronous working style with them until they’re more independent. We’re also working on trying to make our onboarding process a bit more self-service, but we haven’t gotten there just yet.
Finally, this style of work can lead to less human interaction, which can be addressed by holding informal events (such as games sessions, “remote coffees” and other things of the sort) to make sure team members are bonding.
Last words
This was an article that I’ve been meaning to write for a long time, as it’s a topic that I’m quite passionate about. I’d love to hear your feedback (both positive and negative), so reach out on Twitter or LinkedIn! Also, if this sounds like an environment in which you’d thrive as an engineer, we are hiring. You can find our open positions on our Careers page.
