Team, Co-founders & Legal

How do I write my first company handbook without it becoming dead documentation nobody reads?

A starting point

Write it as decisions and defaults, not policies. One living doc that answers 'how do we do X here' (leave, expenses, tools, how we make decisions, how we give feedback) beats a 40-page PDF. Keep it in the tool your team already lives in, link it in onboarding, and make updating it part of shipping any new process. If a section has not been touched or referenced in 90 days, it is probably wrong or dead, so cut it.

Go deeper

Hand-picked from around the web, each with a note on why it earns your time.

3 resources 3 link-checked Read Use

Read

📄 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 →
📄 Article
✓ Link checked Free Beginner

Why we picked it This is the 'why does nobody read our handbook' guide, and it names the real failure mode: fewer than 1 in 20 docs get updated monthly, so teams quietly drift back to Slack and the doc dies. Its fixes map directly onto your answer: assign a named owner per section, embed an 'answer with a link' habit so the doc becomes the reflex, keep it inside the tools the team already lives in (Slack, Linear, GitHub) instead of a new platform, and use staleness signals to cut dead sections, which is your 90-day rule made concrete.

Internal Documentation: How to Build Docs Your Team Actually Reads

From Slite by Slite 15 min read

  • Every section needs a named owner, or it rots: undeniable ownership beats better writing
  • Keep docs where work already happens and answer questions with a link, so maintaining the doc is part of daily work, not a side project
  • Surface and cut stale content on a cadence, since an untouched section is almost always wrong or dead
Open slite.com →

Use

📋 Template
✓ Link checked Free Beginner

Why we picked it This is the lean counterweight to GitLab: a real, Creative-Commons handbook you can fork today, written as short human sections (Getting Started, How We Work, Making a Career, Our Rituals, Benefits) instead of a 40-page policy PDF. 37signals deliberately ran with no handbook for over 10 years and only wrote one when new hires felt lost past ~50 people, so it captures exactly the decisions-and-defaults tone you want. Copy the section list, delete what does not apply to a 5-person Indian team, and add your India specifics (leave policy against actual holidays, PF/ESI once you cross thresholds, notice period).

The 37signals (Basecamp) Employee Handbook

From GitHub (basecamp/handbook) by 37signals 30 min read

  • A handbook can be short, human, and voice-driven rather than a legalistic policy document, and still cover the essentials
  • 'How We Work' plus 'Our Rituals' are the sections that actually get read: how decisions and feedback happen, not HR boilerplate
  • It is Creative Commons and forkable, so you start from a working structure instead of a blank page, then localise for Indian statutory bits
Open github.com →

People also ask

How do I build company culture intentionally from day one? Culture is what you do repeatedly and reward, not a poster of values, so your own behaviour and your first hires set it whether you're deliberate o... Intermediate 3 resources → Should my startup be remote, hybrid, or in-office? Remote works and widens your talent pool massively, 37signals has run a calm, remote-first company for two decades, but it demands strong async wri... Intermediate 2 resources → How do I run a remote team without endless meetings and burnout? Default to async: write things down, replace status meetings with written updates, and protect long stretches of uninterrupted focus, real work hap... Intermediate 3 resources → What operating cadence and rituals should an early team have? Keep it lean: a short weekly written update, clear owners for every project, and one focused planning rhythm (weekly or bi-weekly) is enough at fir... Beginner 3 resources → How do I avoid burning out my small team while still moving fast? Reject the 'crazy at work' hustle myth, sustained output comes from calm, focus, and reasonable hours, not heroics and permanent crunch. Protect pe... Intermediate 3 resources → How do we preserve culture and values as we grow past the first team? Codify your values into concrete hiring, feedback, and promotion decisions, culture scales through who you reward and who you let go, not through s... Advanced 3 resources →