What you can (and can’t) learn from GitLab about remote work

A year after shelter-at-home orders emptied many offices, it’s no longer edgy to suggest many workers don’t need to go back to “colocation,” the jargon term for everyone working in physical proximity—same room, same building, or same campus. It’s been a decade since The Great Reset, a book by University of Toronto urban studies theorist Richard Florida, forecast that big-city offices would disappear in favor of distributed and remote workforces—not for pandemic safety, but for more fundamental economic reasons wrought by the spread of digital technology and high-speed networks. Last year’s lockdowns only tipped the scales on a change already in progress, forcing companies to learn in months what might have taken years.

Most organizations are still fumbling for the keys to productivity, employee satisfaction, and ultimately business success. The psychological issues of going remote are never-ending, but for this article we’ll focus on pragmatic strategies to get the work done when you can’t connect in person.

It’s not process—it’s practice

For CEOs and upper management, remote work is the biggest organizational challenge many have ever faced. How do you structure a work-from-anywhere company to succeed? What rules do you need to set down? What processes and procedures must be established? 

Any fiesty DevOps engineer will bristle: You don’t need processes, you need practices—internalized skills that workers learn, share, and develop into sharpened, smart reflexes through live repetition as a team. The term “best practices” is well established in big-company management, but DevOps culture—a melding of software developers and IT operators into a single role—grew out of the realization that for all the best-practices talk, entire divisions of companies had become segregated, entrenched, and mired in rules and barriers set up to keep order at the unwitting expense of results. Practices aren’t procedures, processes, or policies. They’re more like martial arts skills. You don’t follow them, you become them.

GitLab, a DevOps tool company based in San Francisco but spread around the globe, have become the go-to experts on distributed workforce practices. CEO Sid Sijbrandij was an early outspoken advocate of dispensing with office space entirely, on the premise that trying to maintain both an office workforce and a remote workforce was a formula for failure. (We’ve interviewed management and human resources experts who agree that hybrid workforces are a proven challenge to employee performance and retention.) 

After starting from an engineer’s home in Ukraine a decade ago, GitLab has “turned into The Little Company That Could,” as one admirer put it. There are plenty more fans: Forbes included Sijbrandij in a recent list of Top Business Minds of the Pandemic. And in a savvy hiring move, GitLab recruited former Engadget blogger Darren Murph, whose 17,000 posts had already earned him a Guiness World Record a decade ago, as Head of Remote to guide them as they grow. 

Plenty of tech companies work without a shared office, but Harvard Business School professor Raj Choudhury, who specializes in remote work and its future, told us GitLab is worth studying by others. “I don’t think they are distinctive in any form that gives them an advantage,” he says, meaning it’s not GitLab’s structure, business, or product that makes them different. Rather, “They were clearly an early adopter of this model, and they have done it well … This whole process of embracing all-remote or majority-remote work is an organizational transformation process.” 

GitLab has the advantage of being a small company (compared to Walmart) with a largely tech-savvy workforce. And they don’t have many companies’ challenges of shipping or handling physical products, providing in-person services, or needing to transition a large, established workforce from onsite to remote. Yet Choudhury says GitLab’s core approaches—which resemble DevOps thinking from the top down instead of bottom up—can and should be applied to most companies regardless of how their businesses differ: “It’s not about what you work on, it’s about how you work.”

What GitLab-proven techniques can you apply to your own organizational transformation? We refined them into a 1-2-3 set of high-level practices applicable to both all-remote and (more likely) hybrid companies who seek to succeed in a work-from-home world. 

1. Think async

We’ve all endured one: The hour-long Zoom that everyone groans could’ve been handled in email instead. Having to communicate in real time too often slows projects and wears on workers. It even happens within a single office. Companies with teams spread across multiple time zones simply notice it more readily than others. 

It’s worth noting that GitLab seriously tried to establish an office three times—once near Sijbrandij’s home in the Netherlands at the time, and twice in the San Francisco Bay Area where investors traditionally relocate tech founders to keep them at hand. But each time, team members came to the agreement that commuting to the office wasn’t worth the time, and living in Silicon Valley was no longer necessary.

Choudhury wrote in his 2020 case study on GitLab that operating asynchronously, i.e. without tying team members to the same schedule or requiring frequent meetings, “was key for a globally-distributed team, as it allowed each team member to work largely independently, regardless of his or her time zone.” 

Open source software projects, from which GitLab grew and still is, often operate asynchronously from the start. Contributors around the globe work at different organizations and contribute to the project on their own schedules. It’s not a huge step up for open sourcers to band together as a formal company with no central office and no central clock. 

Choudhury observed that in GitLab’s case, the executive team set company-level objectives and key results each quarter—the OKRs to which many of us adhere nowadays—but left it to the individual teams to decide for themselves how exactly to meet those goals.

Going async is a test in trust over risk for managers from top to bottom. It’s one thing to keep yourself from micromanaging your direct reports. It’s another to declare each company milestone as a destination, then take your hands off the wheel and believe everyone will get there on time without working the same hours.

There’s an upside to look forward to: Async work removes the rewards for presenteeism, the Dilbert-like skill some employees develop of being at their desks 9 to 5, looking busy while not getting much done.

GitLab encourages workers to break their own tasks down further into what’s called the minimum viable change. That is, do the least amount of work on a thing necessary to submit it for review, approval or use by whoever needs it, then pass it along. A few lines of code, or a paragraph of text, is enough to submit now rather than keep them waiting until the whole thing is done. The minimum viable change approach keeps work flowing, and can also let others identify problems, questions or challenges to one another’s work sooner.

Meetings are actively discouraged, unless “we go back and forth three times, then it’s time for a video sync call.”

2. Automate everything

Automation doesn’t mean replacing Earth’s humans with robots. But at least for regular steps in workflow, look for and try to remove points where one human worker needs to get another one involved to move things forward. A major impediment to async work is the need for person A to get word from person B before continuing a task, or for person B to do some typing to move person A’s output to the next stage of input. 

Software engineers almost can’t help automating their workflows—why wait for someone else to eyeball your code for errors or merge it into a larger product when you can configure or even create a tool that checks it automatically in seconds?

Good automation tools are both faster and less prone to error. You don’t need to wait for them to become available. They don’t procrastinate or forget. In a global async workforce, they don’t take a day to exchange one round of emails or forget that one worker’s weekday is another’s weekend. In fact, automating everything is one way that distributed teams prevent the burnout demand of round-the-clock availability from team members.

Automation has long been a foundation of the Continuous Everything approach to software development and IT support. But there are plenty of everyday work tasks for which most companies haven’t enabled workers to self-serve. 

Automated reporting on company metrics is one of the most powerful tools for keeping a distributed company on track. Dashboard tools replace weekly status write-ups and go-around-the-room meetings with onscreen stats, statuses, and problem notifications that anyone (provided they’re given access) can check anytime. Not only does your manager know what’s up (or down), but people in other parts of the company who depend on your deliverables don’t need to wait til next week’s meeting to find out if there’s a problem or not.

There are many free open-source dashboard tools, and free customizations for commercial tools like Salesforce’s Tableau. I myself work on a team that wraps from Asia to Australia to California, New York and a picturesque village in Italy where one of our star performers is stuck in lockdown. No one ever needs to ask me how it’s going and wait for a response—there’s a private URL where traffic stats, systems statuses, and my cheery notes are displayed in real time 24/7. 

GitLab’s software can be set up to post to Slack automatically when there are changes, comments, or other events about which your faraway teammates might not remember to tell you.

3. Document everything

Just as important as keeping communications async, GitLab pushes to keep them public within the company, so that others can find and learn from them. The company maintains a giant employee handbook—not the kind written by HR that no one reads, but a collaborative, employee-written trove of 10,000-plus pages to which all employees are expected to contribute. Got a question? Search the handbook first.

The handbook isn’t a free-for-all wiki. Each section has someone who maintains it and reviews requests for changes, just as programmers do with source code, before allowing them to be incorporated. It’s more organized and curated than telling employees to search Slack because the practice was discussed somewhere in Slack sometime last year. 

Instead of Slack, Google Docs, or another tool designed for collaborative work, GitLab uses their own product which began as an open-source software project collaboration system. What matters isn’t which tools, but that important information is available to whoever needs it from wherever, whenever. An employee who encounters an unfamiliar situation or unexpected need can look up GitLab’s preferred method of dealing with it, or at least whom to contact for help. 

Marco Minervini, a postdoctoral researcher at European business school INSEAD, documented this “handbook-first” approach in a case study he co-authored. A new employee was told that his first week with GitLab wasn’t about doing his specific job, but about “learning to work the GitLab way.” That included reading through the handbook to become familiar with it for future needs, both as a reader and as a contributor. They won’t memorize the extensive guide to how to communicate in their first week on the job, but they need to know it’s there.

“The value of this knowledge work is underestimated,” Minervini says of the handbook. Weighing the amount of learning most knowledge workers need to do for any job, versus the time required to create the documentation that would speed that learning, he says that at most companies, “my speculation is they could do far more.”

Choudhury agrees that documenting practices and keeping them up to date is critical to keeping an async team in harmony and on track. The HBS GitLab case study uses a fictional example to make the point: An employee asked to speak on a podcast divulges something publicaly after checking the handbook and not finding the guidance that would’ve prevented the PR fumble. 

Beyond the handbook, the company documents its day-to-day decisions, status reports, meeting agendas, meeting results, project progress, problems encountered, and their solutions. Burning questions and minimum viable answers to those questions are available online internally. It requires workers to devote more time to writing, but speeds up workflow overall. 

GitLab meetings are recorded, so employees who don’t need to be there to contribute can still watch or listen to them later as better fits their schedules. The handbook tells attendees to take written notes as well: “A surefire way to waste time in a meeting is to avoid writing anything down.” You’re expected to write down the results of any real time conversation about work.

The company hired Murph because in addition to being a prolific writer, he’s an evangelistic educator who has written an extensive guide to transitioning to and managing remote work. Teaching everyone to become a better documentarian is high on his list.

Choudhury says this pervasive kind of documenting needs to become an always-on instinct for everyone: “Even if you are in a hybrid remote world, you need to work remote-first. Even the folks working in an office, or on the days you come into the office, you need to act like you are working remote, and document the things you would if you were remote.”

Can a colocated company go remote?

Maybe you’ve heard the joke: A company CEO gets the entire company on Zoom after everyone has been vaccinated against COVID-19, and announces that while it’s safe to return to the office, henceforth they’ll only have to come in one day a week. 

After the applause dies down, the CEO says, “That day is Thursday. See you then.”

Minervini says that boss gets why they still pay for an office. “My take on this is you need to coordinate the days,” he says, so that people and teams who rely on one other for throughput are in the office on the same day. If what workers really want is a half-empty room away from home where they can work unbothered, that’s a separate discussion. 

Creating a hybrid workforce that doesn’t flounder is pretty much all that human resources publications talk about in 2021. GitLab’s take is unwavering: Don’t even try. “For decades,” Murph wrote us, “remote workers have absorbed subpar access to praise, promotion, and information because they prioritized community and time with family. Post-pandemic, they will have more options. Top talent will only tolerate subpar and archaic workflows for as long as they have no better options.”

How does his company provide better options? Murph says they’ve gone to great lengths to keep employees in touch with the top of the org chart as the company grows:

As the company scales, leadership is more inclined to host company-wide AMAs, Iteration Office Hours, and Group Conversations. These mediums enable everyone to interact with senior leadership, both synchronously (during the live AMA) and asynchronously (by adding questions in advance via a Google Doc affixed to the meeting invite). 

Minervini says while open-source software and DevOps practices succeeded as a bottom-up movement among technical staff, transforming into a remote-first company needs the people at the top to believe in it. But that’s not enough: “In addition to the organizational structure, there’s also the selection of people. GitLab select people who already know they’re going fully remote, and they are very careful in their selection of personnel—that process is more demanding.”

In fact, several thriving all-remote companies Minervini has studied put candidates through more rounds of interviews and more up-front checks, even tests on their potential to deliver in a remote team. Even so, these companies often learn to live with higher turnover rates, as new employees either struggle or grow dissatisfied with a new style of work which both they and their employers are still exploring.

Large companies that successfully transform into remote-first, he says, will certainly have a lot of turnover. Again, it’s a selection process: People whom the company chose (and who chose the company) to work in an office setting often won’t be the right match to do the same work from home. In that light, he says, “Attrition is not necessarily a problem.”

The good news: Human resources managers have told Minervini that remote-worker attrition is highest among new hires and junior staff. More senior staff, who’ve gotten to know each other over time, have better adapted to being sent home.

Rejoice! We have no choice

Just having Tom Brady’s playbook won’t win you the Super Bowl. Implementing these practices doesn’t guarantee your remote teams will thrive. Nor does embracing remote work mean you’ll beat your business rivals. GitLab is doing pretty well—it was valued at $6 billion in a recent pre-IPO stock sale—but they face fierce competition and entrenched big-budget leaders in the markets for their wares. It would be naive to claim that simply being all-remote guarantees success.

Regardless of how GitLab fares, though, it’s clear after a year that many of us won’t be heading back to a 9-to-5 desk, even if COVID-19 is wiped from the Earth. Remote and asynchronous work has too many advantages and too much appeal to give up. We’re still figuring it out, but here’s the start: Automate everything, document everything, and always think async. Even if you do work in an office, you’ll get more done.

To read more about GitLab's research, check out their Remote Work Report, sponsored by Dropbox, which surveyed over 3,900 people worldwide.