Building Distributed Teams – Team Communication
This is the fifth post in my series on Building Distributed Teams. So far, we’ve covered why you need to be building a distributed team, what makes an ideal distributed team member, individual vs pods when hiring and team leadership. As a reminder, this series is focused on building a distributed technology product team. While the principles here might apply to building a distributed sales team, it is not the focus.
In this post we’re going to talk about how a highly functioning distributed team communicates and where a lot of companies get tripped up with this model.
There are three things that the best distributed teams do to facilitate great communication:
- Company leadership ensures that everything that’s important for the team to move fast is written down
- Everyone on the team is online and available for a set period of time each day
- All important communication is handled in publicly available channels
Writing It Down
One of the main reasons you build a distributed team is so that you can be as or more productive than if everyone is sitting in the same office. However, you’ll be sorely disappointed in how quickly the team moves if you don’t do your job as the leader of the team to ensure that everyone has what they need when they need it.
One of the best examples I’ve seen of publishing everything that’s required for a distributed team to function in recent times is Gitlab’s Employee Handbook. You should stop what you’re doing and go read this right now. Everything a team member needs to know about working at Gitlab is right there in easy to read bullets.
If every time a new team member has a question they have to wait for someone else on the team to be available, things will grind to a halt.
This is a two-way street, of course. Every team member has to care enough to write the specifics of their particular area down as they work on them or the system breaks. If it’s not written down, it’s not done.
Schedule Overlap
Regardless of how widely distributed your team is in terms of timezones, you must ensure that everyone on the team is available for a set period of time each day. For example, you might mandate that everyone is online from 8-10 a.m. EST. This window is used to cover important communication that everyone in the company needs to know, and to address key questions that might be slowing parts of the team down.
This also facilitates everyone getting to know each other. You have to be intentional about this or your team will not function.
You might consider using one day a week during this time to share wider information about how the company is doing, key milestones upcoming, or new customers that were onboarded since the last time the team met.
Communicate in Public Channels
Before Slack and HipChat came along, I ran all of my teams using Hangouts or other messaging systems. Nearly all communication in a distributed team happens via written channels, not voice or video. Why? In any size team, someone will be missing on any given day. If you use voice or video channels, that person may miss something important. If you use written channels, if someone was missing they simply catch up the next time they’re online.
Also, if you’re having face to face meetings in your main office, you must remember that a good number of your team are not sitting with you. If you make key decisions in those meetings, you have to be intentional about communicating the what AND the why to those who were not sitting with you.
A great practice is to record all face to face meetings in your office and share the audio in your public comm channels. Others can listen to the audio on their own time and ask questions as needed.
Of all the the things that make distributed teams fail, poor communication structures are probably #1 on the list. You must over-communicate at all times, and ensure that the rest of the team understands that every side conversation that is not shared weakens the team.
Writing everything down, ensuring there is sufficient schedule overlap, and forcing all communication into asynchronous, public channels as much as possible will go a long way toward ensuring your distributed team functions at their highest possible output.
In our last post, we’ll talk about the most common reasons why this model fails and how you can avoid the pitfalls. See you next time!