Encouraging a Culture of Written Communication

More and more people are being exposed to working remotely. One of the key factors for success in a remote workplace is a culture of written communication. It’s not always obvious how to create such a culture, and it takes at least some level of discipline from the people involved to make it a habit.

I’ve worked with mostly remote teams over the past three years. Here are a few of my observations on what helped cultivate such a culture.

Drafts and High Standards

In High Output Management, Andrew Grove said that writing things down is a medium for self-discipline. It forces us to be more precise than in verbal communication and thus leads to clearer thinking. Similarly, you may have heard of Amazon’s culture of six-page memos, which Jeff Bezos talked about in one of their shareholder letters.

Based on these stories, you might be determined to demand high writing standards everywhere, right off the bat. I believe this is the wrong approach though. Context matters. In a team of individual contributors, it’s crucial to share ideas early, to iterate and collaborate on them. Not everyone will have the same level of writing skills. Improving it can take a long time. Lower the barrier, encourage more writing, and people will get more practice.

Where you should enforce high-quality writing is broad or upwards communication, because there clarity is more important than speed and ideation. Here too, it’s important to keep in mind that good writing takes time. In the shareholder letter, Bezos mentioned that the great memos usually took a week to write. They incorporated input from co-workers, and were edited or even re-written multiple times.

Don’t require that amount of effort everywhere. Imperfections, even typos, should be allowed for communication within the team. This will ultimately lead to more people collaborating, more people writing, and better solutions because of the combination of both.

Easy to Search. Single Source of Truth.

The usefulness of lowering barriers extends to the area of knowledge management too. I believe it has to be easy for people to write a document without having to worry too much about where to put it. Therefore, I believe it's better to have a tool with good search functionality rather than investing in having a perfect information architecture. In the latter case, we're putting up extra roadblocks for the writer, because then they'll need to spend extra time figuring out where to put their writing in the first place.

Similarly, you should try to have a single source of truth as much as possible. If you have many places where information can be found, it will affect both people writing the documentation and those trying to find it. The writers will have yet another blocker to just getting stuff written down. The readers won’t know where to look and will have to interrupt people in Slack, as opposed to referring to the knowledge base themselves.

Balancing Async and Synchronous Communication

Sometimes written discussions can become quite long. While this may seem like a good sign initially, you’ll notice that discussing in this way can become tiresome because of the extended back-and-forth. So when a comment thread becomes a bit too long, it’s often better to jump on a video call to discuss things and then summarize it afterward. You don’t want to have these video calls every time, but finding the right balance between synchronous and asynchronous communication is good. This is usually more appropriate in the early stages of a draft, when there are still a lot of questions to ask and context to fill in.

The rule of thumb is to prefer asynchronous communication as much as possible, but don’t become too pedantic about it when you notice it starts to break down. It’s better to get on a few video calls and push for more async if you feel it’s appropriate than thinking black-and-white and sketching video calls as completely evil.

Thinking Out Loud

Finally, good teams communicate well, whether it’s a professional basketball team, a crew on a nuclear submarine, or a product team in a startup. As much as possible, encourage people to post anything of interest to the public channels. Notice that I’m saying public channels, and not private messages, because we don’t ping anyone unless it’s necessary. We just want to make the information available.

If you are changing a configuration option on production, considering to do a database migration, or just noticed something interesting in the performance graphs… post it to the chat. When you are making critical changes, this has the benefit of making the action deliberate. Just like the Japanese train conductors who deliberately point at whatever they are checking, you’re much less likely to make mistake that way.

If you’re uncertain about something, or investigated something of interest, but didn’t quite get to the bottom of it… share it in the chat. It gives others a chance to chime in and it builds trust. Posting in public channels can be daunting, if you have to mention you don’t know, or that something might be going wrong, or you think you may have caused an issue but aren’t sure. Encouraging everyone to do this regularly builds up both the team’s level of psychological safety and people’s courage to be vulnerable.

Once a crisis happens, and one always does at some point, you’ll be happy to have a team that’s ingrained with the habit of continuously and informally sharing information like this. It’ll be much easier to get a grasp of what’s going on and to get to the bottom of it quickly.

And, because of the trust you’ve built and the information that’s being pushed into public channels, there’s less of a need to speak via private messages or video calls. This means fewer interruptions and thus more pleasant and productive workdays in general.