Choosing the Right Communication Method for Remote Engineering Discussions

TV news tells us that working from home is the new normal. Or, at least, as normal as life gets right now. Zoom is a household name and ancient jokes about wearing pajamas under the desk are doing the rounds on social media.

But it’s not the same for us developers, right? We were using Slack back when it was called IRC and all we need to do our jobs is a laptop with a decent internet connection.

Maybe. Or maybe not. Successful remote work takes more than just a set of tools. And if your office-based engineering team has gone remote overnight then your biggest risk is getting team communication right.

One of the first things you’ll need to consider is when to choose which type of communication. Here’s what we at Heroku have learned over a decade of running distributed engineering teams.

Choose the right channel

There are exceptions but most conversations within a distributed engineering team fall into three distinct categories:

• simple queries
• back and forth discussions where a group of people reach an understanding or agreement over time
• complex queries or discussions with lots of opportunity for misunderstanding.

If you’re used to working in the same office as your colleagues, your go-to method for each of these may have been to grab a meeting room and whiteboard it out with the people involved. 

In a remote team, you can’t check who’s at their desk or even rely on people sticking to roughly the same schedule. And the methods open to you come with a different set of trade-offs.

So, for each of these types of communication, which methods should you use?

Simple queries

Say you’re working with a new API and you’re getting rate limited. You check the docs but there’s no mention of what the rate limit is. 

To get the answer you need to ask a simple question. There’s no ambiguity and no need for discussion. That answer is a fact. If someone knows it, they can provide  it. If they don’t, they can ignore the question.

That makes this sort of query ideal for real-time chat, such as Slack or Microsoft Teams chat, or even for a workplace social network such as Yammer.

You’re optimizing for the trade-off between the work required and the opportunity for ambiguity. Where the risk of ambiguity is low, choose the communication method that has the least overhead.

Back and forth discussions

Big conversations, on the other hand, take more effort. Should we use Redis or Kafka to queue inbound data? How should we architect our new product? Emacs or vim? (Only joking, that’s not a discussion but an assignment at birth.)

Conversations about things that have long-term, larger impacts need:

• the opportunity for participants to question, debate, present evidence
• room for people to learn, adjust their viewpoint, correct misunderstandings
• a record.

As such, they’re not well suited to communication methods that demand an immediate response. They need structure and time.

You might be ready to object because, in your office, the best discussions all happen in real-time around a whiteboard. Here’s one of the great things about distributed working: it can introduce you to better ways of doing things that you’ve been doing for years. After all, who does their best thinking in a badly ventilated meeting room where Jeff is talking over everyone again?

In a distributed team, bigger discussions happen best by email or a similar asynchronous, recorded medium such as the comments on a Jira ticket. There’s a little more overhead than jumping in Slack but the long-term benefit is a conversation that unfolds rather than getting lost in the scrollback.

Complex discussions

For all the technology at our disposal, there are some situations where good old fashioned face to face communication is the only thing for it.

Learning a new concept from a colleague, trying to uncover a particularly evasive bug, dealing with a personal issue all benefit from the high bandwidth, low ambiguity of in-person communication.

But you’re on lock down. And, besides, the person you need to speak to is 2,000 miles away.

Video calling won’t be how you conduct most of your communication in a distributed engineering team but it is the method you’ll most often use for the really important conversations. That doesn’t mean that the subject matter must be important. Maintaining the human contact in your team is much easier with video calling, even if it’s just to take a break and chat about The Mandalorian.

Video and voice calling require that people break out of what they’re doing and they take time. So, save them for when no other method will do.

Stay human

It can be easy to forget that behind the text on the screen is a reasonable person (except Jeff, right?) who has been thrown into remote working and, perhaps, doesn’t know how best to express themselves.

Distributed working is weird if you’re not used to it and it takes intentional effort to do it well. Communication is, probably, the hardest part. Being choosy about how you communicate can both help to smooth over awkwardness and ensure that the whole team understands that their colleagues value their time.