How GitLab Runs 2,100 People With No Meetings
Most teams inherit their meeting culture the same way they inherit technical debt: gradually, silently, and without anyone signing off on it. GitLab decided early on to build a genuine no-meetings culture — and the numbers justify it. Here’s what they built instead — and why it’s worth more than $300,000/yr for a 10-person engineering team. The result is what the industry now calls a no-meetings culture — and GitLab is its most documented example.
The GitLab no meetings model is one of the most studied async systems in the world — and one of the most misunderstood. This is what it actually looks like in practice.
The meeting problem GitLab refused to inherit
Most companies grow into meeting culture the same way they grow into bad posture: gradually, without noticing, until it’s too late to fix without deliberate effort. A team of 5 has a weekly sync. That sync outlives the project that created it, the manager who scheduled it, and occasionally the entire product it was meant to support. Nobody cancels it because nobody officially owns the decision to cancel it.
GitLab had a different constraint. With employees in 65+ countries across nearly every time zone imaginable, a default of synchronous meetings wasn’t just inefficient — it was physically impossible. Someone was always going to be joining at 2am or skipping entirely. So they did what most companies only talk about doing: they built a system where the meeting is the last resort, not the first instinct.
What’s interesting is that GitLab will tell you this wasn’t a bold strategic move. It was a survival mechanism. The GitLab no meetings philosophy — as it’s now widely referenced — turned out to be a genuine competitive advantage.
2,100+ employees · 65+ countries · first officeless company to go public · 85% of questions resolved without scheduling a meeting · 15 hours saved per person per month · sprint planning time reduced by 50% after moving to async. Source: GitLab Handbook and JetThoughts async study.
The core decision: handbook-first, meetings last
The principle that drives everything at GitLab is deceptively simple: if it isn’t written down, it doesn’t exist. Every decision, every process change, every policy update must be documented in their public handbook before it is communicated or implemented. Not after. Before.
In practice this means that instead of calling a meeting to align on something, the default is to write a proposal, post it, and collect feedback asynchronously. The meeting is reserved for things that genuinely require real-time human interaction — and according to GitLab, that turns out to be a much shorter list than most teams assume.
It’s worth being honest about what this requires: it asks leaders to change their default behaviour first. Most async initiatives fail not because the tools are wrong but because managers keep defaulting to «let’s just jump on a call.» Every time that happens, it sends a signal that async is optional.
«A memos-over-meetings culture creates an atmosphere where business results can be decoupled from linear time, leading to more flexibility and a sense of control. Writing forces clarity of thought. When you write what you’re planning to converse about, it leads to more precision, and it enables more parties to contribute input to the topic at hand.»
The 5-layer async system GitLab built
Their approach isn’t one tool or one policy — it’s five interlocking layers that make async the path of least resistance for every type of work:
1. The public handbook as single source of truth
Every process, role, expectation, and decision lives in a fully public, version-controlled handbook. When an employee has a question, the answer is almost always already documented — no meeting, no Slack ping, no waiting for someone in a different time zone to wake up.
2. Issues and merge requests replace verbal alignment
All work is proposed in writing via GitLab Issues or MRs. Stakeholders comment asynchronously. Decisions are made in threads, not calls. The written record becomes institutional memory — searchable, permanent, and available to anyone who joins the team later.
3. Live Doc Meetings for unavoidable syncs
When a meeting is truly necessary, GitLab uses what they call Live Doc Meetings: a shared document is the agenda, the notes, and the action items — all updated in real time during the call. The meeting ends; the document lives on. No follow-up email needed.
4. OKRs documented quarterly, checked monthly
Each department’s quarterly goals are publicly documented and checked against progress monthly via written updates — not all-hands calls. This eliminates entire categories of status meetings across the company.
5. Results over presence — no facetime culture
The company explicitly measures output, not availability. There are no «working hours» expectations tied to a specific time zone. This removes the psychological pressure to attend meetings as a visibility signal — the root cause of most over-meeting in traditional orgs.
GitLab no meetings: the results — and what they don’t tell you
The numbers from The results are genuinely impressive. But before presenting them it’s worth noting what they don’t capture: the first 6–12 months are hard. New employees without experience in async environments take significantly longer to onboard. Some people find the written-first culture isolating at first. They acknowledge this in their own handbook. It’s not a silver bullet — it’s a trade-off that happens to pay off very well if you’re willing to go through the transition.
With that caveat stated, here’s what the data shows:
| Metric | Result | Impact |
|---|---|---|
| Questions resolved without a meeting | 85% | 15 h/month saved per person |
| Sprint planning time reduction | 50% | 2–4 h/sprint returned to ICs |
| New hire onboarding speed | 50% faster | Handbook replaces onboarding calls |
| Synchronous meetings per week (avg) | Fewer than 4 | vs. 8–14 industry norm |
| Employee satisfaction with communication | Top-quartile | Consistently rated great place to work |
The company scaled from a small open-source project to a publicly traded company worth over $15 billion — without ever opening a physical office. Whether async caused the growth or simply didn’t prevent it is a fair debate. What’s harder to argue with is the cost per employee of their meeting load compared to industry benchmarks.
5 things you can copy from GitLab’s system today
You don’t need to be fully remote or restructure your entire company. These five tactics are the highest-leverage elements of GitLab’s system — each one works independently and shows results within weeks:
| Tactic | What GitLab does | Your equivalent | Expected impact |
|---|---|---|---|
| Handbook-first decisions | Document before communicating | Notion, Confluence, or Linear doc | -30% decision meetings |
| Issues over verbal alignment | All proposals written in GitLab Issues | Linear, Jira, or GitHub Issues | -50% sprint planning time |
| Live Doc Meetings | Shared doc = agenda + notes + actions | Google Doc open during every call | -25% meeting duration |
| Async status updates | Written OKR check-ins monthly | Loom video or Notion weekly update | Eliminate status meetings entirely |
| Results-based culture | Output measured, not availability | Ship metrics over attendance metrics | Removes meeting-as-visibility pressure |
How to roll this out in your team: a 4-week plan
They built this culture over years. You can capture most of the benefit in 4 weeks by focusing on the highest-impact changes first:
Week 1 — Audit and baseline
List every recurring meeting your team attends. For each one: who owns it, what decision or output it produces, and whether that output could be achieved with a written document instead. Calculate the combined hourly cost.
Week 2 — Kill the status meetings
Replace every weekly status update with a short async format: a Loom video, a Notion page, or a Linear comment. Give your team one week to adjust. Resistance is normal — it passes once people get 2 hours back.
Week 3 — Introduce Live Doc Meetings
For every meeting that survives the cut, open a shared document before the call starts. Agenda goes in. Notes go in during the call. Action items go in before anyone leaves. No follow-up email needed ever again.
Week 4 — Start your handbook
Pick one recurring decision that happens verbally and document it. One process, one page. Share it with the team. Invite edits. This is how their 2,000-page handbook started — one documented decision at a time.
What this is actually worth in salary
The numbers above are compelling in the abstract. Here’s what they mean for a real engineering team. Take a team of 10 engineers — not a large org, just a typical product squad — attending 8 meetings per week at an average of 50 minutes each, with a fully-loaded average rate of $95/h per person:
10 people × $95/h × 0.83 h × 8 meetings × 48 weeks = $303,168/yr in meeting overhead.
Apply GitLab’s model conservatively — not 85% reduction, but 60%, because your team isn’t fully remote and you’ll keep more syncs than GitLab does. That still brings the number down to roughly $121,000/yr, returning nearly $182,000 in engineering capacity annually. That’s a senior engineer’s fully-loaded salary. Every year. From fewer meetings.
Conclusion
The honest version of this case study is: GitLab’s system works, but it’s not easy to copy, and most teams won’t fully copy it. That’s fine. You don’t need to go fully async to get most of the benefit.
What you do need is at least one person with enough authority to cancel their own recurring meeting first — and mean it. In most organisations, that’s the blocker. Not tools, not processes, not culture decks. Just one manager who’s willing to be the first to say: «This meeting doesn’t need to exist.»
Darren Murph put it plainly in an interview: «Meetings should not be the default way to move a piece of work forward.» That single sentence, if genuinely acted on, would recover more engineering hours than any productivity tool on the market.
FAQ: GitLab async meetings
How does GitLab manage without daily meetings?
GitLab replaces verbal alignment with written artefacts. Every decision is documented in their public handbook before being communicated. Questions are resolved via Issues and MR comments — 85% without ever scheduling a call. That is the foundation of the GitLab no meetings philosophy.
What is GitLab’s handbook-first culture?
Any change to process, policy, or decision must be written into the GitLab Handbook before it is communicated or implemented. This creates a single source of truth that replaces most status and alignment meetings entirely.
How many meetings does the average GitLab employee attend per week?
Fewer than 4 synchronous meetings per week on average — compared to an industry norm of 8–14 for engineering roles. This translates to roughly 15 hours per month returned to each employee for focused work.
Can non-remote teams apply GitLab’s async model?
Yes. The core tactics — handbook-first documentation, Live Doc Meetings, async status updates, and issues over verbal alignment — work in hybrid and in-office environments. The starting point is replacing status meetings with written updates, regardless of where your team sits.
What tools does GitLab use for async communication?
They use their own platform (Issues, MRs, and comments) for work decisions, Slack for informal communication with strict norms against using it for decisions, and shared Google Docs for the rare synchronous meetings they do hold.
How long does it take to shift to async-first culture?
Most teams see measurable results within 2–4 weeks of replacing status meetings with async updates. A full cultural shift — where documentation is the default instinct — typically takes 3–6 months with consistent leadership modelling.