Everything from

GitLab Handbook

2 resources from GitLab Handbook we point founders to, and the questions each answers.

📄 Article
✓ Link checked Free Intermediate

Why we picked it GitLab runs a fully remote company on exactly the rule your answer prescribes: every area has one named owner who holds the final say, and everyone else can weigh in but does not co-decide. It is the most operational, copy-able playbook for one clear owner per domain, written by a company that lives or dies by it. Steal the mechanic wholesale: assign the domain, name the person, and let disagreement escalate cleanly instead of stalling.

Directly Responsible Individuals (DRI)

From GitLab Handbook by GitLab 15 min read

  • A DRI is one named person with final say in their area, which kills the 'who decides?' ambiguity that slows two founders down
  • Input is welcome and disagreement is encouraged, but the DRI makes the call and the team commits
  • Split ownership so decisions never have two owners: overlap, not disagreement, is what actually causes the deadlock
Open handbook.gitlab.com →
Answers How do we divide roles and decision-making so we don't step on each other?
📄 Article
✓ Link checked Free Intermediate

Why we picked it This is the reference implementation of your thesis: the handbook IS the process, not a description of it. GitLab's rule that any change (policy, process, decision) gets written into the handbook before it is communicated is exactly your 'updating it is part of shipping any new process' point, made operational by a company that runs on it. Do not copy its 2000+ pages: read the handbook-first page for the discipline, then steal only its table-of-contents structure (how we work, decisions, comp, tools) as a skeleton for your one living doc.

The GitLab Handbook (and the Handbook-First Approach)

From GitLab Handbook by GitLab browse 30 min

  • Write the change into the doc first, then communicate it, so the handbook is the single source of truth instead of a stale summary of Slack decisions
  • Structure by 'how do we do X here' sections (comms, decisions, comp, tooling), which is a ready-made outline for your first handbook
  • The 2000+ page scale is a warning, not a target: an early-stage team wants one lean living doc, not GitLab's full surface area
Open handbook.gitlab.com →
Answers How do I write my first company handbook without it becoming dead documentation nobody reads?