How GitLab Runs the World's Largest All-Remote Company With a 2,000-Page Handbook

Snapshot

GitLab is one of the largest all-remote companies ever built. 2,500+ team members. 65+ countries. No offices — not a single one. They are also a publicly traded company (GTLB on NASDAQ, IPO October 2021), which means this operating model survives not just the early scrappy years but IPO scrutiny, quarterly earnings calls, and enterprise sales.

Their defining operational choice: when in doubt, document it. The GitLab Handbook has over 2,000 web pages of publicly available content covering every aspect of how the company runs. It is not just a policy document — it is the operating system itself.

Core Philosophy

GitLab uses the term “all-remote” deliberately and with a specific definition: no company-owned offices, anywhere. This is different from “remote-friendly” (office exists, remote is allowed) and “remote-first” (office exists, but processes favor remote). At GitLab, remote is not a policy exception — it is the only mode. (Source)

Their remote manifesto:

• Asynchronous communication over synchronous communication
• Formal communication channels over informal ones
• Written processes over verbal explanations
• Results over activity

(Source)

“Remote is not a challenge to overcome. It’s a clear business advantage.” — Victor, Product Manager, GitLab (Source)

Communication Model

Async is the default. Synchronous communication is explicitly a last resort. GitLab’s guidance: if back-and-forth reaches three exchanges on the same topic, move to a video call. Otherwise, handle it in writing. (Source)

Writing standards are specific and enforced:

• Short sentences — fewer than 15 words
• Replace adjectives with data
• Avoid acronyms and jargon
• Subject-Verb-Object sentence structure
• Assume positive intent in text (tone is easily lost)

(Source)

Primary tools:

• GitLab issues and merge requests — for all project work, decisions, and technical discussion
• Slack — async-first usage with “do not disturb” norms; not expected to produce real-time responses; supplementary to issues
• Google Docs — collaborative documentation
• Zoom — video calls when needed

Slack is not a decisions tool at GitLab. Important conversations are moved to GitLab issues so they are searchable, permanent, and accessible to anyone who needs the context later. (Source)

Meeting principles:

• All meetings require a live doc agenda attached to the calendar invite, minimum 24 hours in advance (ideally 72)
• Meeting attendance is optional for non-essential participants
• Time zones across EMEA, APAC, and AMER are factored into scheduling
• Ask: could this meeting be replaced by async? If yes, it should be.

(Source)

Planning and Cadence

GitLab uses a structured multi-horizon cadence:

(Source)

OKRs are the quarterly planning mechanism — used company-wide and tracked in GitLab’s own OKR tooling. (Source)

Dual career paths allow individual contributors to grow without entering management. Senior individual contributors (Distinguished Engineers, Fellows) have equivalent seniority to VPs. This matters for async remote work: you do not need to manage people to have authority and influence. (Source)

Decision-Making Model

GitLab uses a DRI (Directly Responsible Individual) model — every project, decision, and initiative has a single accountable person. This prevents the “everyone is responsible, no one is responsible” diffusion that async companies frequently suffer.

Decisions are made in writing. A proposal goes into a GitLab issue or merge request. People comment. The DRI makes the call and documents it. The thread remains permanently visible.

Handbook-first culture: when a decision is made, it goes into the handbook. The handbook is the single source of truth. “If it’s not in the handbook, it doesn’t exist.” This is enforced, not aspirational — the handbook covers everything from expense policies to performance management to onboarding checklists.

Management hierarchy is present — unlike Basecamp’s manager-less model, GitLab has up to eight hierarchical layers (associate through CEO/board). The hierarchy is used lightly for day-to-day work but is real for escalations, performance management, and strategic decisions.

Org Structure

• 2,500+ team members across 65+ countries (per GitLab’s published team data and Wikipedia, 2025).
• Up to eight hierarchical layers: associate/intermediate/senior → manager/staff → senior manager/principal → director/distinguished → senior director → VP/fellow → executives → CEO/board. (Source)
• Dual individual contributor and management tracks — prevents the “you have to become a manager to advance” trap.
• Publicly traded (GTLB on NASDAQ, IPO October 2021) — standard public company governance, board, investor relations obligations.
• Co-founder Sid Sijbrandij founded GitLab and built the all-remote model from the company’s origin.

Tools and Stack

(Sources, Slack handbook)

Rituals

Coffee chats. Scheduled informal 25-minute video calls between any two team members, encouraged across team and division lines. Designed specifically to replicate the informal hallway conversation that distributed companies lack. (Source)

AMAs (Ask Me Anything). Open company-wide video calls with executives or team leads where anyone can ask anything. Scheduled regularly, open to all.

Group conversations and Key Reviews. Regular cross-functional calls designed to keep people connected to broader company context, open to all employees. (Source)

Onboarding social calls. Every two weeks, the People Operations team hosts a “Ta-New-Ki” call for incoming hires before their start date, allowing them to socialize and ask questions before day one. (Source)

Contribute (annual company event). GitLab holds an annual in-person gathering called GitLab Contribute. ([Inference — based on published company history; event cadence may have shifted post-pandemic.])

What They Do Well

• The handbook is the operating system. 2,000+ pages sounds unmanageable. It works because every process owner is responsible for keeping their section current, and because it is the canonical reference for every decision. When someone asks “how do we do X?”, the answer is always “check the handbook first.”
• Results over activity is enforced, not stated. GitLab explicitly does not track hours. Managers measure output. This is a meaningful operating constraint, not a marketing line — it shapes how performance reviews work and what 1:1s focus on.
• The DRI model prevents async diffusion. When every project and decision has a single named accountable person, async discussions have a place to land. Without a DRI, async debates can circle indefinitely.
• Radical transparency with the public. The handbook is public — not just internal. This forces clarity: you cannot write a vague or self-serving policy knowing it will be read by potential employees, customers, and competitors.

Tradeoffs and Weaknesses

The handbook is 2,000 pages. That is also the problem. New employees face a document the size of a major reference work. The onboarding process takes at least two full weeks of guided self-study before team-specific work begins. The learning curve is real and acknowledged. (Source)

Loneliness in the first month is acknowledged. GitLab explicitly names this in their handbook: “The first month in a remote role can feel lonely, especially if you’re transitioning from a traditional office setting.” Coffee chats and structured social calls partially compensate; they do not fully solve it. (Source)

At 2,500 people, the eight-layer hierarchy creates real distance. The flat-feeling async tools (issues, Slack) can create false intimacy. An individual contributor and the CEO appear equally close when commenting in the same GitLab issue — but the actual organizational distance is significant. Decisions made at the VP/executive layer are invisible to most of the company until they land in the handbook.

Compliance at 65+ countries is expensive. GitLab uses Employer of Record (EOR) arrangements in many markets, which adds cost, administrative overhead, and country-specific employment constraints that colocated companies never face. (Source)

What Founders Can Copy

GitLab’s operating model was designed for unbounded scale — most of these practices apply at any size, but the cost-of-starting shifts dramatically. The scale notes flag where the practice is cheapest to introduce.

1. Handbook-first culture. Every decision goes in the handbook. Not just policies — all important operating decisions. Make it public if you can; external accountability improves the quality of what you write. (Cheapest to start at 5–25 people, when the surface area is small enough to write in a week. Possible at 200; agonizing if you wait until 500.)
2. DRI on every project. Name a single accountable person for every initiative. Post it publicly in the project issue. This prevents async discussions from becoming decisions nobody owns. (Applies at any scale; load-bearing above 25–30 people, the size at which “everyone is responsible” stops working.)
3. Coffee chats as structured ritual. Schedule random 1:1 coffee chats across team lines. This is not social nicety — it is infrastructure for the informal connections that drive collaboration in colocated companies. (Most useful at 30–300; below 30 people typically know each other already, above ~300 the matching gets complex without dedicated tooling.)
4. Require an agenda 24+ hours before any meeting. No agenda, no meeting. Enforcing this one norm eliminates 30–50% of the meetings that should have been documents. (Applies at any scale; cheapest to enforce as a norm below 50 people, where leadership is in the room for most meetings.)
5. Results over activity. Don’t measure hours. Measure what shipped. This requires defining what “results” means for each role — that work is hard but worth doing. (Applies at any scale; the role-by-role “results” definition is the work, and it is most actionable at 30–150 where roles are stable enough to specify.)
6. Async-first Slack usage. Explicitly tell your team: Slack is async. You are not expected to respond within minutes. Set the norm from the first week, before people default to treating it like an instant messenger. (Applies at any scale; much harder to retrofit above 50 people once urgent-Slack culture has set in.)

Where This Model Breaks

• When documentation norms break down. The whole system depends on people actually writing things in the handbook. Under pressure, documentation is the first thing cut. GitLab’s culture treats handbook-writing as real work, not overhead — most companies do not.
• When the handbook becomes a museum. Documentation that goes stale is worse than no documentation — it is actively misleading. The handbook requires ongoing stewardship. At 2,000+ pages, this is a significant ongoing cost.
• When the DRI model meets political reality. In practice, at 2,500+ people, some decisions have multiple powerful stakeholders who each believe they are the DRI. The model works in clear situations; it requires escalation paths for ambiguous ownership.
• Below 20 people. This level of process infrastructure is overkill for a 10-person startup. It makes sense when the alternative is 2,500 people asking the same questions independently.

Related Practices

• Async Communication — the foundation of GitLab’s operating model
• Documentation Systems — the handbook is the canonical example
• Decision Ownership — the DRI model in practice
• Remote Onboarding — GitLab’s two-week structured remote onboarding

Related Frameworks

• 20-30 Person Fracture Point — the process infrastructure GitLab uses was built early
• Sync vs Async Decision Matrix — GitLab has explicit guidance on when to use which

Sources

1. GitLab’s Guide to All-Remote: https://handbook.gitlab.com/handbook/company/culture/all-remote/guide
2. GitLab Communication Handbook: https://handbook.gitlab.com/handbook/communication
3. How to Embrace Async Communication: https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous
4. Complete Guide to Remote Onboarding: https://handbook.gitlab.com/handbook/company/culture/all-remote/onboarding
5. All-Remote Drawbacks: https://handbook.gitlab.com/handbook/company/culture/all-remote/drawbacks
6. GitLab Cadence: https://handbook.gitlab.com/handbook/company/cadence/
7. GitLab Org Structure: https://handbook.gitlab.com/handbook/company/structure

Inferences

• The public handbook is a self-reinforcing system. Because it is publicly readable, GitLab must write clearly for external audiences — not just internal ones. This external accountability produces better documentation than internal wikis produce, because internal wikis allow sloppy writing that “everyone” understands in context. The public constraint is load-bearing.
• The coffee chat ritual is not optional at GitLab’s scale. At 2,500 people distributed across 65+ countries, the natural probability of any two team members ever interacting drops dramatically. The coffee chat program is an engineered substitute for hallway serendipity. Without it — or something structurally similar — a 2,500-person remote company stratifies into isolated subgroups.
• The eight-layer hierarchy and the “results over activity” value are in natural tension. Results measurement works best when the work is discrete and observable. Management layers exist partly to deal with ambiguity about what “results” means. GitLab resolves this with OKRs — but OKRs only defer the tension, not eliminate it.

Work with Alex

If your company is trying to build the process infrastructure to support a growing distributed team — and you want to do it without creating a 2,000-page handbook overnight — Alex helps leadership teams design the operating system proportional to their stage.