How to improve your team’s communication in the age of remote work
I wrote this originally as a guest-article in Smashing Magazine.
Remote work is taking over the world, and the biggest obstacle remote teams face is emulating the natural communication that happens at the office.
In this article, I’ll show you how to improve your team’s communication and productivity by creating habits and processes focused on improving collaboration.
Products are not built in isolation. A big part of our professionals lives is spent discussing, brainstorming, and deciding alongside others. No matter our field of expertise we need our team’s knowledge to amplify our own.
With the rise of remote work, we’re communicating more and more in written instead of spoken form and teams need to adapt. If communication fails, everything else fails too.
When we talk with others in person we receive a lot of information. We canread the room to acknowledge unspoken agreements, alliances, tensions, and the overall mood of everyone, and react accordingly. We do this almost unconsciously, making face-to-face communication more effective.
However, the same reason also makes it messy. If someone is having a bad day, we might see it as a sign of tension or lack of investment in the project. For outsiders, lacking an understanding of the complex dynamics of a team can lead to the wrong conclusions.
A downside of office work is how easily information silos are created. Having colleagues next to us makes it easier to ask for help by tapping on their shoulder than to create documentation and rely on it. This creates information disparity, where a few individuals hold critical knowledge. Is everyone in your team relying on a single person’s knowledge? Or is knowledge safely stored in software instead?
I’ve been there before. I used to work on an over-engineered product where only one person fully understood it. We relied on him to get tricky tasks done. We were “too busy to document it” and instead spent the better part of a year slowly refactoring it. Instead, we should’ve taken the time to document how it worked and then done a workshop for everyone to catch up. It would’ve made us more productive, eased the refactoring and our time working with the product.
Becoming a productive remote team requires a change of mindset: defaulting to asynchronous instead of synchronous collaboration. This allows people to focus on what matters by decreasing distractions and prevents a culture of “always online” which is an adaptation of tap-on-the-shoulder communication to chat and email.
Research has shown that we need from 15 to 30 minutes of focusing on a task before we’re fully immersed in it and are able to do meaningful work. The worst part is that every time we’re interrupted we’ll need to start over. A tap on the shoulder, call, or notification can break our focus. Being “in the zone” makes us more productive by letting our minds solve one hard problem at a time, instead of multitasking, which we’re terrible at. This has been dubbed “Deep Work”.
Achieving deep work should be our goal in any team, but doing it in an office setting can be challenging because of so many distractions. Asynchronous communication in a remote setting is perfect for it.
Once you’re not required to be always-online, the opportunity to do meaningful work will drastically increase, but your ability to get help will get slower, so how can we get the best of both worlds?
Working groups form a network of knowledge, where each individual will have unique information that is accessible by everyone. As we share information among us, we form an institutional memory that makes the team more productive, but can also hinder us.
If you find a solution to a hard problem, others can ask for your help when facing it. But what happens if someone needs your knowledge in two weeks when you’re on holiday? The solution is to offload it onto software that is always accessible, and to foster an environment where everyone sees the value of documentation as a first-class citizen. However, it’s easier said than done.
Asking someone at the office to create documentation, although logical, might be ignored since everyone is nearby and ready to help. But remote teams appreciate being self-reliant when facing issues.
The bigger the team, the harder communication gets, and having a central repository of knowledge helps to tame complexity. By making documentation the default instead of an afterthought, you’re improving your institutional memory, which makes critical information accessible by anyone, anytime, anywhere.
What should you document? Solutions to thorny problems, outages and their causes, onboarding, new tech or tools introduced, fruitful and unfruitful discoveries. It’s all valuable information that should be accessible.
For example, when I joined a remote-first company my manager assigned me a Notion document with goals for the first two weeks. The first week was about reading our “Engineering Documentation”, which explains most of our tech stack and how to set it up locally. The second week I had to do my first task, which also had everything documented: requirements, deliverables, stakeholders. It was by far the best onboarding I’ve had.
Private communication hurts remote teams. Because of it, knowledge and information are not shared equally, and no matter how trivial a discussion is, others might benefit from it. For your remote team to communicate effectively, doing it in public is an important step.
Keeping communication private is similar to not having documentation. You’re storing information in your head and nowhere else. This fosters information silos, decreasing productivity as a result.
Some topics will be sensitive enough to warrant private communication though, such as health or workplace issues, but if you’re collaborating privately consider your motivations and try to switch to public instead.
Public communication in an office is difficult because you can’t interrupt everyone all the time to share something, and it’s a good reason why agile processes such as daily stand-ups exist. But with asynchronous collaboration everyone will read through the announcements in the team channel whenever they can. Daily standups can either be ditched, or become a time to socialize instead.
In companies where communication happens in private, changing to a public mindset can be challenging, but the benefits are worth it. Some tips to facilitate the move is to have clearly defined channels for different topics in your chat app. That way everyone knows where to ask questions and have discussions. Making everyone aware that the team should communicate in public is important too.
But beware, too many channels (private or public) can hurt productivity since everyone spends more time deciding where to communicate rather than _how. _Only have as many channels as you really need, only invite the necessary people to them, and understand that it’s OK to mute unimportant channels.
When everything happens in public your team is more interconnected and it facilitates leading by example since everyone rises to the challenge of being better.
Expressing one’s ideas effectively is hard, but by following some rules we can dramatically improve how useful each message we send is.
From the perennial “let’s go for a tea/coffee” to the famous water cooler brainstorming session, in-person communication is riddled with traditions. We use these traditions to simplify complex collaboration.
We’re still figuring out the best habits to help us communicate online, but some great rules to follow is to make every message we send actionable, a question, or informative, and to include its context.
Now, let’s break down the rules.
With actionable messages, there’s something to be done. A ticket can be created, a solution provided, or a discussion had.
Compare a non-actionable message with little context: “I clicked the subscribe button and a modal showed up”, to an actionable one: “On the products page, I clicked the **‘Subscribe’ **button and a modal opened. But I should’ve been redirected to the subscribe page instead. Are we aware of it?”.
In this case, either the behavior is wrong, or the specification is out of date and there’s a clear action: A ticket can be created or the documentation updated.
A good question explains the why behind the question and provides context. The trick is to maximize the chances of someone understanding your problem right away by explaining it as clearly as possible. If you’re asking for help with a problem, highlight what you’ve tried so far and If you haven’t tried to solve it yet, try first.
Compare an unclear question with no context, reason, or attempts: “Does anyone
know how to render a modal with React Router?”. With a clear one: “I need to
show a modal with our newsletter when a button is clicked, but I’m not managing
to do it with React Router. I tried using a
<Link to="/modal" /> but it
redirects to a page instead of opening the modal in-place. Can someone help?”.
A good informative message is self-contained. You don’t need a lot of prior knowledge to understand it and its value.
Here’s an informative but unclear message: “We reached an all-time high of users today!”, with a self-contained one that has context: “We reached 10k concurrent users today on the site, an all-time high! That’s a 25% increase from last month”.
If you noticed, all rules mentioned _context. _Adding a message’s context has an anchoring effect, helping the reader better understand the rest of the information.
Here are the same messages as above but with context struckthrough. Notice how much better they are if they contain it:
On the products page,I clicked the ‘Subscribe’ button and a modal opened. But I should’ve been redirected to the subscribe page instead. Are we aware of it?”.
- “I need to show a modal
with our newsletter when a button is clicked,but I’m not managing to do it with React Router. I tried using aCan someone help?”.
<Link to="/modal" />but it redirects to a page instead of opening the modal in-place.
- “We reached 10k concurrent users today on the site, an all-time high!
That’s a 25% increase from last month”.
Would you send an email to a colleague sitting next to you, asking if they’d like to go for a coffee? Probably not. You can be more productive by using your tools as they were intended to be used, and a remote team needs many of them to collaborate effectively. Let’s see how to best use each type.
Adding an image to a bug report, a video to a feature announcement, or an emoji to a celebratory message can make all the difference between understanding and confusion. Using media helps to explain visually what is hard to describe.
Many services allow you to use emojis for collaboration such as Jira or GitHub. For example, a thumbs up 👍 usually means “good” or “acknowledged“ and is widely understood, but make sure your team is aligned on what less common emojis mean. In our team, we use the tulip emoji 🌷 in code reviews to express an “Improvement, but not required” comment. We have that usage documented under “how to do code reviews”.
Chat tends to be the beating heart of a team. It’s a newspaper of the current events, where most collaboration happens.
To improve chat communication, create laser-focused channels. Each project should have a channel so that any conversation about it can be kept in one place. Just beware not to overdo it and harm productivity as a result.
Chat is also a great place to talk, make jokes, and connect with your peers. Create “share” channels where random discussions, articles, and funny cat gifs don’t interrupt serious conversations.
Depending on the app you use, you might have “threads”. If you do, try to keep all discussion inside a thread. It dramatically reduces noise in the main channel and keeps the conversation focused.
Deciding whether to document something can be tricky. If the answer to any of the following questions is yes then you should document it.
- Will someone need to read this again?
- Will we keep contributing to this?
- Is this a repeating event?
- Is this information evergreen?
Event summaries, technical guides, team decisions or guidelines, checklists, and results of brainstorming sessions should all be documented. Writing documentation isn’t fun, but spending 2 hours writing something that could save hours for multiple people in the long run is a huge productivity win. Time savings compound.
Documentation saves time in other ways too. It helps to spread knowledge throughout the organization, to answer questions, and people to be self-reliant. You can create templates for common tasks such as team meetings and investigation tasks to simplify the work. Apps like Notion and Confluence have ready-made templates you can choose from or you can create your own.
When chat discussions are becoming a long thread, move it over to documentation. One person writes down a summary of the problem at hand, and everyone can collaborate asynchronously.
For more effective decision making through documentation, explain the problem at hand, its context, and list possible solutions. That helps stakeholders choose and leads to more focused discussions, instead of a back and forth between options.
Product management tools such as Jira are complex. But they can boost productivity by connecting any decision or important information relevant to a task in a corresponding ticket. This is a game changer if done properly.
This follows the idea of having a single source of truth. By compiling all the information about a feature or task in a single place it becomes simple to stay up to date and to solve misunderstandings by pointing to earlier agreements. If the feature is blocked, put on pause, or someone else takes over, being able to follow through all the decisions saves a lot of time, and anyone that needs to verify information knows where to find it.
We often make product decisions in chat or documentation. Keep your ticket up to date by adding a link to it. For example: “We’ll implement animations next sprint to ship on time, discussion in the link below”.
However, we’re all human. We’ll miss things. Decisions won’t be recorded, information might not be up to date, and some knowledge will live in our heads, but porting at least some information could save someone hours down the road.
We should try to offload knowledge and information onto software tools for organization and ease of access, but sometimes talking to each other directly is priceless. Being able to call our colleagues friends is a valuable part of our professional lives, but creating strong connections in a remote team is challenging. Talking directly to others helps a lot.
From pair-programming, brainstorming in real-time, important private conversations, delivering critical news, or simply hanging out, video conferences excel at making us feel connected to our peers.
Team rituals are great ways to strengthen bonds and to foster human connection. You’ll be surprised at how natural it becomes to talk with friends via video after a while. In my team we meet every Tuesday to do a roundup of what everyone’s working on by demoing it and to crack a few jokes in between. On Fridays we play simple browser games together and have a good time.
But beware, overuse of video calls can hurt productivity just as much as an open office. A request for help via video is hard to deny. Make sure your team is respectful of each other’s needs to focus. Having an asynchronous mindset helps. If video is needed, schedule it, it could be in 30 minutes or tomorrow morning. Unless it’s something critical everyone is happy to wait to get help.
Video communication should be linked with your other tools too. If a decision is made in a call you should document it, it’s easy to forget what was agreed on otherwise. If the meeting is important consider recording it.
Just like any other productivity tool, you can use video to save time. Switch to it when the conversation is becoming entangled in confusion, there’s too much context to share via text, or an in-person explanation is better.
Follow all the best practices highlighted in this article and you’ll notice how you and your team spend less time on discussions, disagreements, and reminding each other about things, and more time solving problems and doing the things you enjoy.
Getting started can feel overwhelming, so the first step is to promote asynchronous communication by letting others know that answering chat, contributing to documentation, and even video calls should be done when it’s not interrupting their focus time .
Start leading by example. Don’t wait for others to improve the docs or send well-crafted messages. Soon enough, everyone in your team will consider improving communication as a top priority and will start to contribute ideas and find ways to be more productive.