Async-First Teams Report “Significantly Higher” Productivity—Yet 81% of Remote Workers Check Email After Hours. Are We Doing Async Wrong?
I’m leading an 80-person engineering team at an EdTech startup, and we’ve been async-first since 2022. On paper, we’re crushing it: 85% of remote teams report measurable productivity gains with async collaboration tools. We’ve saved an estimated 6 hours per week per engineer by cutting unnecessary sync meetings. 61% of employees say async communication helps them balance work and life better.
But here’s what’s actually happening on my team:
Last month, I ran a pulse survey. The results were jarring:
- 81% of our engineers check work email or Slack after 6 PM (this matches industry data almost exactly)
- 63% admitted to working on weekends, and 34% during vacations
- 69% cited “digital communication overload” as a top contributor to burnout
- 47% expressed concern about blurred work-life boundaries
We went async-first to give people their time back. Instead, we created an always-on culture where:
- “Async” became code for “respond whenever, which means constantly”
- Slack threads from 3 AM got responses by 6 AM
- “No meetings” turned into “no synchronous boundaries at all”
- Engineers felt more pressure to be available, not less
The Contradiction Nobody’s Talking About
The research is clear: async-first should improve productivity and work-life balance. Teams using async communication save 6 hours every week by eliminating unnecessary meetings. Developers need 2-4 hour uninterrupted blocks for deep work, and synchronous meetings scattered throughout the day make this impossible.
Yet 86% of fully remote workers report burnout. We’re more productive and more burned out. How is that possible?
What I Think We’re Getting Wrong
After countless 1-on-1s and retrospectives, here’s my hypothesis: We’re treating async as a communication mode instead of a boundary framework.
What we say async means:
- “Work when you’re most productive”
- “No need to be online 9-5”
- “Respond thoughtfully, not immediately”
What our behavior actually signals:
- “Be available across all time zones”
- “If it’s in writing, respond within hours”
- “No meetings means always interruptible”
The average worker on my team receives 153 Slack messages per weekday and faces 275 interruptions daily (documented industry-wide). We replaced meeting interruptions with constant async interruptions, which might actually be worse because there’s no clear “off” time.
The Three Async Boundaries We’re Missing
After 18 months of experimentation, here’s what’s starting to work for us:
1. Core Collaboration Hours ≠ Core Work Hours
- Before: “Work whenever, respond whenever”
- Now: “Core collaboration window is 10 AM - 2 PM PT. Outside that window, responses expected next business day, not same day”
- Result: Engineers protect mornings/evenings for deep work. Urgency culture is fading.
2. Response Time SLAs Based on Channel
- Slack DM: 24 hours
- Slack channel message: 48 hours
- Email: 72 hours (unless flagged urgent)
- PR review: 24 hours during core hours
- Documentation comment: No SLA (respond when you have context)
This seems obvious, but we never defined it. The lack of clarity created anxiety that “async” meant “always available for anything.”
3. Forced Offline Periods
- No-notification hours: 6 PM - 8 AM (Slack/email notifications disabled by default)
- Meeting-free Wednesdays (for deep work, not just “no meetings but constant Slack”)
- Company-wide shutdown weeks (2 per year where nobody works—not even “just checking Slack”)
The controversial part: we’re measuring boundary violations. If a manager messages someone at 11 PM, that’s flagged in our quarterly leadership review. If a team’s PRs consistently come in at midnight, we have a conversation about workload and sustainability.
The Hard Questions I’m Still Wrestling With
-
Does async inherently create always-on pressure, or are we just bad at boundaries?
- Is the problem the communication mode, or our inability to define “done for the day”?
-
Are we optimizing for the wrong metric?
- We measure productivity (PRs merged, features shipped). Should we measure sustained productivity over quarters, not velocity over weeks?
-
Is async-first actually more inclusive, or does it advantage those who can work 24/7?
- Parents, caregivers, people with second jobs—does async-first help them, or make it harder to disconnect?
-
When does “flexibility” become “exploitation”?
- If someone chooses to work at 2 AM because they’re productive then, great. But if they feel pressure to be available at 2 AM because that’s when someone in another time zone is active, that’s a culture problem.
What Success Looks Like (I Think?)
For us, “doing async right” would mean:
- High productivity (which we have)
- Low burnout (which we don’t have yet)
- Predictable response times without 24/7 availability
- Deep work blocks protected from interruptions
- Clear “done for the day” signals that everyone respects
Right now, we’re 2 out of 5. We’re productive, but we’re not sustainable.
So, Are We Doing Async Wrong?
I think the answer is: Yes, and most async-first teams are too.
Async isn’t the problem. Treating async as “no meetings but always interruptible” is the problem. We need to rethink async as a boundary framework, not just a communication preference.
Has your team cracked this? How do you do async-first without creating an always-on culture? What boundaries actually work? And am I overthinking this, or is this a real crisis that we’re all pretending is normal?
Let’s talk about what async should look like in 2026—not the aspirational version, but the version that doesn’t burn people out.