Eight tips for working remotely

TL;DR: When embracing remote work, you could have the best tools in the world, but without the necessary social norms, you’re setting yourself up for failure. Here are eight cultural “rules” that represent the intangible of successful remote communication, regardless of your industry, your role, or what tools you use.
7 minute read

Recently new to remote work culture? This post is a non-software-specific adaption of my popular post 15 rules for communicating at GitHub with “rules” adapted for fostering successful remote culture, regardless of what tools you use or what industry you’re in. Looking for help choosing the best tools to support remote workflows? Check out my other post four characteristics of modern collaboration tools.

I’ve been working remotely for the past seven years at a company that creates tools for software developers to, well, work remotely to build software together (meta, right?). At GitHub, with the majority of the company being remote (including our top executives), we have developed a unique culture around how we work. We use our platform to collaborate on everything from Marketing and Legal to internal policies, but it’s not that the medium defines the workflow (although it certainly helps), in fact, it’s the other way around.

GitHub’s remote-first communication style can be summed up in one word: asynchronous. Much of this is defined by the workflows of the open source software community, where many of us got our start, but part of it, as a distributed company, is out of necessity. Like open source, rarely are two people in the same place at the same time, working on the same thing at the same time. Yet as in the case of Wikipedia versus Encyclopedia Britannica, distributed workflows produce better results than their traditional counterparts, and I’d argue that everyday quality of life is better for those involved, as a result.

Asynchronous communication through mediums like chat or collaborative document editing eliminate the endemic “you had to be there” aspect of most corporate workflows, and reduces the administrative overhead necessary to capture, collect, and shuttle information back and forth between business units. You could have the best tools in the world, but without the necessary social norms, you’re setting yourself up for failure.

Culture’s inherently hard to define, but here are eight cultural “rules” that represent the intangible of successful remote communication, regardless of your industry, your role, or what tools you use:

1. Prefer asynchronous communication

As my former colleague once put it, “Chat is inherently asynchronous; tapping someone on the shoulder is inherently being a jerk.” Knowledge workers are most productive when they have large blocks of uninterrupted time. A two hour block is not fungible with four thirty minute blocks. Think about it practically: Lawyers store large sections of the law in their head when they work. Designers have a vision they’re trying to express on paper. Unlike say, working on an assembly line, when knowledge work is interrupted, intentional or not, whether a popup, a meeting, or a “hey, you got a sec?” drive by, there’s a significant switching cost to get back to where you were. Think about it as the geek equivalent to needing to put on gym clothes, fill your water bottle, and grab your iPad before you head to the gym each time.

In practice, this means that you essentially never “walk over” to a coworker’s desk, virtual or otherwise. Whenever possible, prefer chat or another asynchronous forum like Google Docs, to “just in time” communications. And there’s an added bonus: Asynchronous mediums necessitate a distributed workflow. There’s no “you had to be there”, when “there”, is online and anytime.

2. Don’t underestimate high-fidelity mediums

High fidelity, synchronous mediums like Zoom, Skype, or Google Hangouts are extremely valuable, when used correctly. In many workplace cultures, synchronous meetings are the default, and are often used to make (or worse, communicate) decisions, two goals that are better achieved by non-evented means. What are the latest sales numbers? Create a blog post. Which design should we choose? Post it somewhere where we can discuss it. Reserve such high-fidelity mediums for things that simply can’t be accomplished by lower fidelity means.

In practice, this can come in three primary forms:

  1. Brainstorming - Help me flesh out this idea. What do you think about X? How can we come up with ways to solve X? You can’t “spitball” via a pull request.

  2. Feedback - Hey, I think you could have worded that comment better. Is everything going okay with Y? Feedback is inherently human, and as such, it deserves a human face.

  3. Small talk and gossip - In a distributed company, you need a distributed water cooler. How’s your son’s softball team doing this season? Did you get a haircut? Check in often to ensure your coworkers are human (and you know them as such).

3. Be mindful of noise

A short email or comment on a document may take 20 seconds to read, from the time the notification is received, the screen loads, the reader gains the necessary context, and a decision is made as to what action, if any, is necessary on their part. If there are 50 people subscribed, you’ve just spent more than 15 minutes of your company’s collective time. Was it worth it?

In practice, that means three things:

  1. Avoid drive-by opinions - Assume for a moment that you have a potential say in everything your company does. What issues can you contribute the most to? Have the most impact on? Affect your role most directly? Think twice before providing your opinion on issues fringe to your area of expertise, especially when you don’t have the full context, or aren’t willing to follow through yourself to do what’s necessary.

  2. Only comment if you have something to add to the discussion - It’s one thing to indicate that you’ve taken the time to review a proposed change and give it a thumbs up, but adding a vanilla :+1: to a thread that already has 10 :+1:s, doesn’t really do much to advance the project. Unless what you’re posting moves the issue closer to resolution don’t hit the send button. Just don’t do it.

  3. Always provide context - Context switching costs are non-trivial. Courteous collaborators provide teammates with the necessary context to get up to speed on a discussion, and decide what, if any action they need to take. Messages entitled “a few edits” or “minor improvements” do the exact opposite. This is especially important when CCing a team. In the same comment that brings them into the discussion, minimize the cognitive burden by absorbing the complexity on their behalf, and make it explicit what is being asked of them.

4. Keep discussions logically distinct

The great thing about discussions in asynchronous mediums like forums, in contrast to say, email, is that they can be bifurcated when topics diverge. This keeps conversations focused on one thing and only one thing at a time. Additionally, discrete topics minimize unnecessary noise and optimize for fast decision making by ensuring only the most relevant teams are involved.

In practice, that means discussions should have one purpose, defined by the title at the top of the page. When a concern not directly related to the thread’s purpose arises through the course of the discussion, as they often do, start a new discussion and encourage participants to continue the conversation there, or if you see a teammate hijacking the discussion, do the same on their behalf. If the sub-task is a blocker, note it as such, and move on.

5. Secrets, secrets, are no fun

Email and private DMs are terrible, terrible collaboration mediums, and an even worse mechanisms for storing organizational knowledge. There’s no opt-in or opt-out mechanisms, no ability to link to or cross-reference discussions for non-participants, and conversation history lives in a teammate’s personal inbox or channel list, so when they leave so too does the issue’s context. Use email and private DMs sparingly, and only when issues or chat, exposed to the company, would be inappropriate for the conversation. Put another way, email and DMs are for sensitive conversations.

In practice, that means email and private DMs are typically reserved only for things like personnel discussions, one-to-one feedback, and external communication. The same goes for other mediums (like phone calls) that don’t automatically capture and surface context. If you can have the conversation in a better medium, you should.

6. Don’t ping, just ask

There’s a stubborn chat antipattern, where all chat conversations sparked by a question must begin by the asker either starting with a open “Hi” and waiting for a response before asking, or asking if they could ask a question (“Hey, do you have sec?”). While it may seem like you’re being polite on the surface, it defeats the purpose of chat: asynchronicity. Just ask the question. They’ll know you have something to say, by virtue of the fact that you just said it, and can respond on their schedule, not yours.

In practice, most chat programs let you mention a user by name at the start of a message to trigger a notification on their end. Push them the question, not just the notification. But you can take that a step further: There’s a good chance someone else in the room just saw your question, and is able to answer it immediately (because you’ve exposed the question to the entire team, not an individual). That’s the beauty of a distributed workflow.

7. Overcompensate for tone

It’s often said that it’s hard to capture tone via electronic communications, but that’s a filthy lie. There’s a internet culture is built on a foundation of emoji and animated GIFs. It’s not simply because animated GIFs of puppies are adorable, but because a :trollface: is often the most efficient way to express sarcasm. Be sure to be human. As we say at GitHub, mind your words, they’re important.

Simply put, if you reference something - be it prior discussion, a document, a specific comment or message, whatever—and that thing has a URL, it’s your obligation to find that URL and make that reference a link. Even if the reader could theoretically search for it, you are infinitely more familiar with the thing you’re referencing, and given a comment read by 5, 10, or 50 people, it’s more efficient for you to look it up once, than for readers to look it up 50 times, even if it takes a few minutes to do so. Linking to another discussion creates a visible cross reference, meaning that just by commenting, you create an organic map of the organization’s knowledge.

How you work is as important as what you work on

Has your organization’s workflow changed much since the Cold War? Since the advent of the internet? If you swapped out your laptop for a typewriter and email for inter-office couriers would the way you work be all that fundamentally different? From video conferencing to a remote workforce to real-time chat, the tools available to organizations have radically shifted. Shouldn’t your culture change as a result of that shift, at least a little?

Tools are just that. Tools. Regardless of what tools you use or what industry you’re in, the culture you create around those tools can mean the difference between success and failure (or productivity and a disdain for remote work). These cultural “rules” have allowed GitHub to scale our remote culture to well over a thousand remote employees, but each organization’s culture is different. As you adopt these norms to become your own, think critically about the culture you’re creating and how it must adapt as your tools and workflows evolve over time.

Originally published March 18, 2020 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and 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 →

This page is open source. Please help improve it.

Edit