Latest / The Productivity Podcast with Fexingo: Output, Efficiency, and Long-Term Economic Growth / The Productivity Trap in Remote Work Asynchronous Communication
Transcript
- Lucas: So there's this number that's been rattling around my head since I read a Microsoft internal study from late last year. They looked at sixty thousand employees across different work models and found that replacing a single ten-minute in-person check-in with a written Slack thread costs teams an average of twenty-three minutes of net productivity per person per day. Luna: Wait—twenty-three minutes per person per day? That's nearly two hours a week per person just from swapping one meeting for a thread? Lucas: Exactly. And the study controlled for task complexity, team size, and seniority. The drag comes from three things: context switching when you have to re-read the thread each time, over-explaining because written text lacks tone and nuance, and delayed feedback loops that force more rounds of clarification. Luna: I've definitely felt that. You write a thoughtful paragraph, then wait four hours for a reply, and by then you've moved on to something else. The re-entry cost is real. Lucas: Right. And the thing is, async communication is sold as this great liberator—free your schedule, deep work all morning, answer messages when you're ready. But for interdependent tasks, it can actually increase total coordination time. Luna: So is the answer just 'go back to more meetings'? That feels like the wrong takeaway too. Lucas: No, and the study doesn't say that either. It finds that the cost varies hugely by task type. For routine status updates—like 'did you finish that report'—async is fine. But for tasks with high interdependency, where one person's output depends on another's input, the cost spikes. Luna: Give me a concrete example. I want to picture this. Lucas: Sure. There's a mid-sized SaaS company, about a hundred and twenty people on the engineering team. They went fully async last year—no standups, no sync meetings except for quarterly planning. They tracked story-point velocity using their existing Jira data. Over six months, velocity dropped fourteen percent. Luna: Fourteen percent is huge. That's like losing a day of output every week and a half. Lucas: Yeah. And when they backtracked, they found the biggest slowdown was in cross-team dependencies. A front-end team waiting on an API change from the back-end team—the async thread would take three days of back and forth instead of a fifteen-minute huddle to agree on the interface. Luna: It's ironic because the whole pitch for async is that it reduces interruptions. But for that kind of work, the interruption of context switching—even if it's self-inflicted—might be worse than a quick synchronous chat. Lucas: Exactly. The study's key insight is that async doesn't eliminate coordination cost—it shifts it from the initiator to the receiver, and it adds latency. The initiator saves ten minutes by not having a meeting, but the receiver might spend fifteen minutes parsing a poorly written request, plus the delay means the initiator context-switches back to the task later. Luna: So what's the fix? I mean, we're not going back to five-days-a-week in-office. Remote and hybrid are here to stay. Lucas: One idea that's gaining traction is what some teams call a 'lowest-bandwidth rule.' The principle is: use the lowest-bandwidth channel that still gets the job done. If a task is complex and interdependent, default to a synchronous call—even a ten-minute one. If it's a simple update, use async. Luna: So basically, match the communication mode to the task complexity. Don't write a novel when a quick chat will do, and don't schedule a meeting for something that can be a one-line message. Lucas: Right. And the Microsoft data backs that up. Teams that explicitly trained their members on this rule saw a nine percent improvement in perceived productivity within two months. Not a huge number, but it's a real effect. Luna: I want to push back a little though. Isn't there a risk that people overuse synchronous calls because they're easier for the initiator, even when async would be fine? That could create its own cost. Lucas: That's a fair point. And the study acknowledges that. The lowest-bandwidth rule isn't a blanket 'sync is better.' It's more like: don't use a fire hose when a garden hose will do. A ten-minute call is still a call—it requires both people to be available. So the rule has to be applied thoughtfully. Luna: If walking through the economy of communication with us has made something click, there's a small way to keep this show ad-free. A listener support page at buy me a coffee dot com slash fexingo. No pressure, just a way for folks who find value here to chip in. Lucas: Appreciate that, Luna. And it really does help keep us independent. So back to the data—the study also found that the cost of async is highest for managers. Managers spent an average of thirty-one minutes per day re-reading threads to stay in the loop, compared to eighteen minutes for individual contributors. Luna: That makes sense. Managers need to track more context across more teams. So async scales badly with span of control. Lucas: Exactly. And that's a structural issue. If you have a manager overseeing eight people on four different projects, they're essentially in four separate async conversations simultaneously. The context-switching tax multiplies. Luna: So what does a good async setup look like? If I'm a team lead listening to this, what's one actionable takeaway? Lucas: I'd say: audit your team's communication for one week. Categorize every interaction as either a status update, a decision request, or a complex coordination task. For the decision requests and coordination tasks, see how many could have been resolved faster with a five-minute call. The Microsoft study found that about thirty percent of async threads could be replaced by a sync chat without any loss of information. Luna: That's a pretty low bar. Thirty percent is almost a third of your thread volume. Lucas: Right. And if each of those threads saves twenty-three minutes per person, the aggregate gain is substantial. For a ten-person team, that's about four hours a day of reclaimed time. Luna: I wonder if part of the problem is just tool design. Slack and Teams are built for continuous, low-friction messaging. They don't have a built-in 'this conversation should be a call' prompt. Lucas: That's a good observation. Some companies are experimenting with plugins that nudge you after three back and forths on the same topic. 'You've exchanged six messages about the API schema. Want to jump on a quick call?' Simple, but it changes behavior. Luna: I like that. It's a lightweight intervention. Not a mandate, just a suggestion. Lucas: Exactly. And it respects autonomy while reducing friction. The broader lesson from this study is that productivity tools aren't neutral. They shape how we communicate, and sometimes the shape is a trap. Luna: Okay, so final thought: if async is the default for remote work, and the default is costing us, what's the one change you'd recommend to a team leader tomorrow? Lucas: I'd say: create a simple rule of thumb. If a conversation requires more than two back and forths to resolve, escalate to a synchronous channel. It's not perfect, but it's a starting point that the data supports. Luna: That's a good note to end on. Thanks Lucas. Lucas: Thanks Luna. See everyone next time.