โถWhat's the difference between async and just waiting for a response?
Async communication is intentional design: you craft messages with full context upfront, not expecting the recipient to be available now. You set clear response-time expectations (72 hours vs. same-day vs. FYI). Waiting is passive, you send a Slack and hope they see it. Async is active, you write as if this message is the only thing they'll see about this topic, include background, decision history, and next steps.
โถWhen does async fail?
Time-sensitive crises (production down), high-context brainstorms (whiteboarding ideation), or emotional conversations. If the answer requires back-and-forth 10 times in 30 mins, sync is faster. If someone is visibly upset, a 5-min video call beats 10 written rounds. Rule: async for decisions, implementation, updates; sync for emergencies, complex creative work, and conflict resolution.
โถHow do I write an RFC (Request for Comments)?
Structure: Problem (2 para) โ Proposed Solution โ Alternatives Considered โ Implementation Plan (timeline, risks) โ Open Questions. Post in a shared doc, tag stakeholders, set feedback deadline (48h-1 week depending on impact). Treat it as a written design doc. Bad: 'Should we do X?' Good: 'We have 300 enterprise requests pending features Z and K. Proposal: timeline-prioritize K first (3 weeks, 2 eng, reduces churn by ~5%).' Attach data.
โถWhat's the etiquette for Loom videos?
Script your key points, keep <5min, include timestamps (00:00, overview, 01:30, code walkthrough, 03:45, decision point), add captions for accessibility. Use zoom 125% so viewers can actually read code. Stop talking every 30s (silence feels long but buys thinking time). Post a TL;DR bullet list below the embed. Treat it as a replacement for a meeting, not a bonus.
โถWhat are ADRs and why do they matter?
Architecture Decision Records: one-page docs for each technical decision (why we chose PostgreSQL over MongoDB, why we split auth into separate service). Date it, list alternatives, explain trade-offs, link to RFC or issue. Build a living docs library so future engineers don't re-litigate the same decisions. Good async culture defaults decisions to text first.
โถShould everything be public by default?
Yes for technical decisions, processes, design docs, roadmaps, forces clarity and enables anyone to catch errors. Private is fine for: salary data, personal feedback, personnel matters, executive strategy pre-announcement. Rule of thumb: if a new team member should eventually know it, post it public. If it's confidential by nature, lock it down and archive after it's no longer sensitive.
โถHow do I handle time-zone async?
Accept there's no same-day turnaround across 8+ zones. Set expectations: decisions turnaround in 24-48h, not 4h. Record meetings, post key decisions in Slack with video link. Use a status board (Notion) where each timezone updates their progress end-of-shift. Schedule one annual/quarterly sync on each side's evening; async handles everything else. This actually scales better than everyone pretending 'early morning' meetings work.