Pesto Blog

Asynchronous communication is also distracting

Doug Safreno
Doug Safreno
Feb 27, 2020 - 6 min read
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:

  • Work on task A for 30 minutes
  • Get blocked, ask a question
  • Context switch to task B, work for 30 minutes
  • Get blocked, ask a question
  • Context switch to task C
  • Get answers to A & B
  • Switch back to A

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.

  • If they should be primarily making, transfer the knowledge and decision making authority to a "manager," so that they can make effectively without disruption from other makers.
  • If they should be primarily managing, reduce expectations on productivity and emphasize communication. They won't have much focus time.

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

  • Minimize scheduled meetings. Scheduled meetings are in some ways the worst form of synchronous communication because the requester doesn't get an answer immediately and the receivers can't respond on their own time.
  • Don't overload managers. Overloaded managers will have to respond to makers asynchronously to stay above water, blocking the makers and thereby harming their productivity. Enabling them to receive synchronous communication is key to maker productivity.
  • Take notes. Notes, documents, etc. distribute knowledge such that future employees can access it synchronously without forcing manager's to bear the cost of context switching. If a context switch has to occur, it's best for the manager to bear it, but reducing context switches in general should always be the goal.

How to encourage this communication in Pesto

I'm the co-founder of Pesto, a virtual office for remote teams.

For our users, I recommend that "makers" aggressively use our status feature to create 2+ hr blocks of "focus time."

"Managers" should integrate their calendar to automatically show blocks of unavailability while otherwise being as available as possible for synchronous conversation. Since managers need some focus time too, I recommend at most one hour, generally either the first or last hour of the day, to maximize continuous availability.

If you're not a user and are interested in learning more, click here to go to our homepage. Pesto is currently free while in open beta.

We worked remotely on top of a U-Haul

We worked remotely on top of a U-Haul

Vivek Nair
Vivek Nair
Feb 12, 2020 - 11 min read