Managing and Supporting Remote Teams - From an All-Remote Company
10 July, 2020
The company I work for, Gitlab, is the largest all remote company. It’s topical given the times, but it’s also unique to the company as our values include everyone working remotely with high productivity and måotivation.
To set the stage, we have 1,300 employees, all over the world, and in nearly all timezones. The company’s goal is to work as asynchronously as possible. When I started at the company about six months ago, I was tasked with creating a net new team. Today, the team size is about 12.
The challenge is managing this team over 8 timezones, including a number of team members who have no work hour overlap. We primarily have been working on net new features, with a percentage of maintenance of existing functionality. As a result, effective communication and business practices were needed for people to get onto the same page about the product and get feedback from all team members.
For starters, just because someone is invited to a meeting doesn’t mean they have to attend. This raises the obvious question - how does one participate in a conversation if they’re not able to join? Notes and other content need to be published before the meeting. Everyone is encouraged to read them in advance, and everyone is encouraged to ask questions in the online document - again, in advance. We record all the meetings and make them available to everyone at the company (audio, video, and any screen share). We take detailed notes in the meeting, so people who weren’t there can read them, but also so that any questions that were asked are answered aloud are recorded in the notes. Using video in every meeting allows people to see the emotional reactions that participants are feeling so that all participants can operate with high EQ. The combination of the agenda, recording, and notes has really been a game-changer for asynchronous communication, especially where everyone is remote.
This works quite well nearly all of the time, but it doesn’t work occasionally in two types of instances. The first case is when we need to get everyone on the same page on a potentially controversial decision. Asynchronous communication on something controversial can get mired in back and forth communication in multiple threads in a document or issue tracking system. If there are strong opinions on decisions where people aren’t coming to the same conclusion about direction, video calls may be needed to discuss. You want to do this because you want to receive and address feedback from everyone involved. It is hard to make decisions when people are not able to discuss what they don’t agree on in realtime.
The second case is when you need to quickly communicate something. Sometimes you need to use multi-modal communication - you call the meeting together for those who can attend realtime but also use online messaging like Slack. An example of when we had to do this is when someone we made an offer to backed out about a week before starting. We wanted people to let people get clarification on why this happened (It was family reasons in this case) and so they could plan accordingly.
We use email infrequently. We focus on using the GitLab system itself for communication, and also Slack. We dogfood our own solutions. As a caveat on multi-modal communication, the smaller the group, generally the more likely it will be effective. If there are fewer people in a channel, they are more likely to pay attention. If there are 20 people in a group it tends to be effective, but with 200 it often doesn’t because there are too many messages that are not pertinent to everyone in the channel.
To make important messages to large groups effective, ask people to tag the message with an emoji on it if they’ve read it. Just track the number of people, and don’t worry about exactly who has read it and who hasn’t. If it is more important than that to track (for something like a compliance training) and you need to know if any individual person has seen the message, I would suggest using a different methodology. For those uncommon cases, we use Google surveys and have sent them via email, with decent success. We see about a 90% response rate after one or two reminders, but some get too much email or miss the messages. In those cases, we ask the managers to follow-up with them individually.
Aside from just setting up good communication and workflows, it is important to keep the health of your team members at the forefront of your mind. People sometimes experience more fatigue when working remotely. To prevent burnout, it is a cultural value to set the expectations on when people should be available. At GitLab, you do not need to be available outside your business hours.
It is important to both communicate culture and set examples of it in action through interactions. For example, occasionally I will see someone say something like ‘sorry I didn’t get back to you quickly.’ These are great opportunities to say ‘no need to apologize, I didn’t expect something quickly.’ Leaders often have great ideas on the weekend, but they should not communicate them during non-work hours and instead wait until their regular work hours. Otherwise, this may set the expectations they should be working off-hours whether you intend to set that expectation or not.
Make your remote team have the same opportunities to contribute and feel a sense of belonging to the team no matter when, where, or how they work.
Pascal Rodriguez, Director of Engineering at Bestmile, shares how his company created a supportive environment for remote work by introducing a self-service and asynchronous mindset rules.
Director of Engineering at Bestmile
Fraser Carlisle, Vice President and Global Head of Digital Product of iShares at BlackRock, explains how to achieve alignment across different time zones and by doing so bridge the gap between different markets, languages, and skill sets.
VP, Head of Digital Product, iShares at BlackRock
Shyam Prabhakar, Engineering Manager at Stitch Fix, shares how he reorganized the team distributed across multiple geographies and why self-sufficiency is the key principle to follow.
Engineering Manager at Stitch Fix
Wayne Haber, Director of Engineering at Gitlab, gives a series of strategies to keep remote teams running smoothly.
Director of Engineering at GitLab
Shridharan Muthu, VP of Engineering at Zoosk, discusses effective communication using Slack including a recommended framework that entails three simple tips to make the most of the tool.
VP of Engineering, Backend Applications at Zoosk
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.