How to manage a fully-remote team of thousands at scale? What does a Head of Remote do? How to make a team of 1,200 people feel connected when they have never seen each other face-to-face? What’s the best first step that a company wanting to transition to remote should take?
These — and also, of course, the COVID-19 pandemic — are some of the topics that Sergio, our CEO, covered in conversation with Darren Murph, Head of Remote at GitLab, in our second episode of Working Without Borders, Get on Board’s podcast.
Darren leads and documents GitLab’s remote culture, and also evangelizes it to the outside world — part of the core mission of GitLab is making sure other companies can go remote too. GitLab is one of the pioneers in promoting a fully remote team, and the largest remote team in the world— more than 1,200 people working from 65 different countries.
📻🎧 Listen to the podcast right now below (also available in Anchor and Spotify).
👉🏽 Here are the main highlights of the conversation with Darren (held, most appropriately, remotely — Darren from his home in North Carolina, and Sergio from San Francisco):
- Remote is not just copying and pasting from an in-office environment. The difference between co-located and remote is not merely the location. It’s an entirely different way of thinking about work, performance, and communication.
- Darren doesn’t believe that an ‘in-office culture’ is a thing. It just means that that team only knows how to work in synchronicity, when everyone is in the same room at the same time.
- Remote communication needs to be intentional and deliberate — even informal communication needs to be designed, documented, and evangelized to create virtual spaces where people can bond and trust each other.
- The remote setting forced by the coronavirus pandemic is just a crisis-driven change, where health and safety are most important. Only the most agile companies, able to adapt and reinvent themselves, will benefit from the change in the long term. The ones that are just trying to weather the storm and revert to synchronicity as soon as they can, will reap no benefits.
Read the transcription of the interview below, lightly edited for clarity
Episode transcript
Sergio Nouvel: I’m Sergio Nouvel, and this is the second episode of Working Without Borders, a podcast about running remote and distributed teams, brought to you by Get on Board. For this episode, we have a fantastic guest: Darren Murph, Head of Remote at GitLab.
GitLab is probably one of the few tech companies that have pioneered a fully remote approach for several years now, so we’re really excited to talk to you Darren, and learn some first-hand insights on GitLab’s journey. So, welcome!
Darren Murph: Absolutely! Thanks so much for having me.
Sergio: Thanks so much for being here. So, I think the first question is about your job title. Not so many companies have a Head of Remote, so: What is your role about? And, how did you come up with this role?
Darren: The title was arranged and delivered in the most GitLab-way possible, so this was not my original title. Essentially, when I came into the marketing organization, I was working with Marketing to evangelize and communicate with the press and the media about how GitLab was pioneering culture, and what we were doing on the people’s side. A lot of people know GitLab for the DevOps side, but are less familiar with what we’re doing on the people’s side.
We are the world’s largest all-remote company, so we have over 1200 people spread across more than 65 countries with no offices. Even the executive team, they all work remotely. It’s completely transformational. There’s nothing else like it. And so, when I first came in, that was my role, but it has expanded quite a bit.
And at the back-end of a panel that we were hosting with our partners General Catalyst, Andreas Klinger, who works at AngelList — he was chatting with myself and our CEO, Sid — and he was listening to what I did, and he told Sid, he said ‘my title is Head of Remote at AngelList, but it’s kind of this Frankenstein title. It’s not very indicative of what I actually do. It should probably be more like Head of Remote Products. What I’m hearing here is this guy (Darren) actually is more eligible for my title than I am, so I think you should change his title’. And so Sid left the event and went, hopped on GitLab, and made a Merge Request to change my title to Head of Remote, and more fully encapsulate what I was doing at the company, and then that was merged. So we used GitLab to change my title to Head of Remote, which is a pretty funny story.
But, in addition to the evangelizing I do, and speaking with the press, and things like that, I work with talent branding, and onboarding, and the people group to make sure that remote members of our team feel acclimated, and they have the tools that they need, the processes that they need because it can be a very different experience — especially if you’re coming from a co-located space.
And then, the last part of what I do is what I’m most proud of, which is maintaining and growing the all remote section of the GitLab Handbook. So, if you [check out] GitLab’s guide all remote, you’ll find 30+ guides on how we do everything remotely, from asynchronous to meetings, to hiring and compensation, to learning and development. Every aspect of how we do it, I have written down and documented. And I’ve written it in such a way that any other company can look at this and implement it. We’ve open-sourced these learnings. We view our legacy in the world as tied to what we can do to proliferate the ubiquity of remote-first and all-remote companies, and so, being able to maintain and grow that section of the Handbook is a really amazing opportunity.
‘This is a fundamentally new way of working.’
Sergio: Yeah, that’s amazing. And I’m also wondering, how does your role differentiate from — for instance — People Operations or a COO’s role? Do you have at GitLab those other roles? How do they play out?
Darren: We do actually have a People team and what’s interesting… Well, GitLab is unique in that we’re all remote and we’re 1,200+ people, and so very few companies have this to rally around, they don’t really need someone leading this… yet. And I say yet because there are a lot of companies that are transitioning to remote, either unwinding offices altogether and becoming all remote, or they’re getting a lot more serious about implementing a proper hybrid remote infrastructure. And the difference is Operations and People.
So from an operational standpoint, you look at things like efficiencies, run rates, sales metrics… These are the kind of core efficiencies that you need to operationalize any business, whether it’s co-located or remote. And on the people's side, you have things like: How do we make sure people get paid? How do we make sure people have a good reimbursement system? These are the kind of nuts and bolts of helping people thrive in any company, co-located or remote.
But the difference in our remote company is you have this third area where people who could be coming in from a co-located space: Let’s say you come in from 20 years in an office and you’ve had professionals design your workspace, so you have an ergonomic desk, an ergonomic chair, you’re given a laptop and a monitor, and everything just works. You have professionals that designed this for you. And you join an all-remote company, and just setting-up your workspace in your home is completely on you now. So the burden is shifted from this professional services organization to you.
And that’s an amazing opportunity, to build a workspace that’s designed for you. Especially for people with disabilities, to be able to build an accessible workspace that’s tailored to them. There’s nothing else like it. But, it is kind of daunting, if you come into it, and remote work isn’t second nature to you. So I’m responsible for building guides and being an advocate for people that this is new to them, and they’re integrating into an all-remote workforce for the first time.
The reason I say that I feel like more companies will have this: There are certain elements, to setting up a remote infrastructure, that don’t neatly fit into People and they don’t neatly fit into Operations. This is a fundamentally new way of working.
I’m seeing a lot of companies trying to transition to remote and they’re essentially trying to copy and paste an in-office environment and just replicate that remotely, which is a pretty poor way to go about it. If you look at your meetings’ schedule — and there’re, you know, various board rooms — so you just try to replicate those in Zoom without actually thinking through, ‘hey, is this the best way to work? do we actually need this meeting? should I just start a GitLab issue, for example, and tag the right people and we work on this project asynchronously?’.
There’s a lot you have to think through. It’s a fundamentally different way of working. It’s not like the difference between remote and co-located is simply the location. It’s a completely different way of thinking about work and implementing different forcing functions to help teams work better and more efficiently. And you really do need somebody that has lived that for quite a while to understand those best practices, and what the experiences are, and what the expectations are, and to help people get there if it’s completely far into them.
‘How do you know if a remote team is actually working?…well, How would you know if they were working in an office?
Sergio: Yeah, and that leads me to one of the questions I have, which is: in the case of software engineers, code — let’s say commits, a merge request, you name it — usually is the best proof of performance and delivery. So, how do you measure that performance and delivery for remote workers in non-engineering positions?
Darren: It’s a great question. So it’s really role-dependent. I’ll give you an example: on the Marketing team, we measure things like, ‘How many GitLab mentions do we see in the press? and: What does our competitive intelligence look like? and: Are we gaining share of voice against certain terms that we view as important?’ So you can measure all of these things, and we firmly believe in results over hours. So for us, it’s pretty easy. There is no set working time.
GitLab is completely asynchronous, so it’s not like there’s a rigid set of hours that we try to lock ourselves to. And so time becomes relative. My 10:00 AM is someone else’s 10:00 PM, and then there’s a bunch of in-betweens. So we think less about ‘how many hours are you working?’ and more about managers are responsible for creating objectives and key results (OKRs) and metrics that are relevant to whatever they’re trying to get done. Whether that’s in finance or marketing or any other non-developer function. So they look very different from function to function, but the common thread is that they’re all hard numbers. They’re all very clearly defined. And this is, I think, this is really at the heart of it.
If you’ve ever heard, ‘how do you know if a remote team is actually working?’ This is almost a comical question for me because it’s like, well, how would you know if they were working in an office? I mean, you shouldn’t just judge someone — just because they’re sitting in a seat, doesn’t mean that they’re productive. Just because you look at someone across the office and they smile, it doesn’t mean that they’re having a good day. Like they could easily be masking real pain. You can’t just judge someone because they are in a certain place or because they look a certain way. So the question really becomes, are you sure you have the right metrics in place? Do your team members actually have solid metrics that are relevant to their specific job?
And in an all-remote setting, it forces you to get that right. You can’t mask it with kind of this torturous loop of meetings that look like work. We actually have part objectives that we need to accomplish and it’s easier in an all-remote setting to say ‘you know, I’m actually not sure what I’m supposed to be accomplishing, can we get some clarity on that?’ In an office setting, it’s a little bit taboo to ask that, but in an all-remote setting, it’s mandatory. We have to know what we’re working towards because you cannot see each other work, so we can only measure on those results.
‘…spending money on the lease was a really unwise thing to do. That money could be better spent on people, tools, and technologies.’
Sergio: I was also curious about whether you had to undergo a transition process for GitLab, or was it like that from the very beginning? and if it was from the very beginning, what made GitLab embrace remote-first?
Darren: GitLab was all-remote from the very beginning. The first 3 founders were all in different countries, and so they really had no choice but to work asynchronously. It was all-remote from the start.
Now, I will say, when a small contingent of GitLabers came to California for YCombinator because it was just the thing to do when they graduated from the YCombinator, they did get an office briefly in the San Francisco Bay Area, because it was just the thing to do. And within a couple of weeks, everyone stopped showing up. I mean, it made no sense. Work kept getting done. People didn’t want to bother with the commute and it was already ingrained in the culture to document processes, document solutions, and work remotely, and it just quickly became apparent that spending money on the lease was really unwise thing to do. That money could be better spent on people, tools, and technologies. And so that office kind of faded out really quickly and it’s been remote since day one.
That has made life a lot easier. It is much, much more difficult to kind of unwind an office setting and integrate remote-first practices if you’re a very much asynchronous culture. And I’m careful the way I word that because you’ll oftentimes hear people say: ‘oh, this isn’t going to work for our company because we have an in-office culture.’ It’s like that’s not actually what they mean. What they mean is that they only know how to work in synchronicity. They only know how to work if everyone is available at the exact same time. And that’s the challenge that they’re facing. The remote thing has nothing to do. Well, has very little to do with it. It’s the synchronicity part that is the most challenging, I think, for most companies to wrap their head around.
[a remote work environment] takes time, takes intentionality, takes thought, takes planning, takes documentation.
Sergio: Regarding other companies… it’s probably obvious these days, given the rising concerns about coronavirus — that many, or most companies, are considering remote or are even being forced to work remotely. So, which workplaces or which cultures do you think are going to be best prepared for that transition to remote?
Darren: This is an interesting time. I feel like coronavirus has accelerated the world’s appetite for remote by at least five or ten years. It’s incredible to see that happening, but it’s not an ideal situation by any means. And just to be clear: talking about remote work is very secondary to the actual health crisis. That’s obviously the most important part here.
But you’re right, and because of that a lot of companies are being thrust into a remote situation. But I want to be clear: what you see happening is not indicative of remote work, necessarily. What’s happening is, this is crisis-driven work-from-home, which is very different than an intentionally structured remote work environment. Because that takes time, that takes intentionality, that takes thought, that takes planning, that takes documentation.
And so, essentially, what is happening in mass is that you have thousands upon thousands of people that are ripped out of one space and put into another space with no planning, no preparation, limited documentation, and no Head of Remote on a team. These companies are not prepared for this. They do not have people on board already that understand the nuances of remote and how to get people to transition to them. So that is not an ideal situation by any means.
‘It’s worth the effort to figure out remote because this is only going to become more of a thing, not less.’
But I think you’re going to be able to look back in six months and you’re going to know the companies that are most adept at being agile and kind of rolling with the punches. Because there will be some companies that look at this and say, ‘OK, this is not the ideal way we wanted to go remote, but it is what it is and we’re going to make sure that we go heavy on documentation, that we give ourselves the grace to kind of iterate through this and figure out the communication gaps and fill them as they come.’
And then there will be some companies that say, ‘this is a short-term thing, we’re just going to kind of fumble our way through it. Eventually, we want to get everybody back in the office anyway, so let’s just make the best of it.’ But I think that’s a really poor way to go about it, and here’s why: almost every company already is remote, even if they don’t want to admit it.
What I mean by that is, if you have a company with an office in Seattle and an office in London or Singapore, those two offices are remote to each other. All of those people that work out of both offices, they don’t see each other on a regular basis. They have to communicate across massive time zone gaps. They have to help each other on projects. It’s worthwhile to use this as a forcing function to implement a remote infrastructure, even if you don’t intend to actually hire a massive contingent of people that never come into the office. All companies, for the most part — unless you’re a really small company where everybody gets together on the same floor— if you have a company that’s spread across one office building or two office buildings, these people are remote. You have people traveling on airplanes. When they’re gone on their conferences, they’re working remotely.
It’s worth the effort to figure out remote, because this is only going to become more of a thing, not less. We’re certainly not going to rewind the clock and get more people into the office. This is going to show people, ‘hey, I can actually be autonomous. Work from a place that’s not the office and still get my job done.’
Sergio: Have you felt any impact, as a team, from the current situation and the health concerns?
Darren: Well, an all-remote company is the most de-risked from things like this, and so, — I mean, you can read this in the Handbook, but — part of being all-remote is we are less impacted by socioeconomic factors that apply to specific regions of the world.
And so, for the most part, it’s been business as usual for GitLab. We use Google docs, Slack, Zoom, and GitLab (the product) to do pretty much everything. And, for the most part, we all work from home. We have about 1/5 of the company that regularly works in a coworking space or an external office. GitLab reimburses those expenses. We don’t say you have to work from home, we just say: there’s no office to commute to. We recognize that for some people home is not the ideal place to work, so we will happily reimburse coworking or office expenses. So for some of those folks, they may have had to shift back to home instead of the usual coworking space, but on the whole, no real hiccups for us.
The only thing it has triggered is a massive surge and interest in remote, so we’re helping as many partners and companies as we can. It’s part of our vision to help in any way we can. So there’s been a lot of activity on that front, but in terms of the day-to-day work, it’s pretty much the same as usual.
Sergio: On helping other companies: one of the things that called my attention is that GitLab has had this remote manifesto for years. What do you think its impact has been on other companies or teams?
Darren: I think it’s given teams permission to embrace this. It’s one of those things where… there was this in-between time, where people weren’t so sure if it was OK to give themselves this much autonomy and empowerment, like, ‘Do you lose some kind of prestige or mystique if there’s no office attached to it?’.
There’s a certain level of ego that’s attached to a shiny sign across the storefront. I get that. And it’s like, ‘Can you take a company seriously when there’s no office? And can you really scale it?’ Of course, it works with 10 or 15 people, we get it. But at a thousand? Is that even possible? And I think GitLab has done an amazing job of kind of carrying that flag and being the pioneer and sort of writing the script for how it is possible. And we’re documenting all of our learnings, and even some of our struggles — I mean, I’ve stood up at all-remote page on asynchronous and, at the bottom of it, there’s an entire section on the limitations of asynchronous.
So we’re being honest and open about our challenges, just as much as we are of our successes. And I think people really appreciate that because, on the whole, there are far more pros and benefits to working remotely than there are drawbacks. And we’re not trying to hide the drawbacks because all of our Handbook pages are open to contributions, and so, if we put challenges out there and someone else solves it, we want them to make a Merge Request and tell us how to make it, how to do it better and we want to work with as many remote companies as we can. Write this script and help this concept proliferate as best as we can.
‘Soon, the co-located companies are going to need to justify why they continue to spend money on office space when a zoom call would work just as well.’
Sergio: Have you received any unexpected or unprecedented insights from other companies while building this Handbook?
Darren: There’s a jobs page within our remote Handbook where we list remote first and all-remote companies. And one thing that I’ve been surprised about is just how many companies there are that are hiring remotely. I get merge requests regularly from smaller and midsized companies that it was sending merge requests and say ‘hey can you add our company to this page? We are an all-remote company — or we are our remote-first company — and we’re hiring remotely from anywhere in the world’, and it’s always just so pleasing to see so many of these companies popping up, and I love that.
I think the second thing is — and Sid has touched on this before — where, initially, in fundraising, there were venture capital firms who were quite skittish about remote, and a lot of them passed on investing because they just weren’t sure if remote could scale. And a lot of them that passed early on, now come back. And not only have they said ‘we wish we would have’, but now they are advocates for it.
In fact, there are some VCs that are building in expertise on remote and want to be known as VCs that are remote-friendly, because they see so much opportunity in the space, they want to be the first ones to invest. And it just makes sense. If you think about a conventional start-up getting a seed round and, if they have to spend a good chunk of that on real estate, think about how much higher the success percentage is, if they can redirect that money from real estate to people. It’s not rocket science.
The more money you’re able to spend on good people doing good work, it’s much better than a piece of real estate that ties you to a certain place that you don’t even own, limits your region in terms of who you can recruit, puts you in a bind, trying to match salaries of multibillion-dollar multinationals. It just doesn’t make sense.
We’re reaching a tipping point where no longer will the remote companies have to justify why they do it the way they do it. Soon, the co-located companies are going to need to justify why they continue to spend money on office space when a Zoom call would work just as well.
Sergio: Yeah, absolutely. I’m also interested in what happens beyond the workplace — and even in our remote workplace — and what happens with team-building and creating a sense of belonging among people working in different countries and time zones.
How do you make sure people feel connected and belonging to each other?
Darren: So, in general, remote forces you to do things that you should be doing anyway, just more quickly and way more intentionally. And informal communication is no different.
So GitLab is the most intentional company I know on the topic of informal communication. In fact, we have a Handbook page dedicated solely to that. So if you [check out] GitLab informal communication, you’ll see that we have a page and we’ve iterated a lot on that over the years.
We do things like coffee chats, where you can just grab 20 minutes of time from anyone and just kind of get to know them. We have group social calls and group pizza parties — kind of this 24-hour cycle of pizza party where it’s always dinner time for someone, and then, an hour later it’s dinner time for someone else, and then an hour later… We share all these photos with pizza parties with our families and Slack and it goes on for 24 hours around the clock. It’s pretty phenomenal.
But you know, the thing is, in a co-located space you’ll see companies do things like put the restrooms at the center of the building so that people ‘spontaneously’ run into each other and kind of form and foster relationships. But you got to ask yourself: is that really the ideal way to get to know someone? Is that even great? I mean, we ask that question as if it’s a poor experience remotely, but is it even a great experience in a co-located space? I’m not so sure.
And the other thing it masks is, ‘Should we really be putting ALL of our focus on relationships at work?’ or ‘Should we be asking ourselves how much more time could we spend with our family or in our communities if we didn’t spend so much time commuting to work?’ Because I think that’s where the long-lasting bonds are. It’s connecting in a community that matters to you and spending more time with the family that’s going to be there long after a job change.
For GitLab, the other thing I’ll add is, we have people in over 65 countries and we have a good example as a show in the telemarketing call, so every month or so we’ll get the whole Marketing team on a big Zoom call. Whoever wants to participate can show something off to the webcam. Something they built or something that their family built. And you know you get some really cool insights on what people build across 65 countries. It’s pretty fascinating the things that will show up on those calls that aren’t common in North America, for example.
So you’ll have someone Show & Tell something from Europe, or South Africa, or Asia and then they get to tell you about all the things that they do in their everyday life, and it’s like, ‘wow! that is genuine, intimate, cultural connection’ that you can’t easily get in a co-located space. When you allow people to live where they want to live, they bring all of themselves and all of that culture. And in some ways — well, in most ways — I think that connecting remotely is more genuine and more authentic than in the office because you have to check a certain part of you at the door when you walk into an office, but that’s not the case on a remote team.
‘It’s phenomenal the input that you can get when you let people stay where they are.’
Sergio: That’s fascinating, and also makes me think about: how do you think this remote culture has affected diversity at GitLab?
Darren: I will say that we have the most authentically geographically diverse team of any company that I’m aware of. What I mean by that is: let’s say you have a company in a major urban center — let’s say London — and it’s a diversity and inclusion metric to make the team more diverse. So, even if you had that metric and you set out to hire five people from every country on earth and relocate them all to London so that you would build the world’s most diverse team, the truth of the matter is after six months they would all be Londoners: they have a London cell phone number, they have local currency, they have to abide by local holidays, they use local transit, they speak the local language…
So yeah, they may maintain some of their authentic cultures but they’ll adapt, and they’ll kind of merge into what the culture is around them because that’s the place that they now live in. That’s kind of manufacturing diversity. Whereas, if you hire people from wherever they are in the world and you let them stay there, they’re going to bring that authentic culture to work and you truly get a diverse array of perspectives when it comes to evaluating releases, or evaluating code, or evaluating products, or evaluating marketing messaging. It’s phenomenal the input that you can get when you let people stay where they are. I don’t think that’s easily replicable by just hiring someone from one country and then relocating them to a headquarters somewhere else.
It’s worth the journey to remote if you want to expand what is possible with your team, with your diversity, and with your recruiting pipeline.
Sergio: That is great and I would love to end this awesome conversation with a practical question, which I’m pretty sure that you have been asked a lot recently, but I’m asking it anyway. What would be your first piece of advice for a company trying to embrace remote for the first time? Where should they focus on to enable a remote culture in a sustainable way?
Darren: It’s a great question. I’ve written three guides in particular that I think will help companies, so you can [check out] GitLab’s transition guide, GitLab’s what not to do guide, and GitLab’s forcing functions for remote first guide. I think the Forcing Functions one is really important. I would start by getting the executives out of the office. And the reason I recommend this is, there’s really no silver bullet to get on a good path to transition that I could say would work effectively for any company of any size.
Every company is different. Every company has a certain maturity with tools and culture. But I can guarantee you that if you get all of your executives out of the office, and have someone document the communication voids and communication issues that pop up with information, either flowing to the top or flowing back down, you’ll quickly prioritize what needs to be fixed. You’ll figure out really quickly what worked in an office setting and what needs to be filled for it to continue to work remotely.
And as long as you keep your executives in the office, you can kind of band-aid it enough to make it work, but it’s not an ideal situation for anyone. So, the easiest way to get the clearest answer on that is to get the executives out for a meaningful amount of time. I would recommend a quarter. If you can’t stomach that, do it for at least a month, and then just start working it out.
It’s not like remote is a light switch that you flip — like one day you’re co-located in, one day your remote. It’s a process. It’s a journey. And so, of course, day one might be a little rocky. There’s going to be some communication gaps and it’s really on leadership to just admit to the company ‘hey, this is a journey. There will be some bumps in the road, but we believe that the long-term benefits and efficiencies of doing this are worth it.’ If you’re honest with people and you empower them to help change that and help the process, I think teams would appreciate that and respect it. It’s worth the journey to remote if you want to expand what is possible with your team, with your diversity, and with your recruiting pipeline.
Sergio: That sounds great. Darren, it’s been great having you. I wanted to thank you for this conversation, and also, for all the work you and GitLab are doing to evangelize remote.
Darren: Thanks so much for having me! And if anybody listening has any contributions, [check out] our GitLab remote handbook. If you find a page of interest feel free to make a Merge Request, a contribution, and assign it to me. I’d be happy to take a look at it.
Sergio: Cool, amazing! Thank you so much. This is Working Without Borders, I’m Sergio Nouvel. Thank you for listening. See you in the next episode.
************************
Check out all Working Without Borders episodes here.
Latest on Blog
