Managing and Supporting Remote Teams - From an All-Remote Company

Problem

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.

Actions Taken

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.

Lessons learned

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.