Remote-First Org Design
Async-First Principles
The foundation of a remote-first org is async communication. This means decisions and context live in writing, not in hallway conversations or Zoom calls that only some people attend.
In practice, async-first looks like this: engineers write RFCs for technical decisions and share them for async comment before any meeting. Project status updates happen in written form (weekly updates in Notion, Linear project updates, or a shared doc). Decisions are recorded with context, alternatives considered, and rationale, so that someone in a different time zone can understand the "why" without having been in the room.
Slack is for coordination and quick questions, not for decisions. Any decision made in Slack should be logged somewhere persistent. Channels should have clear purposes and naming conventions.
How the Best Remote Orgs Do It
GitLab (2,000+ employees, fully remote since founding) documents everything in their public handbook. Every process, every policy, every cultural norm. New hires read the handbook. Disagreements get resolved by proposing merge requests to the handbook.
Automattic (WordPress.com, 1,900+ employees across 90+ countries) runs almost entirely on text-based communication through internal blogs and P2 (their async communication tool). They do company-wide meetups once a year and team meetups 1-2 times a year.
Zapier (800+ employees, fully remote) publishes their internal processes publicly, uses Friday updates for async standup, and gives every employee a $50/month coworking stipend.
Office Hours Over Meetings
Replace standing meetings with office hours wherever possible. An engineering manager holds 2-3 open office hours per week. Anyone can drop in with questions, concerns, or just to chat. This scales better than 1:1s for cross-team communication and avoids the "meeting that could have been a message" problem.
For essential synchronous meetings, keep them short (25 or 50 minutes, not 30 or 60), always have an agenda, and post notes within 24 hours for anyone who couldn't attend.
Remote Onboarding
The first 90 days make or break a remote hire. Structure it clearly. Week 1 is environment setup, access provisioning, and meeting the team. Weeks 2-4 focus on small, well-scoped tasks with a buddy available for questions. Months 2-3 ramp up to full-sized work. Check in frequently. Remote engineers won't raise their hand when they're stuck the way office engineers might. Ask directly, regularly, and without judgment.
Key Points
- •Remote-first is not the same as remote-friendly. Remote-first means every process, meeting, and decision is designed for distributed participants by default. If your office employees have an information advantage over remote ones, you're remote-friendly at best
- •Async-first communication requires investing heavily in written documentation. RFCs, decision logs, and project updates should be written, not spoken. GitLab's handbook (2,000+ pages, publicly available) is the gold standard for this
- •Time zone band strategies group engineers into overlapping windows (Americas, EMEA, APAC) with 3-4 hours of daily overlap for synchronous collaboration. Trying to have everyone overlap with everyone creates meetings at terrible hours for somebody
- •Onboarding remote engineers takes deliberate structure. A 30-60-90 day plan, an assigned onboarding buddy, recorded walkthroughs of key systems, and weekly check-ins with their manager are all non-negotiable
- •Meeting-free days (Automattic uses them, Shopify has 'No Meeting Wednesdays') protect deep work time. Two consecutive meeting-free days per week is even better for flow state
Common Mistakes
- ✗Defaulting to video calls for everything. If it can be a Loom recording, a Notion doc, or a Slack thread, it should be. Meetings should be reserved for decisions that require real-time discussion
- ✗Measuring productivity by online status or hours logged instead of output. Surveillance tools like keystroke loggers destroy trust and push your best engineers to leave
- ✗Assuming remote engineers will figure out the culture on their own. Without deliberate social infrastructure (virtual coffee chats, team offsites, interest-based Slack channels), remote teams become isolated individuals who happen to share a Jira board
- ✗Keeping all-hands meetings at a time that only works for headquarters. Rotate meeting times or run multiple sessions to give every time zone a fair shot