This article is part of a series on remote working.

Consider this: what’s one of the most impactful skills that you can improve as an engineer? Is it your programming? Maybe it’s your debugging? I’d like to make the case that it’s your communication.

After all, software isn’t built in solitude. It is imagined, designed and implemented by teams of people. Being a better communicator will make you a better programmer. You write code for other humans. The compiler lets the computer understand it.

Communication skills will make you a better colleague, leader or manager. They will ensure that you are better able to find consensus around your ideas, designs and proposed architecture. Communication skills allow you to build rapport with your colleagues so you can develop your skills through constructive critique and feedback.

This has always been true, but it has never been truer in a remote world. Not only do you need strong communication skills that underpin your work, you also need to be able to pick the right tools and techniques to communicate the right way at the right times.

In the next few articles in our remote working series, we’ll explore some complimentary considerations for how and when to communicate. But we’ll start with looking at synchronous and asynchronous communication.

#define

Let’s start with some definitions.

• Synchronous means “existing or occurring at the same time”. When you have a conversation with somebody face to face, the exchange of information is immediate.
• Asynchronous is the opposite of synchronous. When you send somebody an email and they read and reply to it a few hours later, that communication is out of phase.

Typically, synchronous communication happens at the same:

• Time. This means that for the communication to take place, all parties must be interacting at the exact same time. This may occur without planning if two people met in a corridor, or it may require scheduling a meeting.
• Location. For communication to happen at the same time, it will often be in the same location. This could be a physical room, but it could also be a video call.
• Format. In order to exchange information immediately, all parties will use the same format, such as their voice and body language.

Given that asynchronous communication is the opposite, we could imagine that it could therefore happen at a different:

• Time. One person could send an email in the morning to another person on a different timezone, and they can then reply at their own convenience.
• Location. A message could be written on a phone whilst on a bus in Berlin and replied to via an email client on a laptop in New York.
• Format. That same email could generate some further thinking, which then generates a longer written proposal document to continue the discussion.

There’s another important distinction to be made first: it isn’t a binary choice between the two modes. It’s a continuum.

As you can see from the diagram, it’s rarely the case that something is purely synchronous or asynchronous. Often, it’s somewhere in between.

• Video calls or face to face chats are completely synchronous. Everybody involved needs to be somewhere at a specific time, since the communication is typically happening via voice and body language in the moment.
• Chat is written and is therefore less synchronous than a video call since it can be read later, however it has a short half-life because chats implicitly carry a temporal dependency. Are you catching up on a chat from a few hours ago? Sure, that makes sense. But are you reading through a chat from two months ago? It’s probably mostly irrelevant and noisy.
• Recorded video can be viewed later and requires more preparation than a chat, however its relevance decays fairly quickly (it’s also not searchable). A recording of a meeting from a few weeks ago, or a video updating everyone on the progress of an initiative probably won’t be watched again once it has been used once.
• Email is where we start producing more permanent asynchronous artifacts. Email by nature is archival and searchable, and is often used for important information such as delivering a confirmation of a raise, or confirming that a payment has been set up. Some people reply to emails quickly, but some take many days to reply, and that’s OK.
• A written document requires some effort to produce and may be used as the cornerstone of a project or proposal. Theoretically, a well-written document can last almost indefinitely, assuming the reader knows the date and context of which it was created for. Most online document software also allows collaborative editing and commenting.
• Wikis and READMEs are completely asynchronous, and typically have no interaction between the author and readers. If they are well-maintained, they can last, and be useful, forever.

The old world

When we primarily work together in an office, convenience and habit typically mean that we spend a lot of time on the left hand side of the spectrum. After all, when all of our colleagues are sitting across the room, it’s easy to go and have a conversation in the moment.

This is perfectly normal behavior, however it isn’t suitable for remote working. One could argue that it actually isn’t suitable for any company that has multiple offices, as this way of communicating severely limits the collaboration that can take place across multiple locations.

If you’ve worked in a large company, you’ve probably already seen the effects of synchronous communication being the default:

• Individuals are typically seated with their teams physically in the same office.
• Teams that collaborate frequently are often also located in the same physical location.
• The weakest bonds between different parts of the organization often occur when there is a geographical divide between them.

This can have a tangible and inconvenient effect on the software being created. Conway’s Law states that any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. When companies expand into different locations, opening another office to hire engineers might be an implicit design choice in how they architect their software.

They just don’t know it yet.

Shifting right

In order to fully embrace remote working, we need to shift our mindset and habits to the right of the spectrum.

Instead of choosing the convenient option, we need to choose to communicate in a way that enables an equal level of contribution from anyone, regardless of where they are located in the world.

Shift right.

That’s the habit that you need to instill in both yourself and your colleagues. Every time you communicate, can you purposefully shift right so that you better serve the needs of remote work? For example, could you:

• Turn a face-to-face conversation into an exchange in the team’s chat channel instead? This way, more people can have the opportunity to “overhear” what is being said and contribute to the conversation.
• Record a video call so that those that were unable to make it, or those that didn’t know that it was happening, are able to watch it back later.
• Decide to stop a long chat exchange so that it can be written up more thoughtfully and purposefully into an email?
• Take an email thread that is proposing an idea and turn it into a more detailed written document so that it can be read more easily in its entirety and then circulated for comment and consensus?
• Change an agreed upon idea in a written document and turn it into a more permanent wiki page that serves as the cornerstone of a whole project?

Shift right.

Every single interaction is an opportunity to shift right, and by doing so you are having much more of a dramatic impact than you may think. You are making your workplace more suitable for remote work. You are giving more people the opportunity to discover what is going on and then have a route to contributing to the conversation. You are breaking down geographical silos and fighting the tide against Conway’s Law.

Takeaways

So, all it takes is a shift right. Here’s your homework.

• Looking at the diagram of the continuum above, work out what percentage of time you spend on each form of communication during a given week. Do you use specific methods for certain people or teams? Why?
• What types of communication do you prefer? Has this preference changed over time?
• Do you find any of these methods frustrating? Why is that? Is it the medium itself, or is it how that medium is being used?
• Next week, apply the shift right mindset as much as you can. How does it affect your choice of communication medium and the responses that you get from those that you are communicating with?

That’s all for now. 

We’ll build upon this model next time by seeing how it correlates with permanence of the artifacts we create.