Levels CEO Sam Corcos talks to Murph, The Head of Remote at GitLab, about creating his company’s famous handbook, how to bring together virtual teams, and why you should always state the obvious.
Darren Murph has been called an “oracle of remote work.” He is the author of GitLab’s Remote Playbook and Living the Remote Dream: A Guide to Seeing the World, Setting Records, and Advancing Your Career. He talked to Levels CEO Sam Corcos on our podcast, A Whole New Level recently. This is an edited version of that conversation.
Sam Corcos: You are among the OGs of remote work. If you were starting fresh as a remote company, what would be some of the things that you would do differently than the way that GitLab has evolved in its current incarnation?
Darren Murph: If I were starting fresh, I would build a durable and resilient documentation infrastructure that was as forward-looking as possible and as agile and amenable to new tools coming in, but the thought process, the mental model of it would be fundamentally sound. And part B to that is dialing in your values and how to live those values in a distributed setting, coupled with a mechanism for evolving them easily over time.
There will be values that are fairly obvious at this stage in the company, things like collaboration, we want people to collaborate. And then you can create sub-values of, well, what does collaboration look like? Maybe we explicitly want people to collaborate with no ego. Maybe we say short toes. Anyone has permission to contribute to anyone else’s function in terms of a proposal or an idea and people cannot react as if they’re having their toes stepped on, things like this.
Sam Corcos: I think in our culture handbook, we have direct quotes from the GitLab handbook.
“Short toes” is one of the cultural things that we just directly stole.
Darren Murph: It’s so good. But you can’t possibly know all of the things that will come at scale. The trick here is not trying to focus on finalizing your values at this company stage. The trick is how do we build the infrastructure so that as we evolve, we can add and remove. There’s a process for adding and removing these sub-values because as you add new team members, they will bring new ideas and some values, they’ll need to be modified or potentially removed or merged.
The reason why I put so much focus on this is because company culture is the barometer of how well values are adhered to and reinforced. The only way to scale culture in a remote setting — especially a large remote setting — is to get the values part of it right. The values are the foundational bedrock on which everything else is built. And interestingly, in a remote setting, the values are also operations.
If you were to have a chief operations officer, that would be their primary metric is to make sure the values are up to date, which if you said that in a co-located setting, it would make almost no sense. But in a remote setting, operations are explicitly how you tell people to work together, they are the explicit workflows, how do you get things done, how do we minimize variants on how someone approaches a support ticket, for example. This becomes the operations and all of it goes back to these values, what is documented. So that’s a long-winded part one to that.
On building a company handbook that never gets stale…
Darren Murph: Looping back to that intentional strategy of building an infrastructure where things can be written down, I would continually audit and pressure test what in our organization is implicit or implied. What are people learning via osmosis, because they’re in a working group or a project group and they’re around people enough to see how things happen? What of that is being picked up only because they are in digital or physical proximity to this team and not because they read it and internalized it?
As you scale, that becomes a greater and greater risk. Anything which is implied or implicit will not scale because as the team grows, you can’t invite everyone to every project group. People start getting different incarnations of what collaboration looks like depending on which project group they’re in and you want to avoid that. The continual process of what’s implicit, let’s write it down and make it explicit, should be a very common, normalized thing. And that’s how you build a great handbook. That’s how you build a great company manual that never gets stale, because as you scale, as you grow, there will always be new things that are being passed along and learned by implied knowledge and that’s a continual opportunity to write something down, make it explicit so that your onboarding continually gets better.
On the need for reboarding…
Darren Murph: From an early stage, I would proactively create a reboarding process. Companies are very good about building onboarding processes. They look out for people who join the team brand new, but in a hyper-growth startup, what ends up happening is you’ll look up one day, realize you’re 10 years old, you’re many hundreds, if not thousands of people and your values and your operational principles have evolved so rapidly, you’ve pulled people in from such different circumstances and everybody brings a certain level of organizational baggage and preconceived notions that you need this process of reboarding. It’s the assumption that every year you’re joining a new company, almost going so far as sending a new email at the beginning of every year, that says, “Rewelcome to Levels.”
You really want to be explicit on, we’re serious about this, this is a new company. And you want to continually make that a part of the culture, because if you look at GitLab’s biggest risks page, there’s a couple of them that talk to this. One is losing the values that bind us. And people that join in different cohorts, seasons, or stages of the company tend to have different understandings of what the values mean and how they are lived because they can be lived differently depending on the size of the team and the expectations. If you normalize from the start that when you join Levels, we’re going to set this understanding that every year you’re going to rejoin Levels, we invite you to rejoin the company every year with us and it’s on us as a leadership team to make sure that you understand what Levels 2023 is, Levels 2024 is.
There’s an amazing book called Workquake by Steve Cadigan. He was LinkedIn’s first ever chief HR officer. And he offers up this somewhat radical idea that instead of exit interviews, companies at a very early stage should focus on stay interviews. And at a certain cadence, you offer up every employee, the ability to have an interview on why would you stay, what could we, as an organization do to help you stay?
And people don’t often correlate this with remote, but I think remote companies in particular have an amazing opportunity to get this right in a way that co-located companies don’t. And the reason for that is you could potentially keep someone at your place of employment forever, their entire career, even if they change homes or locales every week. That’s not possible in a co-located setting, so it’s less justifiable to put the effort in. But there’s something about building a culture where you reonboard people every year and you invite them to do stay interviews. This is how leadership can continue to keep pace with what is alluring just outside of frame, what do we not know, what can we build into our company to make us more durable and more resilient?
Sam Corcos: Yeah, it’s so funny. The concept of reboarding, I can send you a message that I sent to Miz two weeks ago where we proposed the idea of kicking that off.
Darren Murph: I think there’s something to it. I really do. It helps reframe that things will change. In a hyper-growth startup things will change and it’s a feature, not a bug. But you have to be overt and explicit about it because if people have this expectation that it’s a bug, not a feature, it will create chaos and dysfunction. And it tends to exacerbate itself in a remote setting, more so than in a co-located setting.
On effectively running a fully remote team…
Sam Corcos: It’s interesting when you’re talking about how values are the operations in a remote team. Levels is the first really fully remote organization that I’ve certainly been in leadership on, but it’s not a coincidence that the person who is leading a lot of our values pushes is our head of operations and we’re starting to see how intertwined those concepts are. It’s not entirely crystallized to me yet on why that’s the case on remote.
I think maybe this ties into one of our cultural values, which is to treat people like adults. And when you’re remote, even if you wanted to, you can’t really look over people’s shoulders and see how they’re spending their time. You really have to trust that people are able to operate effectively. And so having that cultural and values alignment seems like it’s even more important when you’re fully remote. Is that a fair statement?
Darren Murph: I would agree with that. You’ll find a million definitions of culture, but I think there’s something durable about the way GitLab looks at it as an all-remote team. It is comprised of two fundamental things and both have to be right. One is how we work and the other is how we build comradery. And it’s impossible to know how you work in a remote setting, unless you write down how you work. Going all the way to the basics, you have to make it explicit because people cannot learn as easily through osmosis.
I think if you translated it differently, it could also be how you treat people. At the end of the day, isn’t work dealing with people? It’s how you respond to customer request, how you respond to client request, how you respond to team request. That’s really all work is, is a back-and-forth relational exchange of how you interface and operate with each other. That’s why you have to write it down. And if the values are very aligned with that, it removes this misalignment of well, I value one thing, but I feel like I need to work with this person in a different way.
Remote companies are in a great position to take advantage of crystallizing and articulating that. But also, the flip side of that is the risk of not doing that. It’s going to be more pronounced in a remote setting because the office is not there to serve as this cultural Band-Aid, if you will. It really has to be written down.
If you do this right, remote companies become highly efficient machines. That would be okay if we were all robots, but we’re not, we’re humans. And so, optimizing purely for machine level operations will only get you so far before you have to intentionally make sure there are some comradery moments, some rapport and culture building moments built in, because that’s where the innovation comes from.
A lot of people will say, “Where does innovation come from in a remote setting?” If you are explicit about how you work and how you treat other people that covers the efficiency part on the productivity. The innovation comes from feeling like you can trust another human being to really be vulnerable with them. You have to be intentional about setting opportunities up, whether that’s in person or virtual.
On creating trust within a team…
Sam Corcos: It seems like you have to be much more intentional about trust building than you do in a co-located team, because it’s pretty easy to not interact with somebody at all for months at a time. I did a podcast with Vinay Hiremath from Loom about this. We talked about the role of video and seeing people face to face. And I’m starting to develop this theory that written communication is almost inherently trust depleting. Seeing somebody else in person or through audio of video seems to have the exact opposite effect that increases trust in a way that you can’t really get in written form. Is that a fair statement?
Darren Murph: I think there’s something to that. It’s a great opportunity at your stage to document how you’ll use various tools in the toolbox to get a job done, and of course, being willing to iterate with that over time. I’ll start with a more tactical work process, synchronous and asynchronous. Many people look at these as versus, synchronous versus asynchronous. That’s not the case. They’re two very powerful tools. If you have guardrails on when to use each you don’t have to think about it, stew about it and leave it up to someone’s own devices. It’s like having a wrench and a screwdriver. If you’re on a job site, it’s very useful to have both of those, but you need to know when to use them.
Interestingly, text and video, I think are similarly two tools in a toolbox that it would be wise if you’re starting this early, to be more explicit about when to use which and the benefits of why. A lot of companies essentially allow people to communicate through a medium that works best for them. On the surface this seems incredibly inclusive and liberating, and I would agree with that. But as you scale — to your point — people may begin to default to more soulless modes of communication, or they struggle to communicate empathy and humanness through text. Formalizing as a company that a video tool like Loom is great for things like this gives them a heads up.
For example, if you had a manager who said, “I feel like I’m losing some connective tissue with my team. We’re doing well productively, but I just don’t feel that same connective tissue,” it would be nice to have something documented that, hey, we think video in place of text in this could be a great A/B test. Replace your mode of communication with this tool versus this tool for a week, do a mini retrospective and see if it’s any better.
On the “awkward teenager” phase of remote work…
Darren Murph: The reason why I go all the way back to setting up this foundation where things can change is we are at this incredibly interesting point, I call it the awkward teenager phase of remote work. By and large remote teams are using tools that were built for office first settings to run their virtual organizations. And great remote teams are very crafty about how they use them, for example, GitLab deletes all of our Slack messages after 90 days to force people to work in GitLab, the platform. Also, it opens Slack up to be more of a conversational tool, people talk about hiking and parenting and cooking because they don’t talk about work in there. So that’s what it becomes useful for. But that’s not a marketed feature of Slack, we just got crafty enough using an office first tool to make it awesome for virtual.
In the years ahead, I think you’ll see tools emerge that were built for distributed first because now there’s product market fit for them. Similarly, you will see some tools, and Slack’s a great example, that will reinvent themselves to try to become more digital-friendly. You’re going to have to continually be adaptable and agile because new tools will come in to solve some of these problems that we’re currently trying to solve with office-first tools in a virtual world and we’re happy to do a lot of mental gymnastics to get there.
Sam Corcos: I listened to an older podcast within the last couple years with Matt Mullenweg talking about how in many ways we’re in the same stage where radio was in the early 1900s, where they first figured out what radio is and they basically just took theater plays and just read them out loud on the radio. And they didn’t really know how to take advantage of the medium itself and it wasn’t really that great. But eventually they figured out that, oh, there’s actually a lot of potential here and we can lean into what is enabled by radio.
Darren Murph: The interesting part about this is you’re scaling a team where it’s also new to most of them, all of this is being invented in real time. There’s this additional burden on leadership in a remote team that if you infuse a new tool or an old tool with a new way of using it, you have this added burden of learning and development and upskilling people on how it’s used. I call this process unlearning.
Sam Corcos: We call it deprogramming.
Darren Murph: It’s a great way to look at it. That goes back to this concept of reboarding. Change is going to happen so fast that it’s not enough to just deprogram or unlearn at your new hire orientation because things are going to change so rapidly that you’re going to need to re-deprogram even the way that you used to be using things. I’ll give you a tangible example of how I think this is going to happen at GitLab.
Right now, every work-related invite has to have a shared doc agenda on it. Otherwise people will just decline the meeting. We temporarily take notes in the meeting using this doc. Some people actually use Otter and Quora, but it mostly just spits out this raw transcription, which then there’s still a human element of codifying and taxonofying what actually needs to be reported to the company handbook and where.
I see a time where these tools get smart enough that they can listen to the voices, they know who is saying what, and they can actually start pulling out bullet points and takeaways. And at the end of the call, it just looks at a API hook into our handbook. If we were talking about expense reports, it goes and finds the finance page, it finds what I said was new, it makes a merge request to change what that was, and it assigns that merge request to the person who was verbalizing. In this case, it would be me. So, it’s going to cut out an entire layer of manual process.
When this happens, we will need to reboard everyone, because the GitLab way has now been evolved by technology taking a leap forward. I think things like this, it’s going to usher in a sea change for people operations. Never in our lifetimes have we seen behavior change need to happen at such a rapid rate and it’s going to feel very disorienting and very chaotic, if you don’t set the stage early that this is a feature, not a bug.
On the value of forcing functions…
Sam Corcos: One the things that we do related to learning new tools is we take a lot of effort into onboarding. I think the current onboarding is a month and we say no deliverables for a month and really take onboarding seriously. I think it’s extra important on remote teams to do onboarding effectively. On week three of onboarding, we only allow people to communicate via asynchronous video or audio notes and it’s really awkward. And there are definitely times where it doesn’t make sense to do that, but you bump up against those edge cases because people are not used to that as a medium. So, forcing people to get comfortable with that has been a really useful exercise.
Darren Murph: This invites me to talk about forcing functions. I actually think it’s smart for early-stage companies to have a dedicated section in their handbook for here are the forcing functions that we’re actively using. And you want to make that public because then you can point to the page instead of it feeling awkward, you can say, “No, confirmed, we’re doing this for a reason. It feels awkward because it is awkward.”
I’ll give you a great example that we’ve seen success with at GitLab. We call these async weeks. We piloted this all through 2021, so we’ve had a full year of them under our belt. Every six weeks, we block it out in our calendar that this is an async week and you can set up your calendar such that it auto responds to an incoming invite that says this is an async week, so it will reject it. But if you want to still have this meeting and use an asynchronous form of communication to do it, you’re welcome to re-add it, but put async in the title. That way it’s less cold. You don’t want people just pushing off or pulling forward synchronous meetings, that defeats the point. You want to challenge the behavior and invite behavior change.
We did these every six weeks, which I felt was enough of an amount of time to create behavior change, but it’s not so frequent that it’s catastrophic, if it isn’t ideal for everything. But here’s the other thing that we learned in our retrospective on what did we learn from async weeks at the end of the year: We learned that it served as an amazing accountability partner. We even did our one-on-ones async.
We have our shared doc, and we knew that if on async week, we were going to have to tag each other back and forth on ongoing projects to move them forward, we better be great at being rigorous about that documentation in that one-on-one doc for the five weeks in between. Otherwise, you would get to that sixth week and you would be so overwhelmed with trying to remember what happened in the past five weeks. It’s almost like this accountability partner. That’s the best term I can come up with. It made us better about documenting even in times where we probably could have gotten away without it, because we knew that on that sixth week, it would be the only way to move work forward. So that was an interesting one.
On creating culture and building trust and community…
Darren Murph: I think a prediction for remote teams going forward is that culture will largely be built outside of the workplace. It will not be built from within. And this is an interesting concept, quite the paradox where there’s very little you can do and orchestrate that will foster culture when everyone can glance out their window and see freedom right there, you don’t have them captive in an office.
So the example I try to give people who struggle with this paradox is the Zoom happy hour. It goes like this, if you have a thousand people on your team and you’re going to get all of them together for an hour on a Friday, you’ve already committed a thousand work hours to it. It’s a sunk cost, you’re doing it either way. I would say that instead of doing that, a higher ROI use of that time is to deploy those thousand people into their communities for that same hour, or do it any hour during the week, because time is relative, depending on time zone.
The only thing you ask is everyone wear company swag and whatever you do for that hour, you take a selfie of yourself. So whether that’s volunteering at a food bank, reading at a local library, just chatting with your neighbor, whatever it is, whatever moves the world forward for an hour, wear company swag, take a selfie. Now, what you’ve done is you’ve created a thousand pieces of content, a thousand authentic, genuine moments of who these people actually are with that same amount of time.
Then in your next all hands or forum, you invite people who are comfortable with it to share. What you’re doing is you’re folding the real lives, the real culture of people into the workplace and it will build trust at an accelerated pace that a Zoom happy hour could never do. The question becomes, what else can we be intentional about like that, that creates a psychologically safe atmosphere where people bring the culture to work?
You look at a forum or a platform like Twitter, Twitter doesn’t create the content. They created the medium and the mechanism for people to bring the content and that’s what makes it useful. Companies are going to have to think about their culture very similarly, how do we create the platform for our own people to bring their culture to work? It’s very much a paradox, but I think it’s going to be a huge opportunity for remote teams. Co-located teams won’t have the same flexibility to do that.
Sam Corcos: I’ll say something potentially controversial. When we were starting to put together more of our culture, which is something that started to really crystallize after about a year, we started to realize what things were important to us, we started with GitBook, and it started to look a lot like the GitLab handbook. What we realized is that having a written handbook did not actually serve the purposes that we wanted it to. Some of the procedural stuff was really important to be written down, like here are the steps to take to get reimbursed for something.
You need that procedural stuff written down. But things like, how do we do vacations? We would write it down and people would immediately say, “Cool, thanks for the written document, but how do people actually do vacations?” And the concept that Mike Haney, our editorial director mentioned is that people model what they see around them. And in a co-located team, you literally look around you and you see what other people do, and then you model that behavior. It doesn’t really matter what’s written in many ways. I’ve been thinking a lot more about this. You have a very, very long written body of work, as far as the culture handbook goes. How do you think about that as a concept?
Darren Murph: I love that, and it goes back to your first question on what would you do differently. We now have the ability to show in more ways than we did 10 years ago. I always think of things in the boring solution. Like, what’s the boring solution? It could be as simple as you ask people when they go on vacation, take a clip, take a photo, take a memento and then create the mechanism to share that back. We haven’t done it with vacations, but we have done it with something else.
When the pandemic first hit, we noticed that people were working more hours and taking less time off and we saw that as a red flag to burn out if we didn’t address it, so we invented family and friends day. Family and Friends First is one of our sub-values, so we named a day after it. It wound up being a Friday off a month where the whole virtual company shuts down. But the real kicker of how this influenced culture — and to your point on seeing — we started a dedicated family and friend Slack channel.
And what we asked is that when people shut off for the day, take a photo, take a video, micro video, doesn’t have to be long, a story, something, that captures what you’re doing on that day that isn’t work. Then please share it in this public Slack channel, because we wanted people to see other people not working, to reinforce the idea that you should not be working on this day. Over time, it has grown into something that’s beautiful to the point where people now actively look forward to Family and Friends Day, less for the break and more for the glimpse into other people’s lives because we work so diligently that weeks can go by without you sharing anything personal.
Family and friends channel has become this amazing glimpse and like, oh, wow, I saw someone go to the mountains, I should consider going to the mountains. I’ll give you one anecdote that I think someone won Family and Friends Day forever when they posted a Google photos gallery of their marriage. Someone actually got married on Family and Friends Day and that’s pretty remarkable.
The boring solution could be like, have a vacations channel where you normalize [time off]. We disallow all email and Slack while you’re on vacation, except to post in this one channel. If you just have that itch where you’re like, “I have to send something work related,” the only channel that is active for you is this vacation channel. To some degree this reverse normalizes what usually happens, which is people are a bit afraid to take vacation — or worse, they’re afraid to share photos about it because they might feel guilty about how amazing it was. That shouldn’t be the case. We get a lot of positive energy by seeing our colleagues enjoy life. We only get one shot at this thing.
I think you could probably go deeper with that. There’s probably so much more you could do with inviting people to capture and share back. I always think about where is the abundance or the opportunity in remote that wouldn’t exist in a co-located space. If you do it right, you could actually expose more vacations to more people than you ever would in an office.
Because even in an office, like if you worked on the seventh floor in New York and someone took vacation in Sydney who worked on the third floor, unfortunately they would never see the other person’s vacation. If you do it right, remote has the ability to flatten that and make it more visible.
Sam Corcos: That’s very close to something that we do. We did a lightning talk. We do a quarterly assemblage, which is the closest we’ll probably get to an all company event. We do it all virtually. We can go on a tangent later about why we’ve decided not to do all company events, but one of the lightning talks was on how one of our engineers who took a three week vacation to do a cross country road trip. And really just showing that this is totally normal and acceptable and you can do this whenever you want. So it’s definitely something we’re trying to lean into more.
Darren Murph: For what it’s worth, I know of a transitioning company — a company that was fully co-located and they’ve made a deliberate decision to go remote first — what they realized is that although they were providing stipends for people to build out their home office, a significant population was not using it. It was money left on the table. People started prodding and asking why. We’ve reinforced that this money is available, we’ve documented how to use it, why are you not using it? And the answer was, I don’t know how to design a workspace. I don’t know what a good workspace looks like. I don’t know how to spend the money. I just stare at an Amazon page with no idea how to use it.
What they did is they opened up this forum where people who were great at it. There was one person who completely ripped out their closet and put sound isolating boards in there. They actually put this amazing collapsible office in the closet.
It was just phenomenal use of a very small space in an apartment. And they did a mini tour of it. They took a couple of photos. They did a quick video — I think it was about two minutes. And they published that in as many forums as they could, like the company email letter and Slack. They also documented it in the handbook. They created it once and distributed it forever, they just blasted it out. There was an immediate uptick of people using that money and an immediate uptick of people conversing about this type of thing, simply because they were shown one example.
So, is a long running handbook page with a million examples of workspaces the most elegant way to do that? Maybe not, but getting that first one out there was certainly a boring solution that helped foster that inspiration and innovation.
Sam Corcos: Yes, something that we have found is that content solves a lot of problems.
Darren Murph: That is a great, great line.
Sam Corcos: You sort of accidentally generate a lot of content when you’re remote, whether you realize it or not. All of the meetings in our company are recorded by a default. That doesn’t mean we necessarily distribute them, but they’re all there. And it is very common for a conversation to just happen spontaneously and then at some point somebody realized, we should totally share this with the marketing team. And then you don’t need to have that conversation over again, you just share the clip and it just saves everyone a ton of time.
On the value of stating the obvious…
Darren Murph: Even for things that are procedural, it’s great to show people what it’s like. If there’s a promotion doc where you need to keep track of projects that you’ve assembled, same kind of deal where if you only think about it at promotion time, you’re like, “Ah, I’ve got a lot of things to think back on,” well, what does that look like to do it on a week-by-week basis? A quick screen share of a Notion doc with accomplishments could be an amazing eye opener for someone who has never thought about it. I like this phrase that obvious things are only obvious to whom they are obvious.
On a remote team it is very easy to get in your own little box and assume that everyone knows everything, that they’ve seen the same things that you’ve seen because we all work in the same office, the office being the internet. But the internet’s a big place, the office is a big place and you can’t assume that people have seen it all.
Sam Corcos: We’re starting to publish a productivity series. It’s really for internal uses, but we’re also publishing it externally. And these are things like how to use a Mac, this is how gestures work, this is how multiple desktops work, all of these things that if you’ve known about them for years, you just assume everyone knows how to do these things. But we’re starting from no assumptions, and this is part of onboarding. Some people can breeze through it, but yeah.
Darren Murph: Our learning and development team is soon shipping the same type of thing for how to use Slack. On paper you would think, wait a minute, 1,500 people at a hyper-growth SaaS company, surely they know how to use Slack, but that’s not the point. You can’t assume that, number one. We’re hiring people that use Teams or other things or have used nothing at all in the past. But number two, it’s how do you Slack at GitLab? And number three, it’s how do you Slack at GitLab currently? This goes back to that reboarding, where it’s worth showing and then continually thinking about what do we need to reshow.
It’s a lot of work. There’s a ton of intentionality, but I tell people that you’re going to put the work in either way. You’re either going to put the work in fixing all the things you didn’t show people, or you’re going to put the work in showing people. I think the latter is more efficient.
Sam Corcos: I think the best way to show people how to use Slack is to remove Slack from your organization, but that’s a longer conversation.
Darren Murph: These are forcing functions that companies definitely have such an amazing ability to choose now where you can select tools based on what it inspires in your organization. The team over at Doist have companies that they market as implementable. If you want people to reduce their reliance on synchronicity because they have specifically designed even UX elements to send off signals in your brain that incentivize asynchronous communication instead of the opposite. The UX elements incentivize continue to pull to refresh, continue to use it. This will become more and more nuanced and it will matter more and more as more teams go remote.
On closed versus open silo information…
Sam Corcos: I think that’s right. It actually ties into one of the other notes that I had here. We’re 40 people and we’re already starting to run into the problem of context collapse and information overload. One of our — call it a communication value — is around open silos versus closed silos. Information necessarily will be siloed because you can’t expect everybody to have all of the information, so it’ll necessarily silo to within organizations. But an email is an example of a closed silo. If you and I are on the email thread, nobody else can ever access that. Open silo is, at least it’s discoverable and if you wanted to see what the other group is doing, you can.
We’re already getting to the point at 40 people where there’s just too much information and people have been talking internally about switching back to something that’s closed silos and only looping people in when they need access, because it’s already getting out of control. You’re massively larger than we are, so I imagine this problem is exponentially harder. What’s the right approach here?
Darren Murph: If I were doing it all again, I would make sure that two fundamental things were in place. One is that you put all of your focus on teaching people how to search. When we onboard people at GitLab, we recognize that they will never read the entire 2,000 (and growing)- page handbook. Instead, we say, you have to meticulously read this guide on searching the GitLab handbook like a pro. It’s public, so anybody can Google that. Because the purpose here is we want to teach people to default to self-service, default to looking, default to assuming that the answer to their question exists and then teach them how to find it and where to look.
Only if they don’t find it, do you go to the DRI. Like if it’s a finance question and you didn’t find the answer, then you go to the finance DRI. You get the answer to that question, and then there’s a process for documenting it, such that when anyone has this question hence forth, it’s answered for them. We call it, paying it forward. So that’s one, focus on searching.
The line I like to use here is if someone asked you, is there too much information on the internet, you would instinctively say, “Of course not, I know how to use Google.” But the truth is there is too much information on the internet for any one of us to ever comprehend it and the same will be true in your workplace. But that’s the wrong question. The right question is, have you taught me how to search what I need to find, when I need to find it in the correct medium?
The second part of that is as a company scales and grows, more information will become accidentally siloed, not even ill intentioned, just there’s a lot going on, so it may become siloed by accident. Instead of worrying about that, put the focus on, we will always have our goals and our objectives, OKRs — whatever you use — they will always be public to every function in the company, always.
Why that’s important is that even as a company scales and a company grows and the amount of information becomes vast, if you can look at the legal team’s objectives and key results, if you can look at the finance team’s objectives and key results, you can look at that and think, does my work connect to that? Do I understand how what I’m doing ladders up to that? Do I see something here that feels duplicative or off? And that’s where these conversations can begin, because fundamentally, if you can at least convey shared goals and objectives, you can create a sense of belonging that invites follow-ups or invites access requests, or invites questions for more information that come from a place of genuine interest in learning — instead of a place of why didn’t I know this.
That’s the best advice I have because you will produce too much information for anyone to ever read. And at the end of the day, it all comes back to results. What are the objectives for the teams? Under no circumstance, should they be opaque. If you can make those transparent, I think you invite positive conversation on creatively unlocking more transparency as needed.
Sam Corcos: Right. That’s really helpful. Yeah, I feel like I’m going to have to write a document on that.
Darren Murph: It is. And you’ll find that at GitLab. GitLab’s handbook is public, so we’re unique, but you can search for all of our OKRs and you can see across the company what matters to each department. And reading all of those takes no more than an hour. That’s a highly efficient use of an hour. Just go through all the functions in the organization. And you could use the forum as an example of reinforcing that, hey, every quarter or biannually, here are the things you need to know. And transparency on those very, very foundational results-driving type of principles is a great place to start.
On if it’s possible to overvalue collaboration…
Sam Corcos: One of the other things that I wanted to touch on — and you invited this earlier — that one of your values is on collaboration. And I’ll say something also controversial that’s not necessarily what I believe. But I think that collaboration is often overvalued as a concept. I think that when I look at a lot of the best work that has been produced within our organization, it’s usually one very capable person going as deep as they can, maybe taking an entire month. I’m thinking of one document in particular, one strategy, one person spent four months working on it exclusively and went as deep as they could and looped in people when they had questions or when they needed input, but it was really one person taking lead.
The work products that were the least successful were ones that were collaborative from the beginning. It was, let’s get everyone in a room — or in this case, a virtual room — and let’s get everyone’s ideas, let’s have lots of meetings, let’s talk about it and then start delivering the work product. And it usually ended up being a milk toast version of what output we were actually looking for.
Andrew on our team, he defines these two [differences] as hero work versus collective work. And we seem to be very good at hero work and I don’t think we have very many examples of collective work being done effectively. I don’t know if that’s just the type of people we have on the team, whether that’s something that’s intrinsic to remote work, or whether collective work is actually not as good as people think it is and it just makes people feel good to just talk to other people. I don’t know. What are your thoughts on that?
Darren Murph: I love this conversation. I would start by not conflating quantity of people working on something with collaboration. The juxtaposition I would give you is in your first example, where someone worked exclusively on something for four months and delivered a great result, I actually think that is a phenomenal example of collaboration. And here’s why, they collaborated with the system. What that tells me is that you had enough foundational operational underpinning set up. They knew what tools to use. They know where to find the information. They had psychological safety to seek outside guidance. That was self-collaborating to deliver an amazing result. They collaborated with the system.
Also, what I heard was people who were aware of this person doing this project respected the boundaries. That is a form of collaboration. You are collaborating with me by not getting in my way. To me, that feels like collaboration. You are explicitly and deliberately not interfering with this person. That is an expression of collaboration because the opposite of that would be, I’m going to commandeer your time, even though I know you’re working on this. That is anti-collaboration, that is thwarting results. I actually do think that collaboration happened. The hero versus collective or the single player versus multiplayer, I think that’s the more interesting conversation to have. I think collaboration can happen in single player type of work.
On the collective front, what I would offer there is to make sure that results are the key value. What this will force is that if people are spinning their wheels, being inefficient, or spending too much time on things that don’t matter — maybe for the sake of feeling good — they’re trying to refill their social reservoir. Then just call it what it is.
Set up an optional meeting and say, “For the first 20 minutes of this meeting, I feel socially depleted. The objective, the result for the first 20 minutes of this meeting is to refill my social reservoir, to not get any work done, just to refill the social reservoir and to be more explicit about what that looks like.” But if it’s results driven, the medium starts to matter a lot less. These brainstorms or these synchronous moments themselves are not valuable, they’re only valuable to the degree at which it gets us to the result more expeditiously.
Sam Corcos: I’ve always wondered about these things and you’re much further along on this path than we are. Have you seen significant net benefit from things like brainstorming sessions that are live, or jam sessions? Jam sessions is a common thing that people lionize as this bastion of creativity and I just historically have seen very little value come out of them at any company I’ve ever worked for. How do you think about those?
Darren Murph: I used to agree with that and what I have seen in talking with hundreds or thousands of companies and looking at their organizational behaviors is that it’s not a one-size-fits-all solution. In other words, if you get the right kind of people together in these live, quote-unquote, “jam sessions …” I love the 16 Personalities tool. There’s a section of these 16 personalities that if you get them in that environment, they will create incredible innovation. There’s another section of those people that if you put them in that room, almost nothing of value will happen. But if you put a blank mural board in front of that same group, the most amazing innovation you’ve ever seen will happen, probably asynchronously in drips and drabs over the course of a week. It’s two fundamentally different ways of getting to a solution.
This is where I go back to remote providing an opportunity. In a co-located setting, option one, getting everybody together live for the jam session was basically the only option. If you didn’t jibe with that, you were perpetually disadvantaged. But now in a remote setting, you have the ability to offer both. You just have to be very vocal and explicit that this as an either option. It won’t be ideal for everyone, but it’s okay if it’s ideal for you.
This goes back to this synchronous versus asynchronous. I don’t want to demonize one or the other. There’s this delicate balance of offering both as long as the output is in an inclusive medium. If you want to jam live on a whiteboard that has no connection to the internet, totally fine as long as the output is in an easily shareable, easily digestible way. The output must be inclusive, and then the way you get there can be different. That is challenging. It’s challenging because you could end up with a big project group where some people prefer one way and some people prefer another.
The only solution I’ve seen to that thus far is to do both. You say, “Every other week — or however long this working group is going to be — we’re going to do it this way once and then we’re going to do the mural board once and then see how it works.” And hopefully you’ll see sparks of innovation come from a certain subset in one medium, and then a certain one on the other, and you merge them together. Again, this sounds like more work, but it is certainly better than only offering one way and then completely excluding a certain innovative group from that process.
On documenting it all…
Sam Corcos: That’s helpful. One of the other things you touched on at the very beginning of the conversation is you said that you’d think about how to have a more resilient documentation structure. I’m curious what you mean by that in terms of tactical implementation.
Darren Murph: Make it as portable as possible — and you see this in legacy enterprise organizations. Organizations that choose a service without thinking that things will ever change end up in this terrible scenario, where they’ve scaled to many thousands of people and it’s just too hard to implement a new tool. You go all the way back to decades ago in the recruiting function, you’d have organizations still asking people to fax their resumes in because it was just too hard to move to a Greenhouse or something like that.
What I’ve learned in that is always assume that technology is going to disrupt whatever you’re building now. And if your entire operations are documented, that is the highest possible risk. Guard that with your life. Whatever you’re doing now to build this documentation, always have a get out plan, always have a portability plan. And always have a plan that if new ways of doing it come along, you don’t want to have this scenario where you have to have this month-long process of the pain of ripping this out or [questions of] can we afford to do this? Build it as resilient as you can with the assumption that it will change instead of the assumption that it will always stay that way.
On mentoring and bonding remotely…
Sam Corcos: The last topic I really want to talk about is one that we’ve been discussing internally. Our team is quite senior and part of that is because I’m incredibly lazy and I prefer working with people who I don’t have to manage, but it also seems like remote is much more friendly to people who already have excellent time management skills and who don’t need the daily social interaction with colleagues.
People at Levels really do interact quite a lot. They get along with each other. We have very productive working relationships, but it tends not to lead to the development of a new group of best friends. Like Josh, my co-founder who was at SpaceX, a lot of his closest friends are people that he worked with at SpaceX and they spent every weekend together. All of their social occasions were really built around that core work group.
We’ve been trying to think a little bit more about is this necessarily the case in remote teams that don’t have that same dynamic. How do more junior people, how does mentoring, how does that sort of thing fit into the umbrella of remote work?
Darren Murph: The opportunity is that you can design the system to improve on it. Let me give you the example that existed before remote teams at scale. If you had an office building in San Francisco, that type of work was more amenable to extroverts. You were talking about how junior people don’t have as fair of a shot in remote. Well, in that case, introverts were highly disadvantaged. Those with mobility challenges were highly disadvantaged. And another thing that’s not talked about as much in terms of geographic diversity, if you grew up in a very rural place, and then you had to uproot everything you knew and move to a city like San Francisco, just the commute to and from wherever you were going was far more traumatic and chaotic mentally than for someone who grew up in that environment.
Sam Corcos: That’s a good point.
Darren Murph: Now, we didn’t talk about these disadvantages, but they existed. So remote has its own set of built-in inefficiencies or built-in hindrances-
Sam Corcos: Trade-offs?
Darren Murph: Correct. Trade-offs is a great word for that. But the beauty is unlike a building that will never move, remote gives you much more opportunity to vocalize and give voice to those limitations and then work around them and create systems that work around them. I’ll offer you one tangible example.
I’ve seen companies embrace this idea of onboarding cohorts or in person onboarding. And essentially, they create a budget where they get people, let’s say, if you join in Q1, everybody gets together in Q2 and they go to this place. If you don’t have any real estate, you just choose a place on the map. Make it a survey, make it interactive. And you get people together to really build this rapport foundation, these basic principles of how we work here. And then that catalyzes a lot of great asynchronous work.
On the mentorship front, it requires so much more intentionality. In a co-located space, you could invite a new hire or an intern to just shadow you, just walk around and watch how you work. You actually can do that virtually. You just invite this person to all of the Zoom meetings and you just make it a formalized shadow experience. And at the end of every week, you say, “What did you pick up on? What was a burden to you? What didn’t make sense? What could I have done better?” But it will require more intentionality, and I think it just feels different. The shadowing process can be done virtually, but it feels different.
So the boring solution I would say is shadow. At GitLab, we have a CEO shadow program where people can opt in to shadow our CEO for two consecutive weeks to get a very high-level view of the business. I’ve done it twice. It’s been incredibly eye opening. I see no reason why you couldn’t do something similar to that for new hires or for junior hires.
The other thing that I want to talk about — and I know that we’re rearing out of tactical and into theoretical — I really think that the up and coming generation of the workforce is going more prepared for this than we think. This is a generation that never knew the world without the internet. Many of them met their best friends using a virtual or digital means first, and then only after that foundation, did they meet them in person. It’s the complete opposite to anyone who is 40 years or older. You always had to meet someone first and then eventually the internet came along and then you met them digitally.
So I think that COVID will accelerate a shift, especially in the education space where universities are going to ask themselves, what value do we add now? And things like time management will become a piece of the curriculum that did not used to need to exist because universities knew that in the first year of someone’s co-located job, they’ll learn that stuff; we don’t need to teach that. Now that’s going to be an incredible value add. When you can basically learn anything from free YouTube videos, why would you pay for a university? Well, time management. I think that education will evolve and some of this will self-solve, going back to the awkward teenager phase. In the interim, a virtual shadow program is a very rudimentary way to get started on it.
