The pitch for async-first development was simple: replace synchronous meetings with written communication, and developers would get back thousands of hours of deep focus. Five years into the post-pandemic remote experiment, the data says the opposite happened.
Reclaim.ai's 2026 SXSW survey found that knowledge workers need 19.6 hours of focus time per week to feel productive — and are actually getting 10.6. That 9-hour weekly gap is not primarily from meetings. Many of the surveyed organizations had already eliminated most synchronous time. The focus hours are disappearing somewhere else.
The Experiment That Ran
The pandemic forced a live test of async work at scale. Standups moved to Loom. Planning meetings became Notion docs. Hallway conversations became Slack threads. The tooling improved: Linear replaced JIRA, Loom replaced Zoom for most status updates, shared docs replaced the planning-meeting format. More than 57% of remote companies now describe themselves as async-first.
That shift should have returned measurable focus time to developers. If synchronous meetings were the bottleneck, eliminating them should have produced longer uninterrupted coding sessions and meaningfully more deep work per day.
The average focus session in 2025 measured 13 minutes and 7 seconds — down 9% from 2023. Developers averaged 2.24 hours of actual focus per day, with 31.6 interruptions logged across the workday. Microsoft research puts the threshold for meaningful progress on complex tasks at 2 contiguous hours. Most developers are not hitting it, despite having fewer synchronous meetings than they did in 2019.
The numbers are moving in the wrong direction at exactly the moment the conditions for focus should have been improving.
The Bottleneck Just Moved
Replacing meetings with Slack did not reduce communication volume. For most teams, it increased it substantially. Meetings have a fixed endpoint — they end and you return to work. Asynchronous channels have no such structure. A message is frictionless to send. Questions that once waited for a weekly sync now arrive as pings at 10 AM, 2 PM, and 5 PM. Replies breed replies. Threads multiply.
The cognitive cost is consistent across the interruption research: even a brief context switch collapses whatever you were holding in working memory. The UC Irvine finding — 23 minutes to fully regain focus after an interruption — is often cited, but the framing matters. You are not losing 23 minutes per notification. You are collapsing the mental model that took 20 minutes to build and paying that cost again to rebuild it. In a session full of small interruptions, you may never reach sustained depth at all.
A developer working 8 hours with 31 interruptions — roughly one per 15 minutes — is not getting fragmented focus time. They are getting close to none. Those interrupted hours count against your day without producing the kind of output that deep coding requires.
Why Async Teams Are Reporting More Burnout, Not Less
The promise of async was psychological safety alongside productivity: you do not have to respond immediately, so you work at your own pace, and the cognitive load decreases. The reality has been more complicated.
A January 2026 analysis found that 31% of Gen Z knowledge workers report async work increases their burnout. The cause is not the async format itself but the absence of norms around it. When every message carries an implied expectation of a timely response — even at 9 PM, even on weekends — the flexibility of async inverts into always-on obligation. The communication volume grew; the psychological cost of managing it grew with it.
What actually reduces burnout is not switching the format. It is controlling the volume and establishing firm boundaries around when communication is expected to happen. Stanford research tracking remote workers who were given explicit control over interruptions found a 13% productivity gain attributable specifically to that control — not to the absence of meetings per se. The mechanism was reducing unplanned interruption, regardless of whether it arrived synchronously or asynchronously.
What "Focus Time" Actually Means in the Data
Here is what the async productivity narrative consistently misses: focus time is not defined by what is absent from your calendar. It is defined by what actually happens to your attention during the hours that are open.
Two hours with no meetings but with Slack open and notifications enabled is not focus time. It is unstructured interruption time. The calendar is clear; the attention is not.
Tracking this properly requires measuring at the level of actual app behavior, not calendar events. When we look at xeve data across users, developers who describe themselves as "remote, few meetings" often show context switch rates indistinguishable from — or higher than — developers in offices with regular standups. The home environment removed one interruption source and introduced others: household distractions, phone notifications, the pull of always-available messaging that office norms once suppressed.
The correlation that matters in the data is not calendar density versus focus time. It is uninterrupted session length versus output. Days where developers sustain coding blocks of 30 minutes or longer consistently produce more committed code, fewer rework cycles, and lower bug rates than days with equivalent coding time broken into fragments — regardless of whether those fragments came from meetings or from a notification feed.
The Fix Is Not More Async
Going deeper into async — more written communication, fewer synchronous touchpoints — does not solve this if the underlying notification density stays the same. You are just changing the delivery mechanism for the interruption.
The productive move is deciding, deliberately, when communication is expected and when it is not. Not "async or sync" but "protected or unprotected." A morning coding block where Slack is in Do Not Disturb, with a four-hour expected response window, is structurally different from a morning where you happen to have no meetings but are monitoring five channels with notifications on.
The teams that show the best focus time in the data are not the ones with the fewest meetings. They are the ones with explicit communication norms: specific hours when responses are expected, specific windows when developers are considered genuinely unreachable, and measurement practices that make the actual distribution of attention visible. Without that visibility, the policy erodes. A calendar rule that says "two meeting-free mornings per week" loses ground in a quarter if nobody is checking whether those mornings produced three-hour coding sessions or a different kind of fragmented day.
Async-first was the right instinct. The implementation stopped one step short — at the calendar, instead of the notification feed. The focus time did not come back because we only changed where the interruptions came from, not how many arrived.