Snapshot
GitLab reported approximately 2,580 team members in 60 countries as of January 31, 2026. It operates all-remote and trades on Nasdaq as GTLB. (2026 Form 10-K) A later board-approved restructuring plan is described in Org Structure; it is not a completed headcount. Its company history records an October 2021 IPO. (Company history)
Their defining operational choice: when in doubt, document it. The GitLab Handbook spans thousands of publicly available web pages of 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 starting point. GitLab’s communication handbook also identifies work that benefits from synchronous discussion: strategy changes, unresolved disagreements, trust-building, and problems whose context is difficult to express in writing. Its three-exchange guideline remains a trigger for moving a stalled discussion to video. (Communication guidance, video-call guidance)
Communication standards are published. GitLab’s current guide says to begin asynchronously, use public issues, merge requests, and Slack channels where practical, document the conclusions of offline conversations, and assume positive intent. (Source)
AI does not transfer authorship responsibility. The communication handbook asks authors to read, understand, refine, and verify AI-assisted material before sharing it or requesting review. It calls for concise broadcasts, approved tools for sensitive content, and human judgment in feedback and customer communication. Mentioning AI use must not serve as a disclaimer for errors. These are current written expectations, not measured evidence of how consistently they are followed. (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:
- Meeting DRIs should prepare one shared agenda at least 72 hours in advance; informal coffee chats are exempt
- 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’s published cadence spans week, month, quarter, year, three years, ten years, and thirty years, with adjacent horizons roughly three to five times apart. These are time horizons, not a claim that every team uses the same planning meeting or release schedule. (Source)
A scoped Create Stage OKR example remains publicly readable. The page describes quarterly objectives recorded in epics and issues, with monthly scoring. Its October 28, 2026 modification marker says an outdated OKR page was deleted; the underlying change could not be verified in this review. Treat this as a documented example whose current maintenance status is uncertain, rather than a verified current company-wide process. (Source)
Some DevOps teams publish their productivity definitions. Guidance checked November 1, 2026 names Plan:Planning Views, Plan:Portfolio Planning, and Create:Source Code Hardening and Modernization as tracking team-aggregate MR rate, review balance, median time to merge, and open MRs. It uses trailing 28-day windows and shows no individual data. MR/review counts account for time off; time-to-merge and open-MR measures do not. Bot reviews are excluded from review balance. The listed bands are targets, not published achieved results or evidence of an AI effect. (Source)
Dual career paths support advancement without people management. GitLab’s published layers pair Distinguished with Director and Fellow with VP. The dual path is most developed in Engineering; other functions adopt it where their structure and business needs permit. (Source)
Decision-Making Model
GitLab’s DRI (Directly Responsible Individual) model assigns accountability for a defined outcome. Its guidance allows additional approvals or a separate decision-maker in some circumstances; naming a DRI does not remove those boundaries. (DRI guidance)
Written context accompanies decisions. GitLab encourages proposals in merge requests and requires conclusions from offline conversations to be recorded. Its channel guidance also distinguishes the public Handbook from The Loop, Slack, email, and meetings. These are published expectations, not proof that every decision is public or every policy is followed. (Communication guidance)
Management hierarchy is present. The published structure describes up to eight layers and uses Workday as the current organization chart. This differs from 37signals’ stated choice not to employ full-time people managers; it does not establish a company without management. (GitLab structure, 37signals)
Org Structure
- Approximately 2,580 team members in 60 countries as of January 31, 2026. (Source)
- 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 co-founded GitLab with Dmitriy Zaporozhets (Source); the all-remote model developed under his leadership. [Inference — GitLab’s published history does not pin the all-remote model to a single origin moment, so “from the company’s origin” is not directly sourced.]
- A June 2026 restructuring plan is not a new headcount. A Form 8-K for a June 1, 2026 board approval says approximately 14% of the January 31 workforce could be affected, and that GitLab expected to exit 22 countries, reducing its geographic footprint by approximately 37%, with substantial completion expected by January 31, 2027. The CEO’s May letter said the operational changes and the AI strategy were related but independent, and that the restructure was not an AI cost-cutting exercise. Subtracting the plan from the January snapshot would invent a current total. (8-K, Act 2 letter)
Tools and Stack
| Tool | Purpose |
|---|---|
| GitLab (issues, MRs, projects) | All project work, decisions, code review |
| Slack | Async-first chat, supplementary to issues |
| Google Docs | Collaborative documentation |
| Zoom | Video calls |
| Published Create Stage OKR example | Quarterly objectives and monthly scoring in a public page whose current maintenance status is uncertain |
| GitLab Handbook (public website) | Operating manual, single source of truth |
Rituals
Coffee chats. The informal-communication guide encourages conversations across roles and regions, and describes 25 minutes as a common duration. That is guidance rather than a mandatory duration or participation rate. (Source)
Optional AMAs. The communication guide permits a company-wide Zoom AMA when appropriate for an announcement, while noting that issue or merge-request discussions can also handle questions. This does not establish a fixed company-wide AMA schedule. (Source)
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)
GitLab Summit. GitLab’s handbook describes an all-company gathering, previously sometimes called Contribute. Its public history records more than 1,800 attendees in Las Vegas in March 2024. The cited pages do not establish a current annual schedule. (Summit, event history)
AI
GitLab publishes an internal operating model for AI. The numbers below are activity, training feedback, or announced plans. They are not a productivity result.
Ownership is split between a platform hub and each function. Enterprise AI, inside Enterprise Technology and AI under the CIO, owns platforms, standards, and the single interface to corporate security, legal, and privacy. Each function has an AI Transformation Owner who sets what to work on and in what order. Champions inside the function experiment and support peers. The operating-rhythm page gives champions 5–10% of their time with a manager’s agreement, and describes daily work as async-first, with a weekly ATO Council, fortnightly office hours, and quarterly reviews of adoption, value, dependencies, and resources. That is the intended model, not an audit that every function complies. (Enterprise AI, operating rhythm, ATO role)
Security’s plan makes one function’s responsibilities concrete. Its program plan, last modified October 20, 2026, assigns the ATO accountability for Security’s roadmap, Enterprise AI the platform, and up to ten champions a role in priorities and outcomes without making them ATO reports. A coordinator compiles weekly updates; the plan includes monthly division summaries and quarterly review. All milestone dates are proposed, including office hours from the week of November 2. Business-metric targets and the definition of toil remain to be agreed. This describes planned governance, not a completed rollout or demonstrated savings. (Source)
Sharing a canonical agent has an ownership gate. GitLab’s platform-mapping guidance permits personal experimentation but requires ownership and review before promotion to canonical shared process. The ATO approves function-level work; the hub approves company-wide work. Repository skills use CODEOWNERS, version history, and merge requests. The guidance distinguishes technical controls from ownership: Claude’s function boundary depends on the owner, while Glean supports department/group scoping. It also lists tenant settings still to confirm. This documents the intended governance posture, not proof that every configured boundary is enforced. (Source)
The named internal tools are GitLab, Glean, Claude, and Relevance.ai. The charter says the company leads with GitLab and Duo Agent Platform where they fit, and also operates Glean for knowledge and personal automation, Claude for desktop work, and Relevance.ai for company-wide agents. Listing a tool is not a usage rate. (Source)
Fluency is taught by role. On September 2, 2026, the CIO and Chief People Officer described an AI Literacy Ladder that recommends a path from a self-assessment, including a dedicated engineering path. All-company lessons set a baseline; function sessions follow. Among engineering-workshop attendees, 87% said they learned something they could apply immediately, and more than 87% of participating engineers said they were likely to apply what they learned in the next two weeks. In a separate set of non-technical workshops, 95% said they were likely to apply something within two weeks, and 92% reported increased confidence with the workshop’s tool. A month after AI Ladders launched, daily interactions with the primary internal coding tool rose 22.3%. The post does not name that tool, the sample, or a comparison group. The interaction figure is use, not a 22.3% productivity gain. (Source)
Daily use is an expectation; the restructuring is a separate plan. The May 11, 2026 staff letter says GitLab expects daily AI use by every individual and is launching acceleration programs for every role. It also says agents should take work they can do, and that the company is rewiring reviews, approvals, and handoffs with agents. The same letter says the restructure is not an AI cost-cutting exercise, and that the operational changes and the strategy are related but independent. The workforce and country figures for that plan are in Org Structure. (Source)
What They Do Well
[Inference — interpretation of the documented mechanisms, not measured effects.]
- Shared operating context. The public handbook and written-record expectations give colleagues a place to look for documented procedures. They do not establish that every process is current.
- Results as a stated priority. GitLab’s remote manifesto favors impact over activity. Assessing its implementation would require evidence beyond the policy.
- Named accountability. A DRI gives an initiative a defined owner while leaving approval and escalation boundaries explicit.
- Public documentation. External readers can inspect the documented operating model; the sources here do not show that public documents are more accurate than internal ones.
(Remote guide, communication, DRI guidance)
Tradeoffs and Weaknesses
Onboarding has a substantial learning period. GitLab recommends at least two full weeks for general onboarding, followed by team-specific onboarding and training in week three. New hires are encouraged to participate in their team’s work during the first two weeks without pressure to contribute heavily. This is written onboarding guidance, not a rule barring early team work. (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)
Management layers still matter. [Inference — organizational interpretation.] Shared issues and chat can make senior leaders feel accessible while their decision authority remains different. Written proposals need clear ownership and escalation paths; tool visibility does not itself flatten an organization.
Operating across countries creates compliance obligations. GitLab’s filing describes direct employment, Professional Employer Organizations acting as Employers of Record, and independent contractors. (Source) [Inference — supporting several engagement models adds administrative complexity; the source does not quantify that cost.]
What Founders Can Copy
[Inference — application ideas from GitLab’s published mechanisms. The sources do not establish universal headcount thresholds or measured effects for these recommendations.]
- Start with the operating decisions people repeatedly need. Give each record an owner and a place to update it; extend the handbook as the work requires.
- Name an accountable owner. Record the outcome, decision authority, required approvals, and escalation route together.
- Design informal contact. Use optional coffee chats where colleagues need relationships beyond their immediate team.
- Prepare a shared agenda before a work meeting. GitLab’s published example uses 72 hours and exempts informal coffee chats.
- Define role-specific results. A principle favoring outcomes still needs an explicit agreement about what useful work looks like.
- State response expectations. Document when a message can wait and how urgent work should escalate.
(Communication, meeting guidance, DRI guidance)
Where This Model Breaks
[Inference — implementation risks, not measured failure rates.]
- When records are missing or stale. Colleagues may act on incomplete context; designate who checks and updates each operating record.
- When ownership is ambiguous. A named DRI still needs an escalation path when stakeholders disagree about authority.
- When process exceeds the need. A small team can begin with concise decisions and named owners, then extend its documentation as recurring needs become visible.
(Communication guidance, DRI guidance)
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
Additional direct references for this review:
- https://basecamp.com/handbook/how-we-work
- https://handbook.gitlab.com/handbook/communication/
- https://handbook.gitlab.com/handbook/communication/#video-calls
- https://handbook.gitlab.com/handbook/company/culture/all-remote/guide/
- https://handbook.gitlab.com/handbook/company/culture/all-remote/meetings/
- https://handbook.gitlab.com/handbook/company/structure/
Other retained links below include historical/background context; dated accounts do not establish a current universal policy.
- GitLab’s Guide to All-Remote: https://handbook.gitlab.com/handbook/company/culture/all-remote/guide
- GitLab Communication Handbook: https://handbook.gitlab.com/handbook/communication
- Asynchronous Communication and Synchronous Decisions: https://handbook.gitlab.com/handbook/communication/#asynchronous-communication
- Complete Guide to Remote Onboarding: https://handbook.gitlab.com/handbook/company/culture/all-remote/onboarding
- All-Remote Drawbacks: https://handbook.gitlab.com/handbook/company/culture/all-remote/drawbacks
- GitLab Cadence: https://handbook.gitlab.com/handbook/company/cadence/
- GitLab Org Structure: https://handbook.gitlab.com/handbook/company/structure
- GitLab Slack Guidelines: https://handbook.gitlab.com/handbook/tools-and-tips/slack
- All-Remote Meetings: https://handbook.gitlab.com/handbook/company/culture/all-remote/meetings
- Create Stage Engineering Manager OKRs: https://handbook.gitlab.com/handbook/engineering/devops/create/engineering-managers/okrs/
- General Onboarding: https://handbook.gitlab.com/handbook/people-group/general-onboarding/
- GitLab Co-Founder Relationships: https://about.gitlab.com/blog/cofounder-relations/
- GitLab Company and History: https://about.gitlab.com/company/
- GitLab FY2026 Form 10-K (filed March 17, 2026; workforce at January 31, 2026): https://www.sec.gov/Archives/edgar/data/1653482/000162828026018731/gtlb-20260131.htm
- GitLab Summit: https://handbook.gitlab.com/handbook/company/culture/summit/
- Previous GitLab Contributes & Summits: https://handbook.gitlab.com/handbook/company/culture/summit/previous/
- GitLab’s internal playbook to foster AI-fluent technical teams (September 2, 2026): https://about.gitlab.com/blog/how-gitlab-fosters-ai-fluent-teams/
- Enterprise AI handbook: https://handbook.gitlab.com/handbook/eta/ai/
- AI operating rhythm: https://handbook.gitlab.com/handbook/eta/ai/strategy/hub-and-spoke/operating-rhythm/
- AI Transformation Owner: https://handbook.gitlab.com/handbook/eta/ai/strategy/hub-and-spoke/ato/
- GitLab Act 2 (May 11, 2026): https://about.gitlab.com/blog/gitlab-act-2/
- Form 8-K, restructuring plan (event June 1, 2026): https://www.sec.gov/Archives/edgar/data/1653482/000162828026039805/gtlb-20260601.htm
- Governance posture: platform mapping (undated guidance; last modified September 8, 2026): https://handbook.gitlab.com/handbook/eta/ai/strategy/prompts-are-process/platform-mapping/
- Communicating When Using Generative AI Tools (undated guidance; accessed October 16, 2026): https://handbook.gitlab.com/handbook/communication/#communicating-when-using-generative-ai-tools
GitLab DRI guidance: https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/
GitLab informal communication: https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/
How we measure team productivity (undated; last modified October 20, 2026 in a dashboard-link change; introduction date unestablished; accessed November 1, 2026): https://handbook.gitlab.com/handbook/engineering/devops/measuring-productivity/
ATO in Security program plan (undated; last modified October 20, 2026; all milestone dates proposed; accessed November 1, 2026): https://handbook.gitlab.com/handbook/security/ai/ato-program-plan/
Inferences
- A public handbook exposes operating guidance to outside scrutiny. That may encourage clearer writing, but the sources here do not compare the quality of public handbooks and private wikis.
- Structured social contact can help a company of thousands avoid isolated subgroups. GitLab’s coffee chats and documented Summits are distinct ways to create that contact. Their existence does not establish a mandatory coffee-chat policy or an annual Summit schedule.
- An async starting point works best with explicit reasons to meet. GitLab’s synchronous decision guidance and written-record discipline can reinforce each other: meet when interaction helps, then preserve the context and outcome for people who were absent.
- Results-based management still requires agreement about what outcomes matter. Create Stage’s documented OKRs provide one scoped example; they do not establish a company-wide mechanism or prove that goal-setting resolves ambiguity.
- GitLab’s AI model separates who owns the platform from who owns the function’s priorities. The 22.3% interaction increase and the workshop percentages measure activity and intention. They do not show that the hub-and-spoke structure caused better delivery, or that the June restructuring plan has already changed headcount.
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 multi-thousand-page handbook overnight — Alex helps leadership teams design the operating system proportional to their stage.