With more than 1,200 employees distributed across over 65 countries and a valuation of nearly $3 billion, GitLab is one of the world’s most successful fully remote startups.
Describing it as a textbook example of a remote company would be redundant, because the company actually wrote a textbook about it.
I recently had a chance to talk to GitLab’s head of Remote, Darren Murph, who filled me in on how they get stuff done, his advice for all the companies that had to suddenly shift to remote work and why GitLab gets rid of all its Slack messages after 90 days. (Fun fact: Darren wrote for TechCrunch’s corporate cousin Engadget in a past life, where he earned a Guinness World Record for writing an absolutely ridiculous number of posts.)
Darren and I chatted for quite a while, so I’ve split the transcript into two parts for easier reading. Part two coming tomorrow!
TechCrunch: So your official title is “Head of Remote.” What does that entail?
Darren Murph: It’s three things.
It’s telling our remote story to the world, it’s making sure that people who join the company acclimate to working in an all-remote setting and it’s building out the educational piece. The “all-remote” section of our handbook has dozens of guides on how we do everything remotely, from async, to meetings, to hiring and compensation, and I’m the author of all of that.
We do that to better the world; we put it all out there, it’s open source. We want other companies to read it, implement it and use it. We never saw COVID coming, but I kind of knew that down the road [this handbook] would be necessary. Thankfully, I started working on it in advance. Now that the world needs it… it’s been crazy. We packaged up our best thinking in that remote playbook, and it’s just been off the charts with companies downloading it. It’s been wild.
Why did GitLab go remote in the first place?
It was remote by default. The first three people to join the company were in three different countries… so the only way to do it was through the internet.
The one brief moment in time where there was a co-located wrinkle to the company… they’d moved to California for Y Combinator. I think there was like nine or 10 people at the time. Of course, coming out of Y Combinator, at the time, you just get an office — it’s just what you did.
I think that lasted about three days. Then people just stopped showing up.
[Laughs]
But work kept getting done! Because even in the office they were just communicating on… whatever it was at the time. It probably wasn’t Slack, I don’t think Slack existed.
They were like, “this is dumb, we’re not going to commute!” They just stopped showing up, and then they thought… “let’s just not pay for a lease. We could spend this money on people and build the team faster.” Why wouldn’t we do that?
I want to walk through GitLab’s processes a bit — some of the things you do every day, but maybe a bit differently than some other companies. Let’s start at the beginning. I’ve learned that with most remote orgs, most remote jobs… when you put a role out there, you get about a zillion applications. Does that hold true with GitLab?
Yes. Yeah. I forget what the number is, but we actually just changed our recruiting model because it was so unmanageable. It was like 3,000 applications a week. It was just… crazy.
I hired for a role on my team in March. I think I posted it in December and I was getting like 500 applications a week. And I’m not talking about people just blindly clicking “Apply!”… I’m talking about people taking hours of time, amazing cover letters, they made full YouTube videos to apply for the job. That kind of quality, 500 a week.
How do you filter through that? How do you even make a dent?
It was like my full-time job just to look through all of it. But we actually just changed our recruiting model to be primarily outbound.
Typical inbound, just letting people from outside apply… it was just impossible. [Hiring remotely] is just the number-one competitive advantage; people want a remote job more than anything else.
For people that value remote… think about this. You have two job offers; one from GitLab and one from some co-located company. You look at things like salary, job title, prestige… those main things. One thing that GitLab can offer, above all that, is infinite flexibility and autonomy. You can live wherever you want. You can change where you live every week, if you want! For somebody that values that, there’s literally nothing that some other company can throw at you that would match it.
And there’s this massive swell of people that value that autonomy and flexibility over everything else — especially with senior-level people, where they have the portfolio to prove [themselves].
So we moved to the outbound model because it was just impossible to deal with the influx. It was just not manageable, not scaleable.
It also allows us to do something that’s very core to who we are. If you look at our values page, there’s a sub-value in there… and those sub-values are very important. They’re a substantiator of the values.
The only way you can define culture in a remote setting is to write down your values, and then write down how you live those values. It’s not enough to write down the word “collaboration”; collaboration means something different to every human on earth. So we have paragraphs on how collaboration is exemplified and live.
One of those sub-values just says that “Culture fit is a bad excuse.” We intentionally do not hire for culture fit. We hire for values fit.
What’s the difference there? What’s the difference between culture fit and values fit?
Here’s how culture is primarily defined: it’s the energy, the vibe in a room. Let’s dig one step deeper; how do you get to an energy, and a vibe? One of two ways: office decor, lighting, painting, flowers, a weird elephant… that’s one element. And then it’s the charisma, or personas in the office. The loudest voices, the sharpest dressed, the cross-talk that catches your ear.
That’s how most companies allow their culture to be defined… which is a terrible way to do it.
What if somebody’s not there for a week? What if socio-economic issues happen and the mood changes? Now you’re just letting the culture of your company oscillate with the wind?
In a remote setting, you can’t do that. There is no painting, there is no office furniture and there definitely aren’t any voices in the room.
The only way to define culture in a remote setting is to write it down. It’s your values; the values are the culture. So we hire for values fit because if people align with our values, that is the culture we want to create. We want to create an aligned culture, with people that universally look at the North Star of our values.
We want to be able to find people in pockets of the world — ideally underserved pockets of the world that most companies are missing out on, because they’re not in San Francisco, London or Singapore. We want to find those people — like me, in a rural pocket of North Carolina. That’s the talent we want because that person is going to massively align with our values, he’s going to massively appreciate the autonomy and flexibility, so he’s going to be very loyal to the company and not likely to be poached or leave for any other reason.
GitLab is at 1,200+ employees, in 65+ countries… At this point, is time zone even something you consider?
No.
Time zones are difficult, but they’re no more difficult for us than a co-located company.
Here’s what I believe about time zones: Time zones get easier as you scale an all-remote team, not harder.
If you have four people equidistant from each other with eight-hour overlaps, work is going to be hard. Somebody is going to have to be up in the middle of the night if you want to have a meeting.
When you have 1,200 people… the hand-off gets a lot easier. You start filling in the gaps as the world turns. It becomes less of an issue as you scale an all-remote team, but it becomes more of an issue in a co-located space, because if you have an office in London and an office in Singapore and an office in Phoenix… as those grow, now you have 40,000 people that are permanently X amount of hours off from each other. Total nightmare.
One quick aside on the time zone thing: it forces us to be more asynchronous, which we want to be anyway. An ideal day is no [real-time] meetings anyway — let’s do all the work we can within GitLab (the product) asynchronously. It pushes us to get better at doing work async so we don’t have to have people on at the same time.
Tell me about your onboarding process a little bit. When there are 1,200 people all over the world, how do you make [a new hire] feel like they know what’s going on?
You have to shift the burden of onboarding from humans to documentation. That’s the only way to make it work.
Sometimes we have 30-40 people a week joining. That would mean you would need like, 30-40 HR managers to walk people around the virtual room. Never gonna happen.
So we have the most prescriptive, comprehensive onboarding I’ve ever seen. Every [new hire] gets a GitLab Issue on day one, and there are hundreds of checkboxes organized by day. Day one through five, days six through 10, etc. It goes ’til about week six. It’s very in-depth; very, very long. And you know when you’re done. Have you checked all the boxes? Then you’re done.
Everyone goes through the exact same onboarding, with a few additional modules if you’re in engineering, or finance or HR. But everyone goes through the same base onboarding issue. It helps you learn GitLab, and it’s very prescriptive; you know exactly what to read, exactly what you need to get yourself up to speed.
One thing we pair with that, so it’s not a completely cold or isolated experience, is something we call an “onboarding buddy.”
Everyone at GitLab gets another person from the company, outside of their department, to join them as a dedicated one-on-one contact through their whole [onboarding] journey. This person shares their Zoom link and their Slack, and the new hire has full permission to ping them as many times as they want so that they’re only “bothering” one person.
This person connects all the dots for them. It makes [the new hire] feel like part of the team and it also lowers their anxiety. They’re not like “I don’t know who to reach out to… do I just spam the whole Slack channel?” Like, no, just go to this one person.
I’ve actually told these suddenly remote companies that are dealing with all this right now… “Look, you might not be able to document your entire onboarding system overnight, but you can implement a buddy system overnight. Just pick a mentor and pair them up.” People feel better when they have someone to lean on.
That’s how our onboarding works. It’s very long; it’s a good six weeks. The first few weeks, pretty much no work happens, because we want people to read. We want people to read the values, we want people to read what we do. We write down everything; it’s the only way for the communication to work across 65 countries. It has to be written down. The people that work here need to love reading, and they need to love writing, and they’re going to do a lot of it. That may not be amenable for some people, but you’d know it early on; no one accidentally ends up at GitLab. They very much opt into the process.
Those onboarding buddies… how are they chosen? I guess I’m kind of getting in the weeds here, but I’m curious. Does everybody eventually become an onboarding buddy? Are they volunteering as tribute?
You can volunteer! You can add it to your team page profile that you are willing to be an onboarding buddy.
At a base level, though, it’s chosen by a manager. Here’s the logic that goes into it: The manager thinks, “I want to find somebody that’s got at least six months of experience at the company, that’s not directly in the same department, but where there’s enough overlap that there’s some things they’re familiar with.”
We try to look for complementary onboarding buddies. If you have a new hire coming in and you know they’ve never worked remotely before… that manager would probably pair them with someone like me, who has experience in remote. Conversely, I came in, I’d never used GitLab (the product) before… my buddy was somebody that knew Git and understood the technicalities of it, and my manager chose him because she thought there was no one better than this person to give me a deep dive, one-on-one tutorial on GitLab.
Instead of me having to be like, “uh, I don’t know how to use this… can anyone help me?” my onboarding buddy was like… made for this. Look for those complementary assets.
Speaking of remote experience… what’s the mix at this point? Are most people you’re hiring coming from remote backgrounds? Is that something that gets factored into hiring?
It’s not something we factor in, per se. That question is hard to answer, and here’s why: Almost everyone has worked remotely at this point.
Even if they came from [an office], you could ask “…did you ever work on an airplane? Did you ever work in a hotel room at a conference?”
Like, we all get it. Even if their role wasn’t remote, they probably [worked remote]. Even in university. Ask a college student: “Did you ever help move a project along from your apartment while your cohorts were on campus?” Of course. So in some ways, everyone comes to us from remote.
What’s more rare is for someone to come from another all-remote company, just because there aren’t that many. Most people have some amount of remote experience — but still, the majority come from a conventional, co-located company, because that’s how most companies are run. I think if you ask again in 10 years, the balance will have shifted a lot more.
Once folks are onboard, they’re all settled in… where are you communicating? Where does company communication live?
We’re very intentional about how we communicate. The communication page in our handbook is one of the longest, if not the longest, pages in our handbook.
And this is where most co-located companies fail [at remote]: there are no guidelines on communication.
When I tell people this, they’re like, “wait.. you have to write down… how you write down things?”
We’re very prescriptive about it: here’s where work is communicated, here’s where non-work/informal communication is communicated. All of our work communication happens in GitLab — in an issue, or a merge request. Or on Zoom, if we’re having a video chat.
All of our non-work communication — things like parents talking about parenting, hikers talking about hiking, music… topical stuff — happens in Slack. No work happens in Slack.
We expire all of our Slack messages after 90 days. Gone. Bam. Done. Here’s why: Humans are lazy. If we did not do that, it would be way too tempting to start an idea, or a project, in Slack instead of where it needs to be, which is a GitLab issue.
So we implement these really rigid forcing functions — I call them forcing functions. Because people know it would be silly to start a project in Slack because you’re going to have no context or memory of it in three months… so don’t do that!
It works great.
The other side benefit of it is that it makes Slack amazing for informal communication. For most people, Slack is a waking nightmare because the red bubbles mean work is waiting on me. At GitLab, a red bubble is like.. oh! Yolanda probably has some cool tip about wrangling her seven-year-old, I’ll get to it when I get to it! So our anxiety is way lower on Slack, because we intentionally make Slack a place where work doesn’t happen.
I’d bet it also gets rid of that fear of missing things on Slack. You don’t come back to a wall of 300 messages and feel like you have to scroll all the way back up and read everything. If it’s work, if it’s important, it’ll get thrown into the proper format.
Exactly. And we have to be very prescriptive about that, to keep those guard rails up, because otherwise the lines between work and life can blur too easily, and then you end up on the road to burnout.
I think [too many] companies aren’t intentional about “work happens here, non-work happens here.” If you’re not intentional about it, and you just let people cross-pollinate, communication gets fractured. You get a project that starts in Slack, and continues to email, little bits in GitLab… how are you going to keep up with that at 1,200 people? It’s a disaster waiting to happen.
This is the biggest issue with these suddenly remote companies. In a co-located space, you can [have a bit of communication everywhere], and you can Band-Aid the communication gaps by just calling an ad hoc meeting… instead of fixing the root problem. Get disciplined with your communication!
It forces us to be more disciplined, which makes all of our lives better.
Do you ever get through the hiring process, through the onboarding process, and people have done their six weeks and gone through the checklists only to say… you know, this remote work stuff just isn’t for me?
Very infrequently.
We have a voluntary retention rate of around 85%, which is astronomical compared to anything else in the Silicon Valley tech space. Almost everyone that comes in wants to stay.
The reason is that we’re very articulate about the onboarding. It’s like… it’s pretty hard to botch it up. You either check the boxes or you don’t.
It just doesn’t happen very much. If you got all the way through that process… like, 99% of our inbounds are rejections. Only 1% even make it through to an interview at all. And everyone you interview with is over a Zoom call; there’s never an in-person moment. That’s either going to vibe with you or not. Like by the fifth Zoom call, if you’re not okay with it… it’s just this process of self-selection. Most people who make it this far want to be here.
I know GitLab has been remote forever, but this isn’t really a normal time for anyone. I would say 90% of [TechCrunch’s] editorial team is remote. But even for us, it’s a bizarre time, and it’s hard to get work done. How has the pandemic impacted your team?
It’s impacted us probably the least of any company on earth, because this is very much how we’ve always operated. It’s how our IT structure has always operated. Everything is in place for us to be isolated [and still] work.
The two biggest things that have changed for us…
For parents? Our team isn’t used to having to pull double-duty as homeschool teachers. We have a lot of parents on our team; remote is very amenable to parenting, so we have a lot of parents here that now have kids at home.
So that’s changed how they are able to work. It’s shifted up their days. We’ve been very intentional about saying, “friends and family first.” Like we have some people that are working massively reduced workloads, and it’s shifted over to their team, because there’s no other option. But we’re better equipped to handle that than most other companies because we already work asynchronously. We’re used to people working weird, non-linear work days, coming in and leaving, coming in and leaving, we’re used to it.
The other wrinkle: We don’t tell people they have to work from home. We understand that not everyone’s home is amenable to remote, so we will reimburse co-working fees. The problem right now? No one can go to a co-working space. About a fifth of our company took us up on that every month! So we have a fifth of our company now that has been forced back into their home just like everyone else in the world, but home is not where they ideally want to work. So for a fifth of our company, there’s more friction than for the rest of us. They’re like, “agh, I can’t wait ’til my co-working space opens back up.”
Those are the two things that come to mind. But man, I gotta nit-pick to find those. On the whole… if we could just put blinders on and pretend nothing was different about how we go to the grocery store and get our food delivered… the actual work is very much the same.
And I think other companies are recognizing this. They’re realizing how much they could de-risk their business by decoupling the results with geography. What I mean by that is… take a business that’s based in Milan. One of the hotspots in all of this. They’re being more significantly impacted in Milan than like, Phoenix, for example, even though it has nothing to do with their business fundamentally. They just got super unlucky and a socio-economic crisis happened in their city.
So now you have business leaders that are like, “what can we do to avoid that?” Well, [you could] not have an office. Look back even further… any business based in London when Brexit hit. No one could see that coming, and now your business is permanently negatively impacted by something that has nothing to do with your business?
[Remote] is starting to make sense. [..] Decouple yourself from geography as much as you can. I think people are looking at companies like GitLab and seeing that. I actually spoke with a company in Asia a couple of days ago; they have two offices for two hundred people. Now they’re all working from home. They’re not renewing the lease on one of [those offices]. They’re keeping one just so clients can come in… but they’re like, “we have to get this right, because now we have 120 people that will never have a desk again. We have to get remote right.”
I think you’re going to see more of that.
