Building a communication process that scales

Develop a system, and grow a culture

A small or moderate-sized team can move faster and deliver higher-quality software than a large team or several distributed teams. That's one of the interpretations of Brooks's law . The increased complexity of the communication process is one of the assumptions on which the law is based. It's pretty often neglected and not taken seriously.

People just don't know how to talk to each other at scale!

As you grow, so should your processes. A perfectly organized process is a no-brainer for the participants. This means that whenever a person in your organization sends a message to another person or a team, it should be clear which channel to use and how. A voice call, email, messenger, or even a comments thread in task manager are all proper channels that should be selected depending on the type of message and its priority. Create a policy or protocol that explains how you use different channels to improve communications in your organization.

Explain to your colleagues what is the most productive way of chatting!

Automation is the next big thing to consider. It should be an essential part of your communication process. Do more broadcasting rather than messaging. Broadcasting means that a message submitted once reaches as many parties involved as possible. The task manager is a good example. First of all, it is the right place to discuss the implementation details of the dev team's tasks. The second important point is that you can subscribe all related parties to automatic notification about progress and status of a task. This eliminates the need to reach out to every interested person when a task is completed or blocked by anything.

Finally, do not underestimate the importance of a code of conduct. All people are very different. What may seem like a harmless joke to one person may be a huge insult to another. Just set boundaries to prevent this from happening. It makes perfect sense for everyone if it's done right.

Make everyone follow it

Developing a communication protocol (or policy) is only halfway to an organized process. Once you get a system in place, you have to make everyone follow it.

Asking people to follow the rules is the hardest part.

Let's take messenger's direct messages as an example. In our company, we explicitly require that everyone communicate on work-related topics in group channels, not in DMs. Hiding things that might be helpful to someone else is harmful to team awareness. We strongly encourage our developers to start threads in the group channels to discuss all things related to the project.

Unfortunately, verbal persuasion doesn't always work, and there are no automatic tools for limiting DMs. Team leaders have to remind everyone of the communication protocol recommendations every once in a while. This seems to be inevitable. So you just need to find the right way to engage your team in dialogue and learning. Also, don't forget about the documentation — it should be informative, concise, and highly specific.

Iterate and improve!

Treat the improvement of a company's communication process as an iterative activity. Try new approaches, automation tools, and strategies. Set up some metrics (formal/informal) (e.g., average reaction time or distribution of messages per channel), collect them regularly, and iterate based on the results.

Most importantly, gather feedback from your team!