GitLab’s CEO on Building One of the World’s Largest All-Remote Companies

When Dmitriy Zaporozhets and I decided, in 2013, to launch an enterprise business around GitLab—the open-source collaborative software-development application that he’d designed and I’d been working on—it wasn’t with the intention of turning it into one of the world’s largest all-remote organizations. It was just that we lived 2,000 kilometers apart—he in Ukraine and I in the Netherlands—and our first hire was in Serbia. None of us wanted to move, so GitLab began its corporate life with a small, distributed workforce. When we brought on a few more Netherlands-based team members, my house was initially our office. They came over each morning, we coded side by side, and then they went home. But within a few days we realized that we didn’t need to be colocated to work effectively, so the team dispersed. By 2015 we had participated in a Y Combinator boot camp and were ready to expand our business into the United States. Our investors were supportive but suggested that we establish a U.S. headquarters, arguing that although our engineers might be able to work from anywhere, our sales and finance teams would have trouble doing so. I moved to the San Francisco Bay area, and we opened an office there. Again our new team members came in for a few days but then retreated to their homes or other workspaces. Again we saw that colocation wasn’t necessary for us to create and market a great product. Dmitriy and I made it official: GitLab would be an all-remote company. Today our more than 2,000 team members are spread across some 60 countries and regions around the world. We neither own nor rent any corporate office space, and we believe that our early adoption of an all-remote approach has made us a better, more scalable company. Well before the Covid-19 pandemic hastened such a shift for other organizations, we embraced and developed best practices around virtual collaboration. We’ve learned that success depends on measuring output, not input; aligning our people on norms and values; ensuring that policies and processes are continually and openly documented; and reinforcing self-management and people-management skills. As a result we’ve been able to hire top talent from around the world and harness its energies to drive GitLab’s quarterly revenue to $113 million and year-over-year growth to 69% as of the quarter ended October 31, 2022. Now that other corporations and start-ups are experimenting with going all remote, we hope to share our lessons. Output, Not Input It won’t surprise you to learn that we use the GitLab platform to collaborate on writing, reviewing, troubleshooting, launching, and monitoring the performance of our code. Managers create a project, or “milestone” in our parlance, within which specific tasks, or “issues,” are to be completed. Those issues are assigned to one or more team members via a “merge request” labeled “work in progress.” Colleagues trade off working on the issue until they deem it ready to “stage” and “commit.” Their code is then run through a series of diagnostics that test for accuracy, security, and performance. If it passes muster, it’s launched, and we continue to track how it performs. If problems are identified, the team iterates on solutions. This entire history of work remains accessible to everyone for reference. Dmitriy’s initial version of GitLab was an open-source tool, and programmers who used it contributed to the underlying code. I joined with the aim of developing a more robust version to sell to corporations, and in 2014 we shifted our business model to focus on that paid offering while leaving a core tool available to all at no cost. That’s when we started hiring more. I’ll admit that I was a little worried when those first few Dutch team members stopped coming into the home office I’d fashioned for us. Were the chairs not comfortable enough? The snacks not tasty? Had I forgotten to shower? My colleagues assured me that it was them, not me: They were simply more productive on their own time, in their own spaces, without commutes. We had all the technology we needed—Slack, Zoom, webcams, Google Docs, and of course GitLab—to communicate, collaborate, and even develop rapport. And what mattered most to Dmitriy and me? Progress and results. Success isn’t measured in input such as hours spent at an office. It’s about output—what you achieve. Today at GitLab, I work with the executive team to set company-level objectives and key results (OKRs) for each quarter, but the relevant teams decide how they want to meet those goals. Each group agrees on its own OKRs and on how action items should be assigned, and then individual members can do the work when and where they choose. Rather than tracking hours logged, we follow the metrics that matter most for each department. For salespeople, they are sales totals and client satisfaction; for customer support staffers, they’re response and resolution time; for software engineers, speed of development and deployment. Interestingly, when we decided to start measuring how many items of work the engineers were able to finish, or “ship,” in a month—rather than the number of whole projects they’d completed—many people told us they could game the results by breaking up the work into ever smaller parts. We told them to go ahead, and the piecemeal approach generated faster and better results. Cultural Alignment Another way we measure team members’ performance is by how well they work on the GitLab platform and uphold our values, because that alignment is crucial, especially in a fast-growing, all-remote organization. Every corporate culture rests on norms and values. Norms are the policies and practices that guide how work gets done, how colleagues communicate, and so on. Values are what the organization cares about. At GitLab the top two values are results and iteration. The GitLab handbook both documents and reflects our culture. It is an evolving online encyclopedia that contains more than 2,000 web pages of information, including answers to basic questions such as “How do I create a merge request?” and “How do I file an expense report?” and a list of the 22 ways we reinforce our values, from promoting only those people who espouse them to having a corporate songbook full of adaptations such as “You’re the Iteration,” sung to the tune of Chicago’s “You’re the Inspiration,” which we often belt out on team karaoke nights. I and the rest of the executive team also practice what we preach. If you drill down into the handbook’s team section and click on my picture and the “read me” link, you’ll find not just my bio but also a list of my flaws (with a directive to tell me when I succumb to them or to point out ones that I haven’t yet noticed), advice from my direct reports on how to work with me, instructions for arranging one-on-one time with me, and a schedule of my regular meetings—among them monthly “iteration” office hours, during which I meet virtually with any and all team members to talk about how we can get better at incremental innovation and reducing the scope of each project so that we can ship sooner. A collage of GitLab team members and their pets. Courtesy GitLab One big concern about distributed workforces is that people will miss out on the knowledge transfer that comes from being in the same place and able to consult colleagues spontaneously. The handbook helps us solve that problem because it provides a single source of truth accessible to anyone at any time. Our team members can’t stop by a peer’s office to ask for help, but they can consult an up-to-date, collectively edited resource to get the answers they need. If what they need to know isn’t there, the next step is to work with colleagues via Slack or Zoom to understand or decide on the right information or course of action and then add those insights to the handbook. It takes a bit of time and energy in the short term but creates great long-term benefits. GitLab is fortunate to have operated this way since the beginning. At co-located start-ups culture tends to emerge and spread informally. But as organizations expand into multiple offices, cities, and countries, formal documentation and reinforcement of norms and values become more important. Many companies struggle with the transition. We never had to make that shift. We’ve always known how to ensure that our team, while fully dispersed, is nonetheless in sync. Open Everything A primary reason that GitLab gravitated to distributed work and adopted transparency as a core value is the open-source nature of our tool. From the start Dmitriy wanted everyone to be able to see the code and build on it, and we get hundreds of contributions from our community every quarter. By eschewing offices, we put external collaborators—including customers such as Goldman Sachs, T-Mobile, and Lockheed Martin—on a level playing field with GitLab team members. We’re all connected in the same online workplace, making collaborative software development more efficient. We are also open with most of our corporate information, and we publish a detailed list of what we aren’t willing or able to share. Public is the default, and any exceptions are noted. The handbook, for instance, is online for all to see: programming rules, the songbook, the rundown of my flaws—everything. As a result, GitLab team members aren’t the only ones who use it to solve problems. Many people outside the company—especially those working on software development—have told us that when they don’t know how to proceed with a task, they often Google their issue plus “GitLab handbook” to see if our policies and practices can help them—or at least provide inspiration. Our commitment to transparency has helped us win customers, investors, and talent because it creates trust. Our stakeholders understand that being so transparent makes us accountable for addressing problems and providing solutions. For instance, by publishing our product road map in the handbook, we let everyone see what’s forthcoming. And if you Google “GitLab onboarding,” you’ll learn about the 200 steps in the process—tasks for the individual, the manager, and the rest of the company. Applicants and new hires tell us they appreciate knowing exactly what to expect from us. As for work on our enterprise product, all team members can review the merge requests, issues, and commits of others. An idea we talk about a lot is the need for short toes—ones that can’t be stepped on. If a colleague, close or distant, sees your code and has a suggestion for making it better, don’t be offended. Embrace it. We encourage handing off work in progress to ensure that happens as often as possible. Recently we’ve also introduced something we call “key meetings”: We ask each department to give virtual presentations on its progress toward quarterly OKRs, key indicators, and top-of-mind issues not just to the executive team but also to a wider, interdisciplinary audience from across the company. We circulate an agenda and people submit questions. Some attend live, others listen to a recording, and it becomes a group rather than a siloed conversation. Good Management Whether you lead an in-person or an all-remote team, many of the same good-management rules apply. The first is exhibiting and encouraging self-management—what we call being a manager of one. We hire and train self-starters who can both handle the autonomy associated with working remotely and proactively engage with their teams. We expect all managers and executives to host regular team and one-on-one meetings and to have an open-door (Slack and Zoom) policy. Being too busy for others should not be a point of pride. Informal communication is critical, especially for virtual teams, so we should all make the time for it. Indeed, a team member in Israel popularized the concept of a coffee chat—booking a colleague for a short virtual meeting with no agenda so that the conversation can unfold naturally, as if in an elevator or at a watercooler. That’s been standard practice across GitLab for years now. We also encourage in-person meetings. Different teams do it with varying frequencies, but during the first month of every quarter we invite team members to use a “get-together grant” to meet up with a team member either in person or virtually. Before the pandemic the entire company gathered once a year in a destination such as Cape Town or New Orleans for a week of workshops and activities focused on strategizing and team building. In some areas we follow the same best practices that other thoughtful companies do. For example, we work with team members to create a formal career and growth plan. That helps even the most far-flung to feel safely tethered. In other managerial realms we are establishing new standards. Consider team meetings. Most of ours last 25 minutes, which forces greater efficiency. Notes are taken collaboratively in real time in a Google Doc, which helps clarify and record the resulting action items while giving people who couldn’t attend greater insight into what they missed. We’ve distilled these and many other ideas into something we call “TeamOps” and have made it public as a guide for any organization—remote, hybrid, or colocated—that’s looking to improve and speed up its collaborative decision-making and execution. Since October 2022 we have also offered a TeamOps certification externally. . . . As more knowledge-work companies consider how they want to operate in a post-Covid world, it’s been surprising to see so many insisting that employees return to an office, either full- or part-time, despite the widespread productivity jumps that occurred during lockdowns. In our view, an in-person workplace operates well until you grow out of a single room. Once you spread to other floors and locations, the work becomes more virtual anyway. Hybrid, meanwhile, is the worst of both worlds, because it creates a divide between those in the office and those outside it. I think we can all admit that meetings with half the people in a room and the other half on Zoom are typically disastrous. At GitLab we believe that tech-enabled distributed teams are the future of knowledge work. We’ve been able to hire exceptional talent from all over the world and introduce our employees to a more flexible and productive kind of teamwork that has propelled our company to new heights. But our success has rested on careful adherence to the principles I’ve described. We hope that more organizations will follow our lead and learn how to run an all-remote workplace well.

GitLab’s CEO on Building One of the World’s Largest All-Remote Companies

Summary.

Partner Center