Remote and Async Communication
Guide to effective communication in remote-first and async-first environments.
Async-First Principles
Default to Async
Before scheduling a meeting, ask: "Could this be async instead?"
| Sync (Meeting) | Async (Document/Message) |
|---|---|
| Brainstorming with immediate building | Collecting feedback over time |
| Sensitive/emotional conversations | Status updates |
| Real-time collaboration | Decisions with clear options |
| Urgent problem-solving | Non-urgent questions |
| Relationship building | Documentation and knowledge sharing |
Why Async Matters
- Time zones: Not everyone is online at once
- Deep work: Meetings fragment focus time
- Inclusion: Async gives introverts equal voice
- Documentation: Async creates artifacts for later
- Flexibility: People work when they're most productive
Channel Selection Guide
Choose the right tool for the job:
Instant Messaging (Slack, Teams)
Best for:
- Quick questions expecting same-day answers
- Informal team chat
- Time-sensitive coordination
- Celebrations and recognition
Anti-patterns:
- Long-form discussions (use docs)
- Decisions needing documentation (use PRs or docs)
- Anything requiring more than 3 back-and-forths
Documents (Notion, Google Docs)
Best for:
- Proposals and RFCs
- Meeting notes and follow-ups
- Complex decisions with multiple stakeholders
- Knowledge that should persist
- Async reviews and feedback
Format tips:
- Start with TL;DR
- Use headers for scannability
- Call out action items and decisions clearly
- Include deadline if feedback is needed
Best for:
- External communication
- Formal announcements
- Reaching people outside your company
- When you need a paper trail
Avoid for:
- Internal quick questions (use Slack)
- Collaborative editing (use docs)
Video Calls
Reserve for:
- Complex discussions needing real-time back-and-forth
- Sensitive conversations (feedback, conflict)
- Relationship building
- Urgent problem-solving
- Brainstorming and creative work
Always:
- Send agenda beforehand
- Record for those who can't attend
- Document decisions and action items after
PRs and Code Comments
Best for:
- Code-specific discussions
- Technical decisions with code context
- Review feedback
- Architectural choices in implementation
Over-Communication
In remote work, default to over-communication:
Share Context Liberally
People can't see what you're working on:
| Don't | Do |
|---|---|
| Disappear for hours | Post "heads down on X, will be slow to respond" |
| Assume people know your schedule | Share working hours in your profile |
| Go silent when stuck | Post "blocked on X, exploring options" |
| Complete work silently | Share progress: "Finished the API, moving to tests" |
Working Out Loud
Share your thinking, not just your conclusions:
Good examples:
"Exploring two approaches for the caching problem: Redis vs. in-memory. Leaning toward Redis for cross-instance consistency. Will share trade-offs in #architecture by EOD."
And:
"Hit an unexpected issue with the auth flow - user sessions aren't persisting across subdomains. Investigating cookie settings. ETA unclear, will update in 2 hours."
When Changing Plans
If priorities shift:
- Communicate the change and reason
- Update anyone who was expecting the old thing
- Don't assume people will notice
Time Zone Awareness
Know Your Team's Time Zones
Keep a quick reference:
- Who overlaps with you (synchronous possible)
- Who doesn't (async required)
- When each person's day starts/ends
Async by Default
When in doubt, don't expect immediate response:
- Include context so they can reply without follow-up questions
- Set clear but reasonable deadlines
- Acknowledge receipt even if you can't respond fully yet
Schedule Sends
Don't send messages at 2am someone else's time:
- Use "schedule send" features
- Or add context: "No response expected until your morning"
Rotating Meeting Times
For regular cross-timezone meetings:
- Rotate who bears the inconvenient time
- Record meetings for those who can't attend live
- Default to async when sync isn't essential
Documentation Over Meetings
Meeting Decision Rule
Before scheduling a meeting:
- Write first: Draft the problem, context, and options
- Collect async feedback: Give 24-48 hours
- Then decide: If still unresolved, schedule a meeting
Many meetings can be avoided if the organizer documents well enough that discussion isn't needed.
Meeting Follow-Up
Every synchronous meeting should produce async artifacts:
- Notes: Key discussion points
- Decisions: What was decided and why
- Action items: Who does what by when
- Recording: For those who couldn't attend
Share within 24 hours while context is fresh.
Recording and Summarizing
For important sync meetings:
- Record video/audio
- Create written summary with timestamps
- Call out decisions and action items
- Share in relevant channels
Writing for Async
Frontload the Point
Start with the conclusion/ask, then provide context:
Buried lead (bad):
"I've been looking at our deployment pipeline and noticed that the test suite takes 45 minutes. After investigating, I found that most of the time is spent on integration tests that could be parallelized. I've put together a proposal to reduce this by 60%..."
Frontloaded (good):
"Proposal: Reduce our test suite time from 45 min to 18 min by parallelizing integration tests.
Context: Our deployment pipeline is slow because..."
Make It Scannable
Use structure for long messages:
- Headers for sections
- Bold for key points
- Bullets for lists
- TL;DR at the top for long documents
Include Everything Needed
The reader shouldn't need to ask follow-up questions:
| Missing context | Complete context |
|---|---|
| "The deploy failed" | "The 3pm deploy to staging failed with timeout error (link to logs). I'm investigating and will update in 1 hour." |
| "Can you review my PR?" | "Can you review my PR (#123)? It's ~200 lines touching the auth flow. Happy to answer questions async or sync." |
Set Clear Expectations
Make response expectations explicit:
- Deadline: "Feedback needed by Friday EOD"
- Priority: "Not urgent, whenever you have time"
- Type of response: "Looking for approval" vs. "Want to brainstorm"
- Who should respond: "@team" vs. specific people
Anti-Patterns
The Slack Novel
Long-form content in chat messages:
- Hard to skim
- Gets lost in scroll
- Can't be edited or organized
Fix: Put it in a document, share the link.
The Ping-Pong Conversation
Back-and-forth that takes 3 hours in chat but would take 10 minutes in a call:
Fix: After 3 exchanges, offer "Want to hop on a quick call?"
The Surprise Meeting
Adding meetings without context or asking availability:
Fix: Always include agenda; ask before scheduling.
The Ghost
Disappearing without communication:
Fix: Post status when stepping away; respond to acknowledge messages even if you can't fully address them.
The Always-On Expectation
Expecting immediate responses:
Fix: Set team norms about response times; use async by default.
Team Norms
Consider establishing explicit norms:
## Our Communication Norms
### Response Times
- **Slack DM:** Within 4 working hours
- **Slack channel:** Within 24 hours
- **Email:** Within 48 hours
- **Document comments:** Before stated deadline
### Urgent vs. Non-Urgent
- For truly urgent: Use @here or call
- For everything else: Assume async
### Deep Work Protection
- No expectation of response during focus time (blocked on calendar)
- "Do Not Disturb" is respected
### Time Zone Respect
- Core overlap hours: 10am-2pm EST
- Meetings scheduled in overlap hours only
- Async preferred outside overlap