THE BUSINESS IN ONE SYSTEM
GitLab’s lack of offices is the most visible part of its operating model and the least useful explanation for how it works. A distributed company can still depend on meetings, private messages, and people who remember why a decision was made. GitLab built a different coordination system: write the process down, make the record easy to change, and treat the handbook as operational infrastructure.
That choice affects more than employee location. It determines how work crosses time zones, how a new colleague learns, how a decision is reviewed, and how the product team experiences the workflow problems it asks customers to solve.
Thesis: GitLab replaces proximity with a shared written record; asynchronous contribution keeps that record current, and the resulting operating discipline reinforces its product strategy.
SYSTEM MAP
How written work keeps moving across time zones
Distributed work → written process → searchable decisions → asynchronous execution → broader contribution → better documentation → less dependence on proximity
The loop needs active maintenance. Documentation that no one owns becomes stale. Asynchronous work without clear decisions becomes delay. GitLab’s advantage comes from combining the two: the written record is expected to change through a contribution workflow.
SYSTEM BREAKDOWN
MECHANISM 01
A handbook moves knowledge out of the room
In an office, people can resolve uncertainty by turning to a colleague. The answer may be fast, but it remains trapped in the conversation. The next employee asks again, and the organization pays repeatedly for the same explanation.
A canonical handbook changes the default destination. The process, owner, and rationale become discoverable without requiring the original participant to be online. GitLab describes its handbook as a single source of truth and exposes much of it publicly.
Public access increases the discipline. Contradictions are visible. Candidates can inspect the operating model before joining. Customers can see how the company approaches security, management, and remote work. Transparency creates reputational risk, but it also makes vague values harder to maintain.
MECHANISM 02
Asynchronous work separates response time from progress
A team spread across time zones cannot require everyone to be present for each decision. Written proposals, issues, and merge requests let one person advance the work while another sleeps. The record carries context across the handoff.
GitLab’s own account of remote red-team operations describes the public handbook as the source of truth and emphasizes asynchronous collaboration across time zones. The security example is instructive because ambiguity has consequences. A useful record must specify scope, process, ownership, and escalation conditions.
Asynchronous does not mean slow or meeting-free. A live conversation can resolve a sensitive or complex disagreement quickly. The operating rule is to capture the outcome afterward so the organization retains the decision rather than only the memory of participants.
MECHANISM 03
Contribution keeps the source of truth alive
A static policy library accumulates decay. The person who discovers an outdated instruction may work around it instead of repairing it. GitLab borrows a behavior from software development: propose a change, show the difference, review it, and merge the improved version.
This lowers the distance between user and maintainer. Employees closest to the work can surface a problem and leave a visible proposal. Review provides governance without requiring every change to originate from a central operations team.
The mechanism also exposes disagreement. A proposed edit turns an abstract complaint into specific language that others can accept, revise, or reject. The organization can debate the actual operating rule rather than exchange impressions about it.
MECHANISM 04
The operating model mirrors the product
GitLab’s product organizes planning, source code, review, testing, security, and deployment around shared artifacts. Its company operates through related habits: written issues, visible changes, review, ownership, and a traceable history.
That alignment gives employees direct experience with the coordination problem the product addresses. A distributed team feels the cost of fragmented context immediately. Product requirements emerge from daily work rather than from an abstract description of remote collaboration.
The feedback loop is valuable because internal scale becomes a test environment. A feature that helps colleagues review work across time zones may help customers coordinating software delivery. Internal use sharpens the problem definition; customer behavior still determines external demand.
MECHANISM 05
Documentation changes onboarding economics
New employees usually consume the time of experienced colleagues. Some interaction is necessary, especially for judgment and relationships. A strong written system removes repeated factual transfer from those conversations.
The new colleague can learn terminology, process, and decision history independently, then use live time for exceptions and interpretation. Experienced employees spend less time rebuilding context. The savings compound as the organization grows because the same artifact serves many readers.
The model also reveals gaps quickly. If onboarding repeatedly requires a verbal explanation, the handbook is missing something, the process is unclear, or the written rule does not match actual work. The question becomes a diagnostic signal.
DEFENSIBILITY
Why established companies struggle to copy it
The software is easy to imitate. A company can install a wiki and declare an asynchronous policy in a week. The difficult part is changing how authority and status work.
In a meeting-driven organization, early access to information creates influence. Decisions may depend on relationships and private context. Moving the record into public, editable artifacts redistributes that influence and makes prior ambiguity visible. People who benefited from the old system may resist even when documentation improves throughput.
There is also migration cost. Teams must write while continuing to deliver. During the transition, meetings remain necessary because the documentation is incomplete, while documentation feels unnecessary because meetings still exist. GitLab avoided much of this conversion problem by developing the habits alongside the company.
FAILURE MODES
Where the system can break
The handbook grows faster than retrieval. More pages can increase ambiguity when search, navigation, and ownership are weak. A source of truth must make the current rule easier to find than an outdated one.
Writing becomes a substitute for judgment. Some decisions depend on tacit knowledge, emotion, or rapid negotiation. Forcing every interaction into a document can hide conflict rather than resolve it.
Transparency ignores legitimate boundaries. Security, personal data, legal privilege, and confidential strategy require controlled access. The useful principle is visible by default with explicit exceptions, not universal publication.
OPERATOR RULE
Make knowledge travel without its author
Every repeated question should improve the system that produced it. Answer the immediate need, then update the artifact, owner, or decision rule so the next person can proceed independently.
Test the documentation when an owner is offline. A colleague should be able to find the current rule, its rationale, and the path for changing it. Any missing step identifies the next artifact to repair.