Hacking Asynchronous Communication as a Remote Team Member

When teams have to collaborate across different time zones, communication becomes a completely different animal. Understanding and addressing the challenges of asynchronous communication is essential to run distributed teams successfully - but it takes some effort. Here’s my experience and what I started doing differently.

My team at JourneyApps builds customised business process applications for large corporates that are headquartered in Europe and North America. Most of our developers, however, are based here in Stellenbosch. There are two constraints that shape our work environment:

• The need for domain knowledge around each customer’s specific context: Our apps need to solve complex business problems, so each developer needs to understand the domain in order to deliver something valuable.

• Fast builds: For competitive reasons, we don’t spend time writing specs but instead we build something fast, get it into the hands of our customers to get feedback, implement that feedback, and repeat.

Team-work across continents

For the past year, my team’s mission has been to prove that we can deliver these apps across the Atlantic. We’re set up as follows: I, as a developer, am based in SA whilst the rest of my team, two more developers and a team lead, is in the US. We all work on the same US-based projects.

Since I don’t interact with customers directly and miss out on communications between my teammates in the US, the biggest challenge for me was to ensure that I knew as much as everybody else on the team did.

Communication is already one of the harder things to get right in the work context. I however needed to find a way to communicate - and to communicate well - with colleagues based across the ocean in a time zone 8 hours away from me.

Hacking Asynchronous Communication

With “asynchronous” communication I am referring to significantly delayed responses. Nothing is natural about waiting several hours for a response that you (think you) need to get your work done! I quickly realised that understanding and addressing this would be key to succeeding in our mission. Here’s what I started doing differently:

Pull over push: Manage noise aggressively

Dealing with tons of incoming info is not a new problem. Most of us need to manage our email inbox on a daily basis. This problem, however, reached an entirely different scale for me with asynchronous communication. The amount of incoming info grew to new heights because most activity related to my projects happened during my night and I had to catch up every morning.

If I missed something important, the cost of that became extremely high. We could lose a full day’s worth of work and often had to spend time the next day(s) reverting the things that were wrong.

I needed to become quite aggressive about how I dealt with incoming info. For this, I came up with a guiding principle that I like to call pull over push: Essentially, I want to choose when and how to “pull in” incoming info rather than it getting pushed onto me.

Here’s what that looks like for me:

• Muting by default: In Slack, we have a channel for each project. If I don’t need to care about a particular project, I can leave the channel. By default, I mute every channel and only get notifications for direct messages or mentions. That automatically gets rid of a lot of noise.
• Scheduling check-ins: Most mornings I first attend to all direct messages and mentions. Then I read all threads that relate to a project I’m currently working on. The rest I simply ignore or browse through whenever I need to take a break. This also helps me to maintain context.
• Automating notifications: In my mind, all notifications that can be automated should be automated. For example: We use Trello to track progress. If I want to know what any of my colleagues have worked on and where they are at, I simply reference or subscribe to a Trello board. This way I don’t get any notifications about projects that I don’t care about.

Queue things for later

Similar to the previous problem, when I fail to respond to something important, we take a hit. Even responding to something that’s not important can help the person on the other side, so every day I need to make sure I respond to everything I can add value to.

I generally apply Getting Things Done‘s 2-Minute Rule to everything that I need or want to respond to: If I can respond within 2 minutes or less, I do it immediately. If not, I need to remember to get back to it later:

• In Slack, I right-click on the message to set a reminder for it.
• For emails (these are seldom), the fact that an email is still in my inbox towards the end of the day is enough of a reminder for me. In some cases I snooze the email for another day.
• For anything else that somehow landed on my horizon, I create a reminder in Slack.

Limit the mental stack of things to think about

One of the most distracting things are situations where I keep thinking about work that I couldn’t do anything about until I got feedback from someone else. This ended up taking up a lot of my mental energy and caused a lot of frustration. That’s why I came up with a system to:

1. Minimise delays and

2. Remove things from my thoughts until I get the necessary response.

Here’s what that looks like:

Double-check before asking

Firstly, when I leave something with one of my team members, it means it’ll be delayed by one day. I’d obviously want to be sure that I couldn’t have done more on my end to answer the question myself and get the thing sorted out much sooner! That’s why I’ve became creative about how I could gather more context to answer questions myself:

• I’d search our Google Drive folders, Slack channels or Trello boards for anything documented about the issue,
• I’d ask my colleagues in my own time zone for anything that they might know of and finally,
• I’d weigh the risk of simply making a call on my own.

Generally, if it’s easy to revert or fix a wrong decision later on, there’s little risk. So in those cases I choose to act now rather than park the issue.

Moving on

I only ask my US colleagues for help when neither of the above approaches turns up enough info or I don’t end up feeling comfortable making the call on my own.

Once I have left a question with my colleagues, it’s simply a matter of telling myself “move on, the ball’s in their court now”. Two things are important here:

• Firstly, my team needs to know that that is my expectation.
• Secondly, I also want to make sure that the issue doesn’t get lost in case the other person forgets to get back to me.

As a safety net, I usually set myself a reminder in Slack to check in on that issue or, if it’s less time sensitive, queue it for my next voice-chat with my respective colleague.

I now always respond with a kind of “roger that” when somebody leaves something with me. It really helps me to know that somebody read and acknowledged a task I leave with them, so I try to inspire them to do the same.

Make it easy for others to respond to you

The idea of “out of sight, out of mind” is one that I needed to accept early on: There are many cases where I simply won’t be heard, or my message won’t get through, because I’m simply not there.

What makes this particularly tricky for us, I believe, is that plenty of other colleagues are in the office that my team members in the US are in. My async messages compete with sync messages from my US-based colleagues or from clients, both of which naturally have a higher priority than mine do.

I figured one way I can get around this it to make it very easy for the other person to respond to me. Whenever I send something over to “the other side”, I ask myself the question: “How can I make it easy for you to respond to me?”

These are the things I now do:

• Write as concisely as possible I try to keep what I write as terse as possible; or have a TL;DR version clearly available. Keeping something short also forces me to focus on the important bits and write only what’s relevant. In asynchronous communication, people aren’t as forgiving when you waffle.
• Write as rarely as possible. I also ping someone less than I would have if that person were in the same room or in the same time zone. Similar to cases I’ve mentioned previously, these pings become noise or get lost much quicker during asynchronous communication than in normal situations.
• Be clear about your needs and expectations. When I have to write a bit more to provide context, I still make very clear what I need from the person. Usually, I write that part at the start, to set the scene correctly, as well as at the end, to remind the person of what I need.
• Point out urgency. If I’m not sure if something is urgent, but suspect it might be a critical issue, I also make that clear. The condition here is that urgent or critical things are not the norm. So I only call something urgent when it really is.

The impact these hacks have had

• Asynchronous communication is the new normal. I no longer think about it. It’s become my way of communicating with my team that I feel perfectly comfortable with. We still run into hiccups, but these are similar to those experienced through normal communication. Operationally, this is an obvious win because it means I no longer spend any energy on overcoming communication challenges.
• Minimal disruption. I can perform the majority of these hacks myself. They require very little changes in behaviour from others which allows us to move really fast. -We’re now winning quicker!
• Accelerated learning. Our setup has forced me to be a lot more independent, especially when it comes to making decisions. Previously, it was far too easy to rely on my colleagues’ guidance when I was unsure about something.

Now I have to predict and prepare myself for all kinds of unknown unknowns, so that when I run into them, I have enough ancillary information to make a call on my own. To me, this has been the most invaluable outcome from this mission.

Resources

• Trello - Project management tool we use within our team. We chose it mainly for its simplicity.
• Slack - We use Slack exclusively for internal communication.
• Google Drive and Paper - We love Paper for collaborative note taking and prefer Google Drive for everything else (file storage, spreadsheets, etc.)
• Notes - I use Apple’s Notes app for all of my notes. It’s easy to use on my phone so I always have it on me and my notes sync between all my devices. I can also take notes while offline (for some reason I get my best ideas in planes).
• GTD’s 2-Minute Rule - Helps me decide between the cost of doing something immediately vs. the cost that comes with queueing it for later.

Benita is a solutions engineer and team lead at JourneyApps where she enjoys creating highly valuable things among a group of really smart people.