Remote Async Communication

# 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 ### Email **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: 1. **Write first:** Draft the problem, context, and options 2. **Collect async feedback:** Give 24-48 hours 3. **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: ```markdown ## 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 ```