If You’re Now “All-Remote” Like GitLab, Remember That Working Remotely Doesn’t Mean Acting Remotely

Tools and practices to support an all-remote SDR team #

So, how does the SDR team at GitLab operate successfully in an all-remote environment? First, our setup is a little different than most sales development organizations. Unusually, we are part of the Marketing organization, not Sales, because we work very closely with marketing on field, digital and other programs and then receive marketing qualified leads (MQLs) from them which we qualify for the Sales teams. That reporting structure makes the most sense for our organization.

Our SDRs tend to be naturally competitive, but the team is highly collaborative. We all want to help each other achieve our targets. And there are plenty of practices and tools that we use within the company to promote cross-collaboration inside and outside of the SDR structure:

Accountability through asynchronous work

Because we all work asynchronously at GitLab, it’s extremely important for people to be accountable and to contribute proactively. For example, whoever calls a meeting is responsible for documenting that meeting and its outcomes in a single document everyone has access to. This document is a single source of truth vs having multiple documents with multiple notes. Our team is distributed across time zones, so people can’t, and aren’t expected to, attend every meeting. But they can still participate by reading the meeting documentation, watching the recording, providing comments or feedback, and asking questions.

Go-to tools: Slack, Zoom, and GitLab

We use Slack frequently to communicate and collaborate. We have a global Slack channel as well as channels for each of our regions and departments. If an SDR has a question or a challenge to overcome, they can post the query either on our Global SDR channel or on our general company Questions channel and get a prompt response since someone is working at all times in our multi-time zone and async work environment.

Zoom is another important tool for us, and we encourage the use of video calls whenever possible. And we take notes from those calls, just as we do for all meetings, and encourage everyone on the team to review and edit them to clarify or correct points. As well as work calls, we also recommend everyone sets up coffee chats with anyone at GitLab (even the CEO has coffee chats!) for a social check-in.

The GitLab SaaS platform is our go-to tool for collaboration on all projects that we run within GitLab the company. We create what are called Issues which allow us to start a discussion on any topic; this can be anything from a new SDR initiative or spiff, to planning a complete field marketing event. Most of our Marketing issues on GitLab are not confidential and so everyone, even the public, can have access to them; Transparency is one of our values.

Focused calls and frequent meetings

Even though we all work remotely, there is a structure to our workweek. Our regular calls within the SDR organization and across the company help define that.

Our team calls tend to be short — about 25 minutes — and to the point, with everyone asked to review any prep material before the meeting. Efficiency is one of our other values! Sales and Marketing hold longer calls every two weeks for larger group catch-ups. And every two months or so, there’s a call for each part of the company, Group Conversations, where each department gives a short report on what they achieved in the last eight weeks (usually a presentation shared in advance) followed by a Q&A. Everyone can ask questions, and notes from the call are always made available. We also host Ask Me Anything (AMA) calls with individual e-team members for the whole company to join.

Each SDR Manager schedules weekly meetings with their teams, in addition to the standard one-on-one meeting. Those calls are opportunities for the team to share their personal plans for the coming/past weekend, and to set the basic game plan for the coming week. More detailed planning and discussion takes place in manager one-on-ones.

Formal onboarding and training processes that include Chorus.ai

When SDRs join our team at GitLab, they are assigned tasks set up on a GitLab issue. They will learn the vital things they need to know to be able to qualify leads mainly through pre-recorded videos on specific topics, as well as using recorded videos of past SDR and Sales training sessions. Onboarding also includes ten random calls with any GitLabbers of their choosing (preferably not SDRs) and studying certain parts of the company handbook which is our bible and our central source of truth for all company activities. Video also plays a big role in our onboarding process, as it allows new reps to get direction and support from their peers in the SDR group and on the marketing team. We also collaborate closely with our sales enablement team who also run training sessions for new hires which the SDRs are invited to.

We also use the playlists feature in the Chorus.ai conversation intelligence platform to help onboard and train our SDRs, think of it as virtual call shadowing. The recordings in Chorus.ai allow us to share best practices quickly and easily across our global sales organization. In fact, the EMEA team is currently using a list of Chorus calls compiled by one of our U.S. managers to help train our reps. Due to GDPR, we are unable to record calls in Europe.

The Remote Playbook

The onboarding process at GitLab includes learning how to work remotely. Some of our new hires are more experienced and already work remotely. But many are new to both SDR and remote work. So, they’re now asked to review GitLab’s Remote Playbook which has recently been published by GitLab.

The playbook is for all of our employees, and includes a section on how to set up for remote work successfully. It provides five tips, which other companies might find valuable in guiding their newly remote teams.

Here’s a quick overview of those tips:

1. Carve out a dedicated workspace. Ideally, you should have a room (with a door) that is dedicated just for work. But if that isn’t possible, a curtain or room divider can help you maintain separation and focus.
2. Set work-life boundaries. Just because you work at home doesn’t mean you’re always available to your family — and they should respect that. At the same time, because there is no commute involved, there’s a tendency for remote workers to put in longer hours. Find a happy medium so you can prevent burnout!
3. Avoid loneliness. When you work remotely, it’s easy to fall into the trap of not engaging in social interaction. So, make a point to set a time for a video coffee break with one or more of your coworkers, so you can chat and catch up just as you would do in person in an office break room.
4. Find structure. A major benefit of working remotely is setting your own routine. At GitLab, our average workday is 7.5 hours, but those hours can be worked anytime. If you find that targets are more responsive to calls or emails at 2 p.m. local time, structure your day around that. Don’t be afraid to experiment to find the optimal work schedule to support your career success.
   
   
5. Be flexible. It’s impossible to take an office environment and recreate it at home, so don’t try. Experiment with options. Make good use of technology. And seek advice and ideas from people with remote work experience, as well as from those who are just setting themselves up for remote work now, too.

A key takeaway from the playbook is that transitioning to remote work, even if it’s only temporary, is a process. It can take time, and some trial-and-error, to get it right.

Opportunities to “Take a Break” and connect

Cultivating a sense of community is important for all of us here at GitLab. One way we foster community is through our twice-weekly “Take a Break” calls. These calls run every eight hours throughout the day so that employees in all time zones can participate. There are four or five different chat rooms where GitLab employees from around the world can talk about everything — from our pets and hobbies to how we’re coping with the COVID-19 outbreak.

GitLab’s Remote Manifesto #

I know that many companies are scrambling right now to develop a formal remote working policy. What’s our policy at GitLab? It’s simple: We all work remotely. However, we also have a set of core values that shapes our remote workplace — our Remote Manifesto.

It makes clear that GitLab, as an all-remote company, promotes the following:

1. Hiring and working from all over the world instead of from a central location.
2. Flexible working hours over set working hours.
3. Writing down and recording knowledge over verbal explanations.
4. Written down processes over on-the-job training.
5. Public sharing of information over need-to-know access.
6. Opening up every document for editing by anyone over top-down control of documents.
7. Asynchronous communication over synchronous communication.
8. The results of work over the hours put in.
9. Formal communication channels over informal communication channels.

Also, every person in GitLab’s 1,250-strong workforce, which spans 65 countries and regions (and counting!), is considered equal. That includes our CEO Sid Sijbrandij.

The main takeaway from all of this (I hope!) is that working remotely doesn’t mean acting remotely. At GitLab, everyone is encouraged, and provided with many opportunities, to interact and contribute. What works for our all-remote team may not work for yours, but I can tell you that I’ve never worked for a company where I have felt so connected and informed.

Elsje Smart is Senior Sales Development Manager for GitLab’s Europe, Middle East, and Africa (EMEA) region. She lives in Marazion (pop. 1,440), a picturesque coastal town in Cornwall in South West England, not far from historic St. Michael’s Mount. GitLab, headquartered in San Francisco, is a complete DevOps platform, delivered as a single application designed to provide higher levels of efficiency across the DevOps lifecycle. Founded in 2014, the company has announced plans for an IPO with a target date of November 2020.