How They Do ItBETA

COMPANY PLAYBOOK

GitLab

GitLab treats distributed work not as a perk, but as an operating system built on transparency, written decisions and small iterations.
Operating system
  1. Handbook-first knowledge
  2. asynchronous contribution
  3. explicit ownership
  4. small valuable change
  5. rapid feedback.

System principles

  • Keep the single source of truth in a living handbook.
  • Evaluate customer outcomes, not activity.
  • Break large solutions into small valuable changes.

Tensions and trade-offs

  • Openness lowers the contribution barrier, but documentation requires continuous maintenance.
  • Small iterations create speed, but can produce fragmented experiences and local optimization.

PRACTICES

How GitLab builds its operating system

01
Documentation

Handbook-first work

A living handbook is used as the single source of truth for processes and decisions.

How it works
Decisions, processes and role definitions live in handbook pages and changes are discussed through merge-request-like workflows.
Why it is used
Creates time-zone-independent access and organizational memory.
Trade-off
Unwritten knowledge becomes invisible; without clear ownership the handbook decays quickly.
Best fit
Distributed, scaling teams that repeatedly transfer decision context.
Open original source ↗
02
Async

Asynchronous communication

Written communication and durable records precede synchronous discussion.

How it works
Written, open channels come first; synchronous discussion is reserved for ambiguity or relationship needs.
Why it is used
Protects equal access to information and focused work blocks.
Trade-off
Risks slow feedback and weaker social connection; escalation channels must be designed separately.
Best fit
Teams spanning time zones with strong documentation discipline.
Open original source ↗
03
Performance

Impact over activity

Results and customer impact are evaluated instead of hours worked.

How it works
Performance is read through role outcomes and customer impact rather than hours worked.
Why it is used
Reduces visibility bias in remote work.
Trade-off
Poor outcome metrics can undervalue invisible work and team contribution.
Best fit
Roles with explicit outcomes and accountability.
Open original source ↗
04
Management

Manager of one

Team members are expected to own outcomes without daily supervision.

How it works
Individuals own priorities and daily progress without waiting for constant managerial instruction.
Why it is used
Reduces decision latency and micromanagement in distributed teams.
Trade-off
Without context autonomy becomes drift; the bar for capability and onboarding rises.
Best fit
Teams with high autonomy, explicit goals and strong written context.
Open original source ↗

Primary sources

GitLab HandbookGitLab ValuesAll-Remote Guide