Async-First or Meeting Hell? How GitLab's 2000-Person Remote Model Challenges the 'Collaboration Tax'

General
1

I’ve been thinking a lot about GitLab lately. Not their product—their operating model.

GitLab runs one of the world’s largest all-remote companies: 1,300+ people across 60+ countries, zero offices, async-first from day one. Their employee handbook alone is 2,700 pages. That’s not documentation—that’s a philosophy.

The Collaboration Tax

Here’s the problem they’re solving: poorly structured remote teams spend 33% more time on status updates and coordination than well-structured ones (Microsoft’s 2026 Work Trend Index). That overhead is what I call the “collaboration tax”—the price you pay when you confuse activity with progress.

Most companies respond to remote work by adding more meetings. Stand-ups become check-ins. Check-ins become syncs. Syncs become all-hands. Before you know it, engineers are in 20+ hours of meetings per week, leaving the actual work for evenings and weekends.

GitLab flips this. They default to async for everything: documentation over discussion, merge requests over meetings, written updates over video calls. Live meetings exist to catalyze weeks or months of async work—not replace it.

My Own Journey

We’re scaling our engineering org from 25 to 80+ engineers, and I’ve watched this pattern play out. Early on, I thought “good communication” meant being available, responsive, in every conversation. What I learned: I was teaching my team to interrupt each other.

When I started treating documentation as a first-class deliverable—not an afterthought—something shifted. Engineers stopped waiting for me to be online. Decisions that used to take three meetings and two days now happen in a well-structured RFC with asynchronous input. Our meeting load dropped by 40%, and velocity increased.

The Real Question

Here’s what keeps me up at night: Are we confusing “collaboration” with “synchronous communication”?

GitLab’s handbook isn’t just comprehensive—it’s a forcing function. If it’s not documented, it doesn’t exist. That sounds extreme until you realize the alternative: critical knowledge locked in someone’s head, accessible only during their waking hours, in their timezone.

Async-first means:

  • Code reviews happen when reviewers have deep focus time, not when the PR author is online
  • Technical decisions get better input because people can think before responding
  • Junior engineers can learn by reading, not by hoping they’re in the right meeting
  • Parents, caregivers, and people with non-traditional schedules can contribute fully

The Uncomfortable Truth

What if the real productivity killer isn’t remote work—it’s our meeting addiction?

What if “I need to jump on a quick call” is just an excuse to avoid the harder work of thinking through a problem and writing it down clearly?

What if we’re defending synchronous collaboration not because it’s better, but because it’s familiar?

GitLab’s 1,300-person proof of concept suggests we’ve been asking the wrong question. It’s not “Can remote work at scale?” It’s “Are we willing to change how we work to make remote work work?”

I’m curious: For those of you running distributed teams, where do you draw the line between async-first and meeting when needed? And for those pushing back on remote work—what is it you’re actually trying to preserve?

Sources:

2

This resonates deeply, Keisha. I’m a big believer in async-first for heads-down engineering work. Code doesn’t care what timezone you’re in.

But I want to push back a little from the financial services trenches.

The Compliance Reality

GitLab operates in a relatively unregulated space. They can move fast, experiment, and course-correct asynchronously. In financial services, some decisions can’t be async:

  • Security incidents: When we detect suspicious activity, I need my security lead, compliance officer, and on-call engineer on a call within 15 minutes. Not in a doc thread.
  • Regulatory decisions: Our auditors want to see that critical decisions involved real-time discussion with appropriate stakeholders. An async trail of comments doesn’t always satisfy SOX requirements.
  • Crisis management: When a critical service goes down and customer money is at risk, I need synchronous coordination, not well-formatted RFCs.

But You’re Still Right

Here’s the thing: these synchronous moments work better because most of our work is async.

When we do jump on a call, everyone’s prepared. The RFC is written. The data is gathered. The trade-offs are documented. We’re not using meeting time to think—we’re using it to decide.

My team across Austin, Mumbai, and London used to spend 20 hours a week in meetings. We’re down to 8. The difference isn’t “more async tools”—it’s treating documentation as a first-class engineering deliverable, not a chore.

The Question I’m Wrestling With

How do we apply GitLab’s lessons without copying them blindly?

They’ve built an organization from scratch around async-first principles. Most of us are trying to transform existing teams with existing habits, working in industries with constraints GitLab doesn’t face.

I can’t wave a wand and create a 2,700-page handbook. But I can require RFCs for architectural decisions. I can default to async code review. I can make “write it down first” the default for my directs.

What incremental changes have actually worked for others trying to shift established teams toward async-first?

3

I love this discussion, but I’m going to be the contrarian from the design side.

Design Collaboration Feels Different

Engineering work often has clear acceptance criteria: tests pass, code compiles, requirements met. Design is messier—we’re iterating toward something we can’t fully articulate at the start.

I’ve tried async design reviews. The feedback comes in text: “Make it pop.” “The spacing feels off.” “I’ll know it when I see it.” Without real-time back-and-forth, we end up with 8 rounds of revisions instead of one 30-minute working session.

Creative collaboration thrives on energy. The back-and-forth. The “yes, and…” building. The whiteboard sketching. I haven’t found an async tool that captures that.

But Keisha’s Point Stands

Here’s what I’ve learned the hard way: async documentation forces you to articulate design decisions you’d otherwise handwave.

When I ran my startup (into the ground, by the way), our design system lived in Figma and my head. No documentation. No rationale. No “why did we choose this?” When I left for a week, everything stopped.

Async-first would have forced me to write down why we used 8px spacing increments, why we chose that color palette, why we prioritized mobile-first. The startup still would have failed, but at least the next person could have understood the design system without me.

The Hybrid Approach That Actually Works

What I do now:

  • Async for execution: Designers work in deep focus, engineers implement without waiting for me
  • Strategic sync for ideation: We do have real-time brainstorms for big features—but they’re prepared. Research shared ahead. Problem space documented. We’re not using meeting time to catch up.
  • Documentation as handoff: Every design decision gets a brief write-up. Not a novel—just enough that future-me (or future-someone-else) understands the “why.”

Luis, your point about “treating documentation as a first-class deliverable” hit hard. Design teams often treat docs as busywork. But undocumented design is technical debt in disguise—you’re just deferring the cost to whoever has to maintain or extend it later.

For the design and product folks here: how do you balance the creative energy of real-time collaboration with the clarity of async documentation?

4

The GitLab example is instructive, but I want to zoom out to what makes it actually work.

The Handbook Is the Real Innovation

Everyone fixates on “GitLab has no meetings!” That’s not the story. The story is GitLab has a 2,700-page handbook that serves as institutional memory, decision log, and operating manual.

Most companies won’t build that. Not because they can’t—because it’s hard and unglamorous work that doesn’t show up in velocity metrics.

Writing documentation is harder than talking. It requires:

  • Thinking through edge cases you’d handwave in conversation
  • Organizing information so it’s discoverable later
  • Maintaining it as systems evolve
  • Cultural buy-in that “if it’s not written down, it didn’t happen”

That’s a massive cultural investment most leadership teams aren’t willing to make.

The Hidden Cost of Async Communication

Here’s what people miss about async-first: it requires better communication skills across the board.

In a synchronous meeting, you can read the room. See confusion. Clarify in real-time. Get instant feedback that you’re being understood.

In async communication, you need to:

  • Write clearly and completely the first time
  • Anticipate questions and address them proactively
  • Structure information for different audiences (exec summary vs technical details)
  • Be comfortable with asynchronous feedback loops

These are not skills most engineers are hired for. Or trained in. Or promoted based on.

The Real Question No One Asks

Luis asked about incremental changes. Maya talked about documentation as debt. Both are right.

But here’s the question that keeps me up: Are we willing to hire and promote for async communication excellence?

If you’re serious about async-first, you need to:

  • Hire for writing ability alongside technical skills
  • Evaluate promotion cases on RFC quality, not just code output
  • Reward documentation the same way you reward shipping features
  • Train teams in async communication as rigorously as you train them in your tech stack

Most companies won’t do this. They’ll adopt Notion and Slack and Linear and declare victory. Then wonder why async “doesn’t work” for them.

What I’m Doing About It

We’re 120 engineers now, fully remote. Here’s what’s working:

  1. Mandatory RFC template for anything touching architecture
  2. Documentation sprint every quarter (yes, we dedicate time to it)
  3. Writing workshops for senior engineers (sounds soft, is critical)
  4. Promotion criteria explicitly include “influences through writing”
  5. No decisions in meetings that weren’t documented first

GitLab didn’t stumble into async-first. They architected for it from day one. The rest of us have to retrofit—and that means being honest about the cultural debt we’re carrying.

For those who’ve made async work at scale: what did you stop doing to make room for documentation time?

5

Maya, your hybrid approach resonates. Michelle, your cultural investment point is spot-on. Let me share what’s actually working for us.

The Reality of Distributed Teams

I manage 40+ engineers across Austin, Mumbai, and London. Three timezones, zero overlap during normal working hours between Austin and Mumbai.

We tried “core hours”—failed. Someone’s always up at 6am or working past 10pm. Not sustainable.

What works: 2-3 hours of flexible overlap time, not for meetings, but for unblocking.

Ownership Clarity Is Everything

Maya, you mentioned async design forcing articulation. Michelle, you talked about communication skills. Both connect to the same root problem: blocked decisions in async environments need clear DRIs (Directly Responsible Individuals).

When it’s unclear who owns a decision, async falls apart. The discussion thread grows to 47 comments. No one commits. Everyone’s waiting for someone else to decide. In a meeting, you can force resolution. In async, ambiguity is death.

What changed for us:

  • RACI matrix for every project (sounds corporate, works)
  • DRI listed in first comment of every design doc / RFC
  • 48-hour decision SLA: If you’re the DRI, you commit or escalate within 48 hours
  • Escalation path documented: If DRI is blocked, they know exactly who to ping

The Meeting Reduction That Actually Happened

We went from 20 hours/week to 8 hours/week in meetings. Here’s what we stopped doing to make room for documentation time (Michelle’s question):

We killed:

  • Daily standups (replaced with async written updates in Linear)
  • “Sync meetings” that were really status updates (now Loom videos)
  • Multi-team coordination calls (now RFC-based with async sign-off)
  • Retrospectives every sprint (now monthly, with pre-reading required)

We kept:

  • Architecture review sessions (but pre-reading mandatory)
  • Incident postmortems (too important to async)
  • 1:1s with my directs (some things need real-time relationship building)
  • Quarterly planning (strategic alignment needs conversation)

Time saved went to:

  • Writing RFCs
  • Code review with thoughtful feedback
  • Documentation sprints
  • Deep work blocks

The Metric That Changed Everything

We started tracking “time to unblock”: how long from “I’m blocked on X” to “I can proceed.”

In the meeting-heavy era: average 2.3 days (waiting for next sync).

In async-first with clear ownership: average 6 hours.

That’s the ROI of documentation + ownership clarity + async-first default.

Michelle, I’m stealing your “influences through writing” promotion criterion. That’s brilliant. How do you evaluate that in practice? Looking for RFCs authored, doc pages created, or something more nuanced?