Team, Co-founders & Legal

How do I keep a distributed team genuinely async so people in different time zones and cities are not always waiting on me?

A starting point

Make writing the default and meetings the exception. Every decision, spec, and update gets written down where anyone can find it, so nobody is blocked waiting for you to be awake or online. Set clear response-time norms (reply within a day, not a minute), protect deep-work blocks, and reserve live time for the few things that truly need it (hard debates, sensitive feedback). If your team cannot make progress while you sleep, you have a documentation problem, not a talent problem.

Go deeper

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

3 resources 3 link-checked

Read

📄 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 Beginner

Why we picked it Doist runs a 100+ person team across every time zone with 80-90% of communication written, and this piece is their playbook stated plainly. It hands you the two norms your answer calls for: a concrete response-time rule (they expect replies within 24 hours, not 24 seconds) and a clear meeting-vs-thread decision (live only for sensitive feedback, brainstorming with real unknowns, and crises; everything else is written). It even scripts how to decline unnecessary meetings and how to judge people on output instead of how fast they answer Slack.

Asynchronous Communication: The Real Reason Why Remote Workers Are More Productive

From Doist / Twist by Doist 18 min read

  • Set an explicit response window (Doist uses 24 hours) so nobody feels they must watch notifications, which is what lets a person in another city work without waiting on you.
  • Judge output, not responsiveness: measuring people by reply speed quietly rebuilds the always-on culture you are trying to kill.
  • Use the Direct Responsible Individual model so written decisions have one clear owner and threads resolve instead of drifting.
Open async.twist.com
✍️ Essay
✓ Link checked Free Intermediate

Why we picked it Newport diagnoses exactly why distributed teams end up always waiting on the founder: the hyperactive hive mind of ad hoc Slack pings has no structure, so every decision routes back through one busy person. He cites a University of Chicago study where remote workers added 30% more hours for flat output, and argues the fix is not more meetings but protocol-driven collaboration (shared task boards, defined workflows) that protects deep work. Read this to decide what genuinely deserves a live meeting versus a written thread, and why unstructured messaging quietly becomes the bottleneck.

On Productivity and Remote Work

From calnewport.com by Cal Newport 12 min read

  • Unstructured ad hoc messaging is the bottleneck: without a defined protocol, every question routes back to you and decisions drag.
  • Remote work does not lower productivity; keeping broken, meeting-and-ping-heavy collaboration habits does.
  • Replace the hive mind with structured workflows (task boards, Kanban, clear protocols) so work moves on rails instead of through your inbox.
Open calnewport.com

People also ask