Communicating in Distributed Teams

Even though distributed teams aren’t new, the pandemic meant a surge in remote work over the last few years. While some companies have failed to adapt in what that means for the workforce, others are thriving. What have the successful teams always had in common? Strong asynchronous communication habits. It’s a tale as old as time, but for some reason the lore of the hallway magic conversations is still stronger than distributed communication habits.

No matter if you’re in an in-office team, a fully distributed team, or some hybrid of the two, asynchronous communication skills will make your team and company better. Regardless of where you sit in the org chart, you can make a difference in your team’s communication. Let’s talk about a few strategies to try and a few places you might need to debug your distributed team’s collaboration.

Err on the side of over communicating.

Async communication was always key in any organization; it’s now just more important than ever and more visible than ever. If your team isn’t all sitting in the same place, make sure your most important information is. Here are a few systems to try.

Always CC for the project.

Working on a group project that discusses with a lot of stakeholders over email? Consider setting up an email group with everyone on the project. If you’re emailing a stakeholder, CC the alias. That way everyone on the team can see what was communicated. I’ve seen this resolve miscommunications, allow the group to search to find an answer when a lead was out of office, and build up the entire team’s context on the project, allowing them to make better decisions on their own. When in doubt, they can pull up all emails sent to the group and piece the information back together.

Ask Us Anything: Group Chat answers.

If you work on a team, try to direct questions to the team chat. This is so much easier said than done, especially for the people who love to help others. If you’re helping someone new ramp up, and you’re constantly answering their questions in a private chat rather than in a team setting, you’re missing out on so many opportunities.

Asking questions takes a certain level of vulnerability; folks are admitting they don’t know something, and sometimes they might feel like they should. But by only asking you questions, that team member might only be building psych safety with you, rather than the whole group. You don’t want to be a hard dependency on their success; if you get sick, go on vacation, or change roles, they won’t have the same resilience they would have if they had trained with the entire team.

If you get a direct question, ask the person to ask in the group chat. The first few times, say that you’ll answer the question there, so everyone on the team can learn. Then work up to waiting at least 15 minutes to see if someone else answers. Then try messaging other team experts to take a look at the team chat and answer. Tag them directly if you need to draw their attention to it.. Over time, you’ll see folks doing a better job building a strongly connected network of teammates that can support each other.

Single source of truth and everyone knows where it is.

In distributed teams, you want people to be empowered to get the answers they need without relying on others wherever possible. You also want them to have the psychological safety to ask when they do need help.

What’s not helpful is misinformation. Make a project have a single, consistent one-stop shop for information. Rather than everyone writing their own take of what’s going on, losing track of what the final decision was on a design call, and filling in their own blanks like a Mad Lib, make it a rule that if it’s not in the Single Source of Truth, it’s not decided.

On my first team at Google, I was assigned a starter bug to add a field to our configuration. I read the description of the task, wrote up the change, and sent it out for review. It was a 3 line change. It got something like 14 comments. It turned out the TLs had only mostly thought they agreed on what the new change would need to be. My change request wound up being where we discussed it, surprising and interrupting everyone, especially me.

When I asked my manager how I would have known who was right since I was new to the project, his response was, “Great question. I don’t know.” He decided 14 comments over a 3 line change wasn’t the most productive way to figure that out, got us all in person, and we made (and wrote down!) the decision. A bit jarring of a first task, sure, but hey it only went up from there.

General rule of thumb: if someone was asking a good faith question on your thought process or project state, where would they have been able to find out that’s not directly asking you? We want to encourage person-to-person questions— that creates connection between people. At the same time, we don’t want to rely on it for critical information if we can avoid it. People will often do their “homework” if the resources are available to them. It’s a balance between community and enabling autonomy.

Keep communication actionable.

If you take nothing else away from this newsletter, please make this the one that sticks. In async communication worlds, you want to save yourself a back-and-forth wherever possible. Especially if you’re asking for help, make sure you’re giving everyone the information they need the first time.

Good communication and good feedback are the same.

Let’s consider these two scenarios:

1. Can you take a look at this?
2. Can you please take a look at my slide deck by Tuesday so that I can incorporate feedback before the presentation to leadership on Thursday? I’m especially looking for feedback about the flow of the presentation.

If this sounds familiar, it’s because it’s Specific (a slide deck for leadership), Actionable (feedback on the flow), Timely (a deadline), and Kind. 🙂

With the first option, yeah I’d be happy to take a look. When I have a free minute. Maybe. Between my 8 meetings today and a report that I have to finish by the end of the week. I’ll probably remember to do this eventually. No problem.

I think we all know what’s going to happen with that.

With the second option, someone can easily use this information to prioritize it against the rest of their to-do lists. This tells them this is semi-urgent, for an important audience, and let’s them know what level of feedback you’re looking for. It’s still a yes/no answer, but now they have a lot more information on whether they could meet that expectation or if you need to ask someone else.

ACK and NACK.

In computer networking, some protocols use the concept of acknowledging receipt of a message (ACK) or signal there was some kind of error (NACK). In incident oncall rotations in software, you often ACK a page to let someone know you have received the page and you’re on it. You can NACK a page if you got the page, but can’t reasonably answer it at the moment (like maybe you were driving on a highway). The NACK lets the system know “I hear you. I can’t do anything about it. Move on to the next person.”

In an in-office environment where a team all sits together, if you had a question you could go directly to ask a question. You could read body language on who heard you and who might not have and who might be able to help and who might not. You lose this in hybrid and remote set-ups.

If you ask a question in the chat and no one responds within a few minutes, it can be impossible to distinguish between “I’m being ignored” and “No one knows the answer” when you post a question and no one is responding. This tends to especially hurt more junior or newer team members, but it’s easy to remedy. This can be another great team norm to set. Maybe you agree to respond with a certain emoji to show when you’ve seen the question, but you don’t know the answer.

Set Realistic Response Expectations

We’re all trying to balance making progress on our work, respecting our coworkers’ boundaries, and learning and growing on our own. We want to be able to focus and we want to be able to help. This can be a good rough guide to find the least interruptive way to still get the communication you need.

• Next meet-up. If it can wait for a 1:1, add it to your agenda for your next meeting.
• Email. Email them if it would be helpful to have an answer sooner than your next meeting. You can expect normally a day or two of response. Keep the the email actionable. If you’re not getting a response, see if they’re out of office, and if not, follow up after a few days.
• Chat. If it needs a same-day response or if you are blocked on your work until you get an answer, send a chat. That’s normally enough to get someone a notification. If you’d tap them on the shoulder to ask, it’s ok to direct message (unless your team has a group chat, like mentioned above).
• Face-to-face. If you’re struggling to get a response in other ways, it’s time to set up a meeting. Sometimes when people are overwhelmed, they fall back to relying on their calendars to know when they need to move to the next thing.
• Page if there is an active fire that needs immediate response. Don’t cry wolf. This should be reserved for true emergencies.

Communication is what makes all teams successful. Distributed work doesn’t change that. Set good communication examples for your team and others will do the same. If there is a breakdown, instead of getting upset at the individual, go over your communication systems together. How could that have been avoided for next time? Because we’re humans, communication is hard, and there will absolutely be a next time.