arielbkYou've just made your morning coffee, eager to get into this new feature you've been planning. Your editor is open. Hands on the keyboard. Here we go.
A notification flashes across the screen. A workmate has a question about something they're working on. Might as well tab over and check it before we dive into things, right?
You stare at the cryptic message for a moment. The feature they've been assigned isn't defined well, so you suggest they ask the manager for some clarity.
You tab back over to your editor, but notifications swallow your screen. The manager is panicking, and wants everyone on a call.
People talk about bits and pieces of the project. Didn't we cover this last week? There's still confusion. The meeting goes on.
A couple of people are talking in jargon about some project specifics. Why are we in this meeting? Nothing really seems clearer. The meeting goes on.
Developers know the feeling of days squandered on ineffective calls and meetings, but it doesn't have to be like this.
Coding is an incredible superpower, and so is communication. Learning to code and learning to communicate are skills that don't just add to each other — they multiply. If you can learn to be a great communicator as well as a great coder you will be unstoppable.
This is my framework for remote communication, formulated while working remotely over the past two years. There are four main areas: empathize, prepare, clarify, and choose the right medium.
Empathize
After some days of working hard on a new feature you send it to a coworker, hoping for some feedback. You receive a reply:
"It's not working."
You wait for something more, but it looks like that's it.
How does this make you feel? You've spent so much effort on something, only to have it boiled down to three words.
Of course you want feedback. The response communicates a lack of empathy. They should have sent you details to reproduce and fix any issue they came across.
At the same time, you don't know what's going on on their side. They may have been on a call and felt pressure to send something.
Empathy is the foundation of communication. It's easy to judge people for how they make us feel. The real learning happens when we consider how our message is received by others.
Prepare
Our coworker showed a lack of communication, but let's consider what we may have asked them. Preparing relevant information for an interaction means people can easily jump into a topic.
Perhaps we sent them a link to the homepage, and told them the feature we worked on was a new payment method on the accounts page.
Perhaps they were too busy to switch contexts and navigate around the website. You've been working on this for days, but for them it's new and takes energy to figure out.
Provide material that will be helpful for them to quickly switch contexts. Sometimes it's best to show something with a screenshot to illustrate your meaning quickly.
Clarify
You don't want to drown people in information. Too much information puts the burden of finding what's relevant on the other person. Spend time refining your communication.
Point out the parts that will be most relevant if you're sending long-form material.
Spend a stretch of time planning and checking assumptions. This takes time up front, but it prevents needlessly wasting time later by proceeding with incorrect assumptions.
Clarify how urgent a message is. Do you need someone to get back to you immediately, or just when they find the time? Start out with something like, "when you get a chance..." or "as soon as you can...".
Urgency is relative — if everything is urgent, then nothing is urgent.
Choose the right medium
How we choose to communicate carries its own message.
Instant messaging
Instant messaging makes things easy, but has also created a pressure to always be 'on', ready to respond at any moment. It should be viewed as a shorter form of asynchronous communication. People should not be expected to respond instantly.
If you're working on something deeply you can reply to messages in small batches. I work in pomodoros, and reply to messages after I've completed my 25 minute deep work period.
Remember that messages are always at least somewhat distracting. Do not start a conversation with a single 'hey'. Send your message once you have it prepared, or give the other person a clue for what you're going to follow up with so they can prepare for it: 'Hey, I have a question regarding x'.
Keep your messages brief, and if they do become longer consider putting them in an email.
Emails are generally for longer content and have a longer reply window. It is useful for any material that can be easily referenced in the future, or when you want something to be given more time and deeper thought.
Email is ideal to process in batches. Go through emails when you have the time and mental bandwidth for them. I usually go through emails twice during a work day.
Since emails are a longer form of content it can be an ideal place to put things for people to prepare for a meeting.
Calls and meetings
Calls and meetings are the most disruptive form of communication and should be treated with care. There should always be a clear purpose for the meeting, and a clear next step after the meeting.
Because meetings are disruptive, it pays to be careful when initiating them. Ask whether the same outcome could be achieved asynchronously through another medium.
Calls can be lazy communication. It takes energy to articulate something through writing, and for some people it's much easier to just 'have a call'. This is a bad habit.
Our brain is tricked into feeling as though the problem is solved just by scheduling the call. Writing pushes us to refine our thoughts.
Schedule calls in advance and ensure people have the time and material to prepare. Putting people on the spot without preparation will usually lead to more confusion and ambiguity.
Meetings work better when you have a visual aid. Take meeting notes, with the purpose of the meeting clearly stated at the beginning.
While the meeting is in progress, keep watch for whether the conversation is serving the purpose. Bring it back, and if necessary deal with other topics afterwards.
Add a visual anchor if you are describing something. Share your screen to show something rather than describe it with words. Often this will include more data points that you may not have thought to mention otherwise.
Communication is a piece of a developer's skillset that potentiates everything else. It is a super power, and every interaction we have is a chance to build it.
We communicate through our code by taking time and care in naming variables and functions, writing commit messages, and asking for help when we run into problems.
Over time it goes from a skill with concrete rules like those I've listed to an art that you adapt fluidly to the situation.
Like coding, communication becomes stronger as you make a habit of consciously improving it. It is a collection of many small things done right. Together they create something powerful.
