Asynchronous Communication And The Curse Of Knowledge

  Saturday, January 25, 2020

The curse of knowledge is a cognitive bias that occurs when an individual unknowingly assumes that the others have the background to understand.

The Curse Of Knowledge In Action

A common occurrence in my workday is receiving a message like so:

Do you think it is okay to increase the limit from 40 to 50?

Receiving such a question often leaves me puzzled.

I’m missing context. I don’t know what limit is being talked about. I don’t know why the person asking the question wants to change it.

When that happens the curse of knowledge is partly to blame. The other person assumed I’d have the knowledge to understand.

In the best-case scenario I ask for clarification and help the person out without falling victim to the curse of knowledge myself. But as is often the case with cognitive biases, knowing about them doesn’t necessarily prevent you from making the same mistake.

I might give an answer that the recipient, in turn, is unable to understand.

Synchronous Communication: Fast Error Correction

When talking face to face or in a video call, the scenario mentioned before is not all too bad. Synchronous communication has low latency and high amount of signals which we can use for error correction. By reading the body language we pick up if the other person acts confused. We notice a change of tone. This helps mitigate misunderstandings.

Asynchronous Communication

Asynchronous communication is when you send a message without expecting an immediate response.

This has a lot of advantages and some people think this is the reason why remote workers are more productive. I somewhat agree with this notion.

But it is not without downsides. The scenario mentioned earlier played out asynchronously:

My colleague:

Do you think it is okay to increase the limit from 40 to 50?

Me, 1 hour later:

Sorry I was in the tunnel. What limit?

My colleague, another 30 minutes later:

In the job configuration I’m working on

This could go on like this for a long time, making asynchronous communication ineffective.

Each round-trip comes with high latency. Depending on the type of conversation and participants it can range from several minutes to several hours or even days.

Reduce round-trips: Give Enough Context

For asynchronous communication to work well, it is crucial to include the relevant context when asking questions or communicating information.

If you reach out to a colleague for help you’ll most likely have spent some time thinking about the problem you’re trying to solve. That means you have a mental model of the problem.

The other person won’t have this mental model. And it is in your best interest to help the other person to re-build this mental model.

That’s challenging. Some of the things that seem to work for me (When I remember to do them):

  • I make myself conscious of the amount of knowledge I have already built up.

  • I try to expand the scope and create a narrative. I lead with what I was working on. Followed by elaborating on the issue I encountered. I include assumptions that I’ve made about the problem. I include what aspects I’ve verified. If I’ve potential solutions I mention them as well. If I have concerns about the solutions, I include them.

  • While doing so I try to use precise words. I don’t say “it doesn’t work”. I explain the observed behavior and expected behavior. I include exact error messages.

  • I try to imagine what the other person already knowns and try to anticipate questions. I try to answer them already.

  • I pause a couple of minutes before sending the message and re-read it. Often I notice that some sentences are difficult to understand.

Even with this in mind, misunderstandings will happen, whether you’re communicating synchronously or asynchronously. The question is how to notice the misunderstanding early. Active listening plays a crucial role here. Try to rephrase your interlocutor’s point. Ask questions that challenge your understanding.

For software development this is where one of the key ideas of the iterative development comes into play: Share your work early. There are many ways to do that. One option is to share an outline of a solution before starting with the implementation. That could be done as a visual sketch, or it could be a pull request that contains enough of the change to get an idea where it is headed.