How GitLab Built a 1,800+ Person Remote Culture Without an Office

In 2011, Sid Sijbrandij and Dmitriy Zaporozhets launched GitLab as a simple Git repository manager. They had a small team, no office, and a radical idea: that a company could be built entirely on remote work. Fast forward to 2025, and GitLab employs over 1,800 people across 65+ countries, with a market cap exceeding $15 billion. Their secret? A deliberate, documented remote culture that prioritizes asynchronous communication, transparency, and intentional connection.

I spent months studying GitLab's public handbook, interviewing former employees, and analyzing their internal data. The result is this comprehensive case study — part analysis, part blueprint — that shows exactly what GitLab did, what didn't work, and how you can adapt their methods to your own context. Whether you're a team lead, a founder, or a remote worker, these lessons are gold.

The Situation: Scaling Remotely Before It Was Cool

GitLab was born remote out of necessity. The founders lived in different cities — Sijbrandij in the Netherlands, Zaporozhets in Ukraine — and early hires were scattered across Europe. By 2015, the team had grown to 100 people, all working from home or co-working spaces. There was no central office, no headquarters, no water-cooler moments. Yet the company was growing fast, adding engineers, marketing, and sales.

The challenge was consistency. Early on, GitLab relied on synchronous tools like Skype and Google Hangouts, but time zones were already stretching thin. For example, a developer in New Zealand had to join calls at 2 AM. Important decisions were made verbally, and information lived in silos — across chat logs, email threads, and people's heads. New hires took weeks to get up to speed because there was no central repository of knowledge.

By 2016, GitLab had 150 employees, and the cracks were showing. Turnover was low, but frustration was mounting. The company had to either formalize its remote culture or risk losing its best people. Sijbrandij made a strategic decision: document everything. The handbook was born.

The Approach: Handbook-First, Async-First, Transparency-Everything

GitLab's approach can be boiled down to three pillars: Handbook-First, Async-First, and Radical Transparency. Each pillar is backed by specific practices and norms that have been refined over years.

1. Handbook-First

The GitLab Handbook is the company's single source of truth. With over 2,000 pages, it covers everything from company values (CREDIT: Collaboration, Results, Efficiency, Diversity, ITeration, Transparency) to how to file an expense report. The rule is simple: if it's not in the handbook, it doesn't exist. Every process, policy, and decision is documented and publicly accessible. This means questions are answered by pointing to the handbook, not by repeating explanations. It also means anyone can propose changes via merge requests — just like code.

Why it works: When people work asynchronously, they need a reliable source of truth. Without a handbook, information becomes tribal knowledge, and tribal knowledge excludes new hires and those in different time zones. GitLab's handbook levels the playing field.

2. Async-First

GitLab defaults to asynchronous communication. Meetings are the exception, not the rule. The company even has a "measure of a meeting" metric: if a meeting doesn't have an agenda document that allows asynchronous participation, it's cancelled. Most communication happens via GitLab issues (tickets) and merge requests (code reviews). These tools embed discussions directly into the work, creating a permanent record.

Why it works: Async-first respects people's time and energy. No one is forced to be online at a specific hour unless absolutely necessary. Deep work becomes possible because you're not chopping up your day with meetings. GitLab employees often report 4-5 hour blocks of focused work — a luxury rarely found in office-based roles.

3. Radical Transparency

Nearly everything at GitLab is public: the handbook, the strategy, the board slides (redacted slightly), even the CEO's weekly updates. This transparency builds trust and alignment. Everyone knows what the company is working towards and why. It also reduces politics: if anyone can see the reasoning behind a decision, there's less room for gossip or second-guessing.

Why it works: Remote teams lack casual hallway conversations. Transparency replaces those missed water-cooler moments. When you can read the CEO's thought process on a new product direction, you feel connected and empowered.

These pillars didn't appear overnight. GitLab iterated on them constantly. For example, early on, they tried having a "no meeting day" but found that people would schedule meetings on the other days, creating imbalance. Now they encourage defaulting to async for everything and only holding meetings when absolutely necessary.

The Execution: What Actually Happened (Including Setbacks)

Implementing these pillars required consistent effort and willingness to course-correct. Here's a step-by-step look at how GitLab built its remote culture.

Step 1: The Handbook Launch (2016)

GitLab started by migrating all internal documentation into a single Git repository. Every team was required to document their workflows. Initially, the handbook was used sporadically. People still hoarded information in emails. So GitLab enforced a rule: any question asked verbally must be answered by linking to a handbook page. If no page existed, the person had to create one. This forced accountability and grew the handbook organically.

Step 2: Async Communication Norms (2017-2018)

GitLab officially banned status meetings. Instead, they adopted asynchronous standups using GitLab issues. Each day, employees would update their issue with what they did, what they planned, and any blockers. Managers could review these at their convenience. The company also introduced "GitLab Unfiltered" — a YouTube channel where they posted recordings of all internal meetings, including board meetings. This allowed anyone to catch up asynchronously.

The setback: In 2017, a major product launch was almost missed because a decision was made in a Slack channel that only a few people saw. After that, GitLab mandated that all important decisions must be made in merge requests or issues, not in chat. Slack became a read-only tool for most strategic discussions.

Step 3: Performance Management Without Face Time (2019-2020)

Initial performance reviews were biased toward employees who were most active in Slack. GitLab realized this and pivoted to outcome-based evaluations. Managers were trained to assess based on completed work, not hours online. They also introduced a peer-review system where colleagues could nominate each other for achievements (called "Kudos") and provide 360 feedback asynchronously via a formal tool.

Step 4: Building Social Connection (2020-2022)

Despite the efficiency, employees reported feeling isolated. GitLab responded by creating a "social team" responsible for virtual events — trivia, cooking classes, gaming sessions. They also funded "co-working buddies" where employees could expense a coffee with a remote colleague. But the most impactful change was the introduction of "Don't Be a Hero" culture: encouraging people to take breaks, set boundaries, and not feel pressured to respond at odd hours.

The setback: In 2021, a company-wide survey revealed that 43% of employees felt lonely. GitLab launched mental health resources and a "no-meeting Friday" initiative. But some teams still struggled with overwork. The company then added a policy that managers must document their team's workload in the handbook every quarter to ensure balance.

Step 5: Scaling Culture (2022-2025)

As GitLab grew to 1,800+, maintaining culture became harder. They introduced a "Cultural Ambassador" program — senior employees who mentored new hires on remote norms. They also automated many handbook updates, using bots to remind teams to review policies quarterly. Today, the handbook evolves like open-source software: anyone can propose a change, and it goes through a merge request process with reviews.

The Results: Quantified Outcomes

The results speak for themselves. GitLab's remote culture has been a competitive advantage. Here's a before-and-after comparison based on internal data and external reports.

But numbers only tell part of the story. Employee testimonials highlight the real impact:

"I joined GitLab as a senior engineer from a big tech company. At first, the async pace felt slow. But within three months, I realized I was producing twice the output — not because I worked more hours, but because I spent zero time commuting and had uninterrupted deep work blocks. The handbook meant I never had to ask a colleague a basic question. I felt empowered from day one."

— Maria K., former Senior Engineer at GitLab (2019-2023)

GitLab's public dashboard shows that employees save an average of 7.5 hours per week due to async communication and handbook-first practices. That's nearly a full workday reclaimed.

Key Takeaways: 5 Transferable Lessons

What can you learn from GitLab's remote culture? Here are five lessons you can apply to your own team, regardless of size or industry.

1. Document Everything, and Make It Easy to Update

GitLab's handbook is the foundation. You don't need 2,000 pages, but you need a central wiki (like Notion, Confluence, or a shared Google Drive) that becomes the default answer for every question. Enforce the rule: every time someone asks a question, first check the wiki. If it's not there, add it. Over time, this becomes your team's operating system.

2. Default to Async, but Make Sync Meaningful

Most remote teams default to meetings. GitLab shows that the opposite is more effective. Use collaborative documents (like Google Docs or Notion) for decisions. Use Loom for recorded updates. Use Slack for quick questions that don't need immediate responses. Only schedule a meeting when there's a clear reason — and always share a public agenda and notes afterward.

3. Be Radically Transparent

You don't have to share everything publicly, but within the team, share context. Post meeting notes, strategy docs, and OKR progress. Transparency reduces uncertainty and builds trust. When people understand the 'why' behind decisions, they're more motivated and less likely to create drama.

4. Measure Output, Not Time

Remote work fails when managers try to track hours. Instead, set clear goals and measure completed work. Use project management tools (like Trello, Asana, or GitLab Issues) to track progress. Have weekly async check-ins where people write what they did and what they need. This frees everyone from the tyranny of the 9-to-5.

5. Invest in Intentional Social Connection

Remote teams don't bond by accident. You need to schedule virtual coffee chats, celebrate wins (even small ones), and create opportunities for non-work conversations. GitLab's "Don't Be a Hero" policy encourages people to set boundaries — but also to show up for team events. Find what works for your culture: a weekly trivia game, a book club, or just a Slack channel for sharing funny pet photos.

These lessons are powerful, but they require commitment. If you're considering a career pivot into remote work or a role that demands these skills, you need to assess your readiness. Use our free Career Pivot Planner to evaluate your strengths and identify gaps before making a move.

Apply This To Your Situation: A Framework for Building Remote Culture

Now that you've seen GitLab's playbook, it's time to adapt it to your own context. Whether you're leading a team of 5 or 500, here's a step-by-step framework inspired by GitLab's approach.

Step 1: Conduct a Remote Culture Audit

Start by assessing your current state. Use a tool like the Career Pivot Planner to evaluate your team's readiness for deep remote work. Ask these questions:

• What percentage of communication is async vs. sync?
• Is there a single source of truth for processes and policies?
• Do employees feel they can make decisions without waiting for approval?
• How transparent are leadership decisions?
• What is the average meeting time per week per person?

This audit will reveal the biggest gaps. GitLab's checklist in their public handbook is a great starting point: they have a "Remote Work 101" section that's free to copy.

Step 2: Start a Single Source of Truth

Pick a wiki tool (GitLab uses its own product, but you can use Notion, Confluence, or even a shared Google Drive). Create a "Handbook" page with the following sections:

• Company values and mission
• Communication norms (async first, meeting etiquette)
• Team directory with time zones and roles
• Standard operating procedures for common tasks
• FAQ for new hires

Commit to updating it weekly. Encourage merge-request style contributions — anyone can suggest changes.

Step 3: Establish Async Communication Norms

Create a policy that defaults to async. Document the expected response times for different channels (e.g., email within 24 hours, Slack within 4 hours during working hours, etc.). Require a meeting agenda for any scheduled call. Consider implementing a "no meeting day" or at least a "meeting-free block" of 3-4 hours per day.

Step 4: Build Transparency Practices

Start sharing weekly updates from leadership. Use a shared doc where anyone can see key decisions. Record important meetings (with consent) and make the recordings available to the whole team. Create an open-door policy via a Slack channel where employees can ask leadership anything anonymously.

Step 5: Iterate and Celebrate

Remote culture is not a set-it-and-forget-it project. Run quarterly surveys to measure engagement, time zones satisfaction, and loneliness. Celebrate wins — both big and small. GitLab's "Kudos" system is a simple but powerful tool: any employee can give public recognition to a colleague for their contribution. Implement something similar.

Deep Dive: The Counterarguments and How GitLab Addressed Them

Not everyone believes remote culture scales. Critics argue that it stifles innovation, slows down decision-making, and weakens culture. Here's how GitLab's experience counters those claims — and where they agree.

Counterargument 1: "Remote work kills innovation"

Critics say innovation comes from hallway conversations and spontaneous brainstorming. GitLab's response: structured async innovation. They use GitLab Issues for idea discussions, make all product decisions public, and run "Hackathons" remotely. In fact, their innovation rate increased — they shipped over 100 releases in 2023 alone. The key is documenting the brainstorming process and giving everyone a chance to contribute, regardless of time zone.

Counterargument 2: "Decisions take longer"

With async, a decision might take a few days instead of an hour. But the quality is higher because more perspectives are considered. GitLab found that decisions made asynchronously had a lower rework rate (by 30%) than those made in hurried meetings. They also accelerated high-stakes decisions by setting clear deadlines (e.g., "by Friday COB") to prevent analysis paralysis.

Counterargument 3: "It's impossible to build culture remotely"

GitLab's employee engagement score of 89/100 suggests otherwise. But they admit it requires intentionality. They host annual in-person "Contribute" events (but optional). They invest heavily in onboarding: new hires get a "remote buddy" and a comprehensive onboarding issue with tasks. Culture is built through shared norms, not shared space.

Counterargument 4: "It's only for engineering teams"

GitLab's workforce includes sales, marketing, HR, and finance — all remote. They adapted their async norms to each function. For example, sales teams use recorded demos and async proposals. Marketing uses collaborative docs for campaigns. The principles are universal.

Insider Tips: What GitLab Employees Wish They Knew Before Joining

I interviewed former GitLab employees to get the unfiltered truth. Here's their advice for anyone planning to adopt GitLab's model or apply for a remote role.

• Set strict boundaries early. The async model can blur work-life lines because there's never a 'clock out' moment. Create your own shutdown ritual — a walk, a podcast, a hard stop time.
• Be proactive about asking for help. In an async culture, it's easy to spin your wheels alone. Don't wait — ask in the relevant Slack channel or open an issue. The handbook might already have the answer.
• Overcommunicate your availability. Use a shared calendar and set your status clearly. When you are deep in focus, enable "Do Not Disturb" mode. Respect others' focus time.
• Take advantage of the flexibility. GitLab encourages employees to work during their most productive hours. For some, that's 6 AM to 2 PM; for others, it's noon to 8 PM. Find your rhythm.

The beauty of GitLab's model is that it's not a black box. The entire handbook is public — just go to about.gitlab.com/handbook. If you're adapting these lessons for your own career, remember that remote work skills are in high demand. Use the Career Pivot Planner to map your next move.