I've talked to a lot of engineering managers who can't figure out why their developers seem frustrated. The sprint metrics look fine. PRs are getting merged. Tickets are moving. But morale is low, and the team keeps saying they feel like they're not getting anything done.
After digging into it, I've found the problem is almost never about output. It's about the conditions under which that output gets produced.
Most developers aren't struggling because they're lazy or distracted. They're struggling because their calendars make sustained focus structurally impossible. You can ship code in 20-minute windows between meetings all day long and still end the day feeling like you accomplished nothing, because the kind of work that actually feels meaningful requires more than 20 minutes to do.
There's a name for this: productivity dysmorphia. It's the gap between what you objectively produced and what you subjectively feel like you produced. And the research explains exactly why that gap exists.
Why Fragmented Days Feel Empty
When you switch tasks, your brain doesn't just pick up where it left off. A study from UC Irvine found it takes an average of 23 minutes to fully regain focus after an interruption. That's not 23 seconds. It's 23 minutes of recovery time before you're thinking at the depth you were before.
That number becomes a real problem when you look at how most engineering calendars are structured. If you have meetings at 9:30, 11:00, 1:00, and 3:00, you don't have four gaps of free time. You have four windows that are almost entirely consumed by context-switching overhead. By the time your brain is ready to do something hard, the next meeting is already close enough to pull your attention toward it.
A 30-minute gap between meetings yields about 7 minutes of usable focus. A 2-hour block yields nearly 100. The difference isn't linear; it's structural.
Psychologist Sophie Leroy's research on attention residue makes this worse. Even after you physically move to a new task, part of your cognitive bandwidth stays stuck on the previous one. You leave a 2 PM standup and open your editor, but your brain is still processing what was said in the meeting. You're typing, but you're not thinking.
This is why three hotfix PRs feel less satisfying than one complex feature, even if the hotfixes took longer in total. The hotfixes get done in short bursts of reactive work. The complex feature requires the kind of deep, sustained focus that Csikszentmihalyi called Flow: full immersion in a hard problem, where time disappears and progress feels real. A fragmented calendar makes Flow nearly impossible to reach. So developers ship things and still feel empty, because they never got to do the work that actually satisfies them.
Paul Graham described the structural version of this problem as the maker's schedule versus the manager's schedule. Managers think in one-hour blocks, so a single meeting just fills a slot. For a developer, the same meeting can ruin an entire afternoon by eliminating any realistic chance of reaching deep focus before or after it.
The Problem With Introspection
Here's what makes productivity dysmorphia hard to diagnose: asking yourself how your day went doesn't work.
Ask a developer at 5 PM how many real focus blocks they had that day. They'll probably say "a few." The actual number, meaning uninterrupted stretches long enough to load context and do hard work, is often zero. Research on retrospective time perception shows that we consistently compress the memory of fragmented work and expand the memory of focused work. What felt like a productive day was actually dozens of short reactive tasks stitched together. The brain smooths it over. The fatigue is real, but the memory lies.
This is where data becomes genuinely useful, not as a productivity metric, but as a reality check.
GitHub's Good Day Project studied 40 developers over two weeks and found that with minimal interruptions, developers had an 82% chance of having a good day. When interruptions dominated their day, that dropped to 7%. They also found that the developers who shipped the most pull requests didn't necessarily have the best days, because being constantly pulled out of focus to handle PRs appeared to cancel out the satisfaction of completing them.
Source: GitHub Octoverse Good Day Project, 2021. N=40 developers over two weeks.
That last finding is the clearest illustration of productivity dysmorphia I've seen in the research. You can be shipping constantly and still feel like you're not getting anywhere.
Span addresses this at the team level. It connects to your codebase and engineering toolchain and automatically categorizes where developer time is actually going across meetings, deep work, maintenance, and context switching, without requiring manual tracking. When an engineering manager can see that their team logged 200 hours last week but the majority was consumed by meetings and reactive work, the conversation changes. The problem stops being "we need to work harder" and starts being "we need to protect more time for actual engineering work."
That shift in framing matters. When a team attributes the hollow feeling to personal failure, it's demoralizing and hard to fix. When they can see it in a dashboard and attribute it to a structural problem, it becomes something they can actually address.
What to Do About It
None of the fixes here are complicated. The hard part is treating them as real constraints rather than nice-to-haves.
Protect at least one two-hour block per developer per day. This is the minimum viable unit of deep work. Thirty or forty-five minutes isn't enough to load context on a hard problem and make meaningful progress. By the time a developer has pulled the branch, reviewed the ticket, traced the relevant code, and formed a clear mental model of what needs to happen, the window is already closing. If you look at your team's calendars and there's no consistent uninterrupted two-hour stretch, you've scheduled a week of reactive work and called it an engineering sprint.
Batch reactive work into fixed windows. Code reviews, Slack replies, and PR comments are real work, but they're interruptive by nature. Grouping them into two fixed windows per day, say mid-morning and late afternoon, keeps them from bleeding into focus time throughout the day. This is a scheduling convention, not a policy. It requires no tools and no approval.
Establish explicit response-time expectations for Slack. The biggest source of interruptions for most engineering teams isn't meetings. It's the assumption that Slack messages need a near-immediate reply. That assumption is almost never written down anywhere, but it shapes behavior constantly. Teams that set a clear norm, like "non-urgent messages get a response within two hours," consistently report less anxiety without any measurable drop in communication quality. One team conversation can change the default permanently.
Use data to make the problem visible to leadership. Individual developers can protect their own calendars to some extent, but the real leverage is at the team and org level. When a manager can show in a dashboard that 60% of engineering time is going to meetings and reactive work, it's a different conversation than asking people to "block more focus time." Span's engineering time categorization is useful here because it provides the kind of objective, code-linked data that's hard to argue with.
That said, none of these changes require a reorganization or executive buy-in to start. They require that someone on the team decides to treat focus time as a resource worth defending rather than the default thing that gets scheduled over.
Final Thoughts
Productivity dysmorphia is a predictable outcome of how most engineering orgs are structured, not a sign that developers aren't working hard enough. When the calendar makes deep work structurally impossible, people feel unproductive because they are, not in terms of output, but in terms of the work that actually registers as meaningful.
The fix isn't motivational. It's architectural. Protect the blocks, batch the reactive work, and make the time distribution visible with data. The developers on your team probably already know something is wrong. The data just gives you a way to show it to everyone else.
Want to understand where your engineering team's time is actually going? Span gives engineering leaders an automated view of how developer time is distributed across deep work, meetings, and reactive tasks, without the manual overhead.
Top comments (0)