Originally posted on the DataCamp Engineering Blog.

Being a remote worker, or working with remote teams forces us to be more intentional about when and how we communicate. Over the last few years I’ve either been working as a fully remote employee or with remote teams. This has been a humbling experience and I’ve learned a lot about what does and doesn’t work when it comes to communication.

In this article, we’ll take a look at some simple guidelines and practical advice which can be useful for remote teams, or teams who have remote workers, to enable both to communicate more effectively. By the end of the article, I hope that you will be encouraged to consider writing a shared team document that describes your team’s communication principles — or at least to be curious about how your team currently communicates and whether there are improvements you could make. Let’s dive in!

One of the biggest paradigm shifts in remote work is that natural opportunities for synchronous communication between your peers becomes harder, and asynchronous communication becomes the norm. In your remote team setup, no doubt you are using tools such as Slack. At DataCamp, we use Slack, and whilst it’s become an essential tool, it also requires us to adapt the way we think about communicating in order to make it work for us.

⏲️ Don’t expect immediate responses

When messaging people via such tools, you should not expect to receive immediate replies to your messages as you would with in-person communication. Unfortunately, typing a quick message to a colleague is not the same as walking over to their desk and having a quick chat in person.

There are numerous reasons your colleagues may not respond immediately. At DataCamp, we encourage engineers to block out sections of their calendar for Deep Work in order to foster focus, and it would be unreasonable to expect people to be constantly monitoring Slack during that time. Similarly, someone might be away from their keyboard, in a meeting, or simply in another time zone.

As the recipient of a message, it is courteous to acknowledge that you have seen or handled a request with a response or an emoji reaction such as 👍, especially as the original sender may be in a different time zone and might not revisit the message until the following working day.

If you find yourself needing immediate responses from people, most likely your request is urgent (is it really?), and you might not have a suitable process for escalation in place. In these situations, typing a message in Slack may not be the best approach.

🗣️ Be highly effective with synchronous communication

For those urgent situations (are you still sure it’s urgent?), or for situations where a discussion with real-time interactions might be more effective, then synchronous communication is required.

Within our teams at DataCamp, we typically have at least a 30 minute slot each day where high context topics can be discussed in a video call. We encourage anyone in the team to bring topics for discussion during this time, especially those which are more urgent and cannot be resolved in an asynchronous manner.

To help facilitate this, some teams have a Slack channel which serves as the agenda for the meeting. Sometimes during an asynchronous conversation it may become clear that it would be more effective to bring the topic to a meeting for further discussion — we use a predetermined emoji reaction that shares the topic into our meeting channel using the Reacji Channeler extension — and the topic can then be picked up at the next daily meeting.

Sometimes, these topics end up being too large for the regular meeting. In these situations, it can be more effective to spin the discussion out into a separate meeting of its own.

We also have scheduled meetings on specific topics where interaction is much more dynamic, such as a collaborative brainstorming session. In these circumstances, the session should be booked with both sufficient notice and a clearly defined agenda with desired outcomes, plus any upfront preparation required by the participants.

On very rare occasions, some things are simply too urgent to wait and we encourage people to break out into video calls on-demand — however, this should be the exception and not the norm. Ideally, there will be a shared understanding within your teams on how to handle such situations — for example, having a handy /zoom shortcut to trigger a zoom call within a message thread.

The key take-away is that synchronous discussion is highly valuable and that team members should strive to be intentional and highly efficient with the time — you might just find that you need less meetings than you expect.

🎬 Default to action

Another useful technique in remote teams is to default to action, or exhibit a bias to action. For example, if as an engineer, you feel unable to proceed due to a lack of clarity on a functional requirement, use your knowledge of the product strategy to make a best effort attempt to resolve the issue until further input can be received using one of the other methods.

Use your discretion: if there is significant engineering or other cost at stake, err on the side of caution. This may occasionally mean a wrong -call is made, however this may be indicative of an underlying team alignment issue more so than the individual’s judgement.

While this approach does require a certain degree of trust between team members, it also encourages strong alignment on direction and is a tradeoff to reduce potential dependencies and bottlenecks. Ultimately, the vast majority of decisions are reversible and it’s unlikely to cause significant setbacks. However, you should always retrospect on situations where this occurs to distinguish whether or not the right call was made.

📝 Leave a paper trail

As so much of our communication has shifted over to asynchronous communication with Slack, it can be hard to keep track of all of the decisions that have been made. To counter this, it is essential to keep a paper trail of decisions and outcomes.

As a remote team member, it can be frustrating to stumble upon Slack threads and discussion where something important was discussed, and yet the resolution is missing. However, there are simple techniques to counter this.

One simple trick is to make sure to revisit threads and make sure that when a decision or outcome is reached, that it is stated in the thread. On top of this, you can mark the thread as resolved by adding a predetermined reaction emoji such as ✅. This way, anybody reading over a discussion will clearly be able to see that the thread is resolved, and more importantly, the action that was taken.

You can also combine this approach with the Reacji Channeler extension to keep a team decision log: mark decisions and outcomes with a specific emoji that will be automatically shared into a decision log channel to create a centralized location for all decisions.

🚨 Have a plan for handling emergencies

The best way to handle an emergency is not to have one in the first place! However, sometimes Murphy’s law applies. Be prepared for these situations, and have a clear protocol for handling emergencies.

For instance, you might use a tool such as PagerDuty to ensure that somebody is always on call for a given service in your stack. By using multiple levels of support, you can ensure that emergencies and incidents can be escalated and that somebody is always on hand to help resolve the problem — don’t rely on trying to nudge people on Slack.

All of these guidelines require diligence and a shared understanding between team members, which leads on nicely to the next point — writing down your communication principles.

🧠 Foster a shared understanding

At this point, all of these guidelines are becoming difficult to remember. Additionally, none of this is much use if only one team member is following the advice. The best way you can encourage efficient communication is to build a shared understanding of what works for you and your team.

A simple way of achieving this is to agree on and write down your communication principles in a team-owned shared document. In fact, this article was inspired by and paraphrases sections of the communication principles documentation of one of the engineering teams at DataCamp.

Ideally, everyone in the team needs to understand this document as it will serve as their guideline on how to work together effectively. Not only is it a useful resource for existing team members, it serves as a great onboarding resource for new team members to quickly get them up to speed.

Now that you have your shared communication principles, everything is perfect and set in stone, right? Wrong!

➰ Learn and adapt

If there’s one key message to take away from this article, it’s that you should introspect and be curious as a team about how to work effectively remotely. No doubt, most teams will have experienced some teething troubles and you should not accept the status quo as being the way things will always be.

In your team, you most likely already have a process for continuous improvement (such as an Agile methodology). A simple way to learn and adapt is to include any communication mishaps or triumphs as part of your retrospective ceremony — what went well and what didn’t go so well with regards to communication — and how can you factor this into your next working iteration?

Embrace that this way of working does not come naturally to some, and will be a new experience for many people. There is always more to learn. Take a look at what does and doesn’t work for your situation and adapt as necessary, and be sure to keep your shared communication principles document up-to-date.

To conclude, the advice in this article can be distilled into a few key points:

• Use the right tool for the job (synchronous vs asynchronous discussion)
• Build strong team alignment and encourage a default-to-action approach
• Keep a record of important decisions and outcomes
• Have a plan for escalating in emergency situations
• Learn from your mistakes and adapt your approach
• Foster a shared understanding of how to communicate effectively

By the way, DataCamp are hiring! There are a lot of open positions across many departments including Data Science and Engineering. Come and see, we’re eager to meet you!