Remote work requires communicating more, less frequently
TL;DR: Remote work requires communicating more, less frequently, because asynchronous communication involves less frequent, but richer communication, meaning there is less time talking about the work and more time doing it, allowing the system to optimize for throughput and flow.
Remote work is not simply a matter of replicating the office environment online. One of the key shifts that remote workers need to make is to communicate more, less frequently. Instead of relying on constant, synchronous, and often interrupt-driven interactions, remote workers embrace asynchronous, and often higher-fidelity, forms of communication, such as long-form writing or thoughtful videos.
I’ve written before about the benefits of working asynchronously, but less obvious, it also changes the way we think and work. Async work allows for more reflection, research, and synthesis. Those working async can and should take the time to think, learn, and synthesize before sharing their ideas, opinions, or solutions, distilling them down to the most critical. This improves the quality and clarity of the communication, and most importantly, the overall throughput of the communications channel.
Think of it like gzip compression, but for human-to-human communication. Yes, there’s slightly more processing overhead at the start, but it allows greater communications throughput using fewer “packets” (communicate more using less).1 How can you communicate more, less frequently? Here’s a few tips I often keep in mind:
- Choose the right medium for the message - Remote workers should use the most appropriate and effective form of communication for the purpose, audience, and context. For example, use writing for documenting, explaining, or persuading; use video for demonstrating, teaching, or storytelling; use chat for coordinating, clarifying, or socializing.
- Write clearly, concisely, and comprehensively - Remote workers should write with the reader in mind, using simple language, short sentences, and clear structure. They should also provide enough detail, context, and evidence to support their points, answer potential questions, and avoid ambiguity.
- Record videos with empathy, enthusiasm, and engagement - Remote workers should record videos with a human touch, using eye contact, facial expressions, and voice modulation. They should also keep their videos short, focused, and interactive, using visuals, examples, and questions.
- Communicate proactively, regularly, and asynchronously - Remote workers should communicate their goals, plans, and updates without waiting for prompts, requests, or deadlines. They should also communicate their availability, boundaries, and preferences without assuming or imposing. They should communicate asynchronously as much as possible, using synchronous communication only for urgent, complex, or sensitive matters.
Remote work requires communicating more, less frequently, because asynchronous communication involves less frequent, but richer communication, meaning there is less time talking about the work and more time doing it, allowing the system to optimize for throughput and flow.
Not to mention, thoughtful, written communication, helps ideas to scale more effectively (there’s a reason the printing press spurred the Renascence). It shifts communication from a one-to-one relationship, to a one-to-many. Next time you’re about to “send a quick DM” or “schedule a quick chat”, consider what steps you could take to optimize for the long tail of information retrieval and discovery. Just like building a web app, “writes” are expensive, but “reads” should be “cheap”, so avoid introducing mental N +1s into the system whenever possible. ↩
If you enjoyed this post, you might also enjoy:
- Twelve tips for growing communities around your open source project
- 15 rules for communicating at GitHub
- Why open source
- Why everything should have a URL
- Five best practices in open source: external engagement
- Four characteristics of modern collaboration tools
- Eight tips for working remotely
- 19 reasons why technologists don't want to work at your government agency
- Leaders show their work
- The seven things a corporate Chief of Staff does
- Ten ways to make a product great
Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →