Feb 27, 2020

Asynchronous communication is also distracting

Asynchronous communication is heralded by many as the answer to distraction culture. Turn off your Slack, turn on your "Do Not Disturb," and just deal with everything later in bulk.

In this article, I explain how asynchronous communication can actually distract workers by resulting in significant context switching, particularly for junior makers. Then, I explain how to balance synchronous and asynchronous communication.

If synchronous = interruptions, asynchronous = getting blocked

I come from a software engineering background, and software engineers get stuck all the time, especially junior engineers or engineers who are new to a company.

Companies assign new engineers a mentor, who is responsible for answering questions and generally getting the new engineer up to speed.

I've been fortunate to have several amazing mentors over the course of my early career, but in one particular circumstance, the mentor was constantly overwhelmed with requests from other mentees (and his other work).

As a result, my day looked like the following, over and over again:

Context switching kills productivity. During this particular ramp-up, I constantly felt distracted because I was constantly switching between different tasks. As a result, I ramped much slower than I otherwise would have, and I was less productive and happy during that ramp period.

I'm not alone on this; any software engineer who has had an overworked mentor will share how frustrating of an experience this can be.

Generally, asynchronous communications (whether due to an over-burdened mentor or team communication policy) hurts the junior members of teams.

Asynchronous is a redistribution of focus time

Consider the two sides of any communication as requester and receiver. The requester needs something from the receiver, whether a decision, information, or advice. There may be multiple receivers, but generally there is only one requester.

When someone answers a question or makes a decision asynchronously, they essentially force the other side to bear the context switch, rather than themselves. In other words, asynchronous communication redistributes focus time from the requester to the receiver.

To make this more concrete, imagine a mid-level maker (e.g. an engineer) has to do 1 hr of receiving communication and 1 hr of requesting communication over the course of a day.

In synchronous communication, Person A requests Person B, and Person B then bears a context switching penalty. As a result, this maker's day looks like the following:

Not ideal. The 4 15-minute interruptions to the maker's day adds an additional two hours of context switching cost (assuming 30 min in lost productivity per interruption).

In asynchronous communication, the maker is never interrupted by inbound communication. However, all outbound communication is blocking, forcing them to context switch to other work. As a result, their day looks like the following:

Not optimal either. This graphic basically shows my life on-boarding to a code base asynchronously. Even worse, there were times where I was blocked on every thread of work I had, and I then became blocked on getting new work because my mentor and manager were busy.

The optimal for a maker would be to do all inbound communication asynchronously and all outbound synchronously. They'd never get blocked or interrupted.

Is this possible though? Doesn't every synchronous outbound query interrupt someone else's day? I actually believe most teams can get most of the way there by emphasizing a few behaviors.

Give the focus time to the makers, not the managers

The most important thing to emphasize is that the makers, not the managers, should have the focus time.

Paul Graham, in his blog post "Maker's Schedule, Manager's Schedule," explains why Y Combinator want founders (the "makers" of YC) to be productive rather than the VCs (the "managers"):

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That's no problem for someone on the manager's schedule. There's always something coming on the next hour; the only question is what. But when someone on the maker's schedule has a meeting, they have to think about it.... I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you're a maker, think of your own case. Don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Since managers are constantly context switching anyways and don't need very much deep work time, they should send requests to their makers asynchronously but receive synchronously. Therefore, they bear as much of the context switching as possible.

Delineate roles well

Many of the people most frustrated with synchronous communication are senior makers.

Yet, from a communication perspective, these senior makers often behave more like managers. They give advice, share information, and make decisions for more junior employees.

A key to success is to, as much as possible, delineate whether such a maker should behave like a maker or a manager.

This is not a silver bullet. In many cases, there are good reasons for someone to not be well-delineated, e.g. someone early in the company who has written a lot of code but wants to continue to be a maker. But they will invariably deal with lots of communication friction if they don't knowledge-share their work to another manage who can effectively handle the synchronous communication for them.

Other keys