Remote work: Working together when we’re not together
GitHub shares best practices for making remote work part of your company culture.
For years, a majority of Hubbers have been working remotely, including many of our senior leaders. As a result, GitHub naturally developed a culture centered around collaboration and communication. Today we continue our series to share how Hubbers are managing remote work. Our first post featured Kem Boggs, Head of Global Talent Acquisition at GitHub, who provided a unique perspective on how we foster a remote-friendly culture, starting with the hiring process and employee programs.
Today we introduce you to Ben Balter, Senior Product Manager at GitHub, who shares how best practices for successful communications can go a long way to establishing cultural “rules”. Ben currently oversees the platform’s community and safety efforts. Previously, he served as GitHub’s government evangelist, leading the efforts to encourage government at all levels to adopt open source philosophies for code, data, and policy development. Ben has been working remotely for the past seven years at GitHub and has shared his wisdom on cultural guidelines for successful remote communication, regardless of your industry, role, or what tools you use.
GitHub’s remote-first communication style has often been described as asynchronous, but what does that actually mean?
When it comes to GitHub’s asynchronous communication style, we define this by the workflows of the open source community, where many of us got our start. As a distributed and now fully remote organization, part of this is done out of necessity. Much like open source, several people are rarely in the same place and time, working on the same thing simultaneously. Like the case of Wikipedia versus Encyclopedia Britannica, distributed workflows produce better results than their traditional counterparts, and I’d argue that daily quality of life is better for those involved, as a result.
With this in mind, asynchronous communication through mediums like Slack or Google Docs eliminates the “you had to be there” aspect of most workflows. And it reduces the administrative overhead necessary to capture, collect, and share information between teams. You could have the best tools available, but without the necessary social norms, you’re ultimately setting yourself up for failure. Asynchronous communication is a preferred way to work with your remote team to avoid too many interruptions. This is especially true now with many people unexpectedly working from home—some for the first time. Asynchronous communication provides flexibility for things like childcare, healthcare, and errands, by focusing on outputs rather than inputs.
What if I need to have a more meaningful discussion to either brainstorm on something or solicit feedback from my team?
Simple answer: Post it where the team can discuss it. Post it before a conversation, to give people time to digest and reflect (different people consume information differently) and afterward, to memorialize and surface outcomes from the sync. There are certain discussions, such as soliciting input on a design, that might require more high fidelity mediums that aren’t easily accomplished by lower fidelity options, such as Slack or a Google Docs.
High fidelity, synchronous mediums, like Zoom or Teams where you can see and interact with fellow collaborators, can be extremely valuable when used correctly—they’re often the default in some workplaces. For example, I might have some input on a post and would like to discuss it with you. Feedback is inherently human, and as such, it deserves a human face. You might choose Zoom for other situations like brainstorms and small groups or 1:1 check-ins. Last, when working remotely, it’s on you to take that extra step to be able to connect on a human level, so don’t forget to turn on your camera, especially these days when it’s really nice to see other faces.
How do I make sure I’m providing valuable feedback when there are so many people who have access to a document?
There are some things I recommend considering when thinking about providing feedback. First, avoid drive-by opinions. Assume for a moment that you have a potential say in all that your company does. What issues can you contribute to the most? Where would you have the most impact? Think twice before providing your opinion on issues fringe to your area of expertise, especially when you don’t have the full context or are unable to follow through to do what’s necessary.
Second, only comment if you have something to add to the discussion. It’s one thing to show that you’ve taken the time to review a proposed change and give it a 👍, but adding a standard 👍 to a thread that already has 10+ 👍s may not be necessary. Unless what you’re posting moves the issue closer to resolution, don’t press the send button.
Lastly, always provide context. Courteous collaborators provide teammates with the necessary context to get up-to-speed on a discussion and decide what action they need to take (if any). Messages entitled “a few edits” or “minor improvements” do the exact opposite. This is especially important when including team members who are more of an FYI. In the same comment that brings them into the discussion, minimize the cognitive burden by absorbing the complexity on their behalf, and be clear about what’s being asked of them.
What is the best way to translate in-person social conventions to be more async?
My best advice here is don’t ping, just ask. There’s often the polite tendency to start a chat conversation with “Hi” and waiting for a response before asking, or saying “Hey, do you have sec?” While the desire to be polite is understandable, it defeats the purpose of using Slack or other tools for asynchronous communication. Just ask the question. It’s a win-win: you get your answer faster and the other person can better manage their own schedule.
Also, when it comes to asking questions, use private direct messages in Slack sparingly, and only when necessary. Instead, prefer shared channels whenever possible. If you mention a user by @name at the start of a message, they’ll receive a notification with your question, but what’s even better is there’s a good chance someone else in the channel might know the answer and can reply immediately. Plus, it’s an open way to capture and surface organizational knowledge for others that might have the same question. That’s the beauty of a distributed, collaborative workflow.
Do you have any advice for how to capture tone?
Many people think that it’s hard to capture tone via electronic communications, but that’s not true. Today’s tech culture is built on a foundation of emoji and animated GIFs, and we know how much Hubbers love their emojis. It’s not simply because animated GIFs of puppies are adorable, but because a 😥 is often the most efficient way to express sadness or 🎉 to celebrate great work. Be human and sincere. As we say at GitHub, “Mind your words, they’re important.”
What’s the most important item on your desk right now?
I’ve worked remotely for so many years, and I’ve found that investing in a good microphone and lighting setup is really important, especially as your primary voice and face to the world. I also have a world clock with all timezones that my team is working in, which makes me more considerate of timezones.
Want to learn more about best practices for working remotely? Check back next week as we continue our series to help you make the most of working in a remote environment from our next interview. And share these useful tips with others who may be new to working remotely.
Explore the remote work series
Tags:
Written by
Related posts
Breaking down CPU speed: How utilization impacts performance
The Performance Engineering team at GitHub assessed how CPU performance degrades as utilization increases and how this relates to capacity.
How to make Storybook Interactions respect user motion preferences
With this custom addon, you can ensure your workplace remains accessible to users with motion sensitivities while benefiting from Storybook’s Interactions.
GitHub Enterprise Cloud with data residency: How we built the next evolution of GitHub Enterprise using GitHub
How we used GitHub to build GitHub Enterprise Cloud with data residency.