Everything from

The GitLab Handbook

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

📄 Article
✓ Link checked Free Beginner

Why we picked it This is the operating manual behind the answer's core rule: don't run a remote team on vibes. GitLab runs 1,600+ people across 60+ countries entirely on written, handbook-first, async-default communication, and this page hands you the exact norms to copy from your first hire: document the decision not just the outcome, put questions in a public channel instead of a DM, and treat working-hours overlap and response time as explicit agreements. It is the rare playbook written by a company that actually lives it at scale, so you can lift the practices wholesale into a three-person team.

Asynchronous communication for remote work

From The GitLab Handbook by GitLab 25 min read

  • Async-by-default means the source of truth is written down, so a teammate in another city can act without waiting for you to be online
  • Broadcast important decisions in multiple places (channel, email, meeting) because you cannot assume everyone saw the one message
  • Set response-time expectations and working-hours overlap explicitly instead of letting them form by accident
Open handbook.gitlab.com
📄 Article
✓ Link checked Free Intermediate

Why we picked it GitLab runs 2,000+ people across 60+ countries with zero headquarters, so their handbook is the closest thing to a field manual for exactly your problem: how do you stop the office from quietly becoming the center. It is concrete on the habits that actually fix two-tier culture, defaulting to written decisions, making meetings optional with a shared agenda so nobody 'finds out later', and designing for async instead of replicating an in-room experience. Read the 'what not to do' and meeting sections first, then copy the handbook-first pattern for a team split across Indore, Kochi, and a metro.

GitLab's Guide to All-Remote

From The GitLab Handbook by GitLab 45 min read

  • Public-by-default written decisions are the single lever that keeps a remote colleague equal to someone in the room
  • Meetings are optional and default to a shared doc, so the decision lives in text and nobody is 'told later'
  • Do not replicate the office remotely; design the process for distributed work from the start or the metro office wins by default
Open handbook.gitlab.com
📄 Article
✓ Link checked Free Intermediate

Why we picked it This is the piece specifically about people whose working hours barely overlap, which is your exact problem. It shows how to hand off work across the clock so progress continues around the day instead of stalling every time your window closes. You get practical norms for response times, handoffs, and not expecting instant replies from someone eight hours ahead.

The complete guide to asynchronous and non-linear working

From The GitLab Handbook by GitLab Long reference page

  • Design handoffs so work continues around the clock
  • Set clear response-time expectations, not instant ones
  • Non-overlapping hours are a feature if the writing is good
Open handbook.gitlab.com
📋 Template
✓ Link checked Free Intermediate

Why we picked it A concrete, copyable pattern for the written weekly update that replaces the status meeting, straight from a team that lives by it. It shows what a useful update contains so you get progress and blockers, not vague activity. Adapt this format for your own team so their written check-in is something you can actually read and act on across the time gap.

Weekly Async Updates

From The GitLab Handbook by GitLab Short reference page

  • A weekly written update can replace the status call
  • State progress and blockers, not just activity
  • A shared format makes updates fast to write and read
Open handbook.gitlab.com
eChai Partner Brands