Your deployment frequency is up 40%. Lead time for changes is down. The DORA dashboard is glowing green. Your manager is happy.
Then your best engineer quits. She tells you in the exit interview: "I spent more time in meetings than writing code."
You check the metrics again. They still look great. What did you miss?
DORA metrics measure velocity. They don't measure whether your developers have time to think. Your team can hit elite DORA scores while engineers burn out from constant context switching. The deployments keep flowing, right up until your senior people start leaving.
The dashboard says you're fast. The reality is you're fragmented.
The Science of Flow vs Velocity
Research from UC Irvine found that after an interruption, it takes an average of 23 minutes and 15 seconds to return to your original task. That's not a guess. That's controlled measurement of knowledge workers under observation.
Here's what that means: if you get interrupted twice during what you thought was an hour of coding time, you're getting about 14 minutes of real work done.
Flow state changes this equation entirely. When Mihaly Csikszentmihalyi spent 40 years studying optimal performance, he identified that flow requires uninterrupted concentration where challenge matches skill. You can't get there in 30-minute blocks between meetings.
DORA metrics can't see this difference. A deployment is a deployment, whether it took 30 minutes of focused work or 6 hours of context-switching hell.
The Real Problem: Fragmented Time
Clockwise analyzed 1.5 million meetings across 80,000 engineers. The average software engineer spends 10.9 hours per week in meetings. That sounds manageable until you see the next number: 6.3 hours per week in fragmented time.
Fragmented time is the 30-minute gap between standup and your 1:1. It's the 45 minutes between the architecture review and the sprint planning session. It's calendar space that looks empty but is functionally useless.
You can't write meaningful code in 30 minutes. You definitely can't debug a complex system issue. At best, you answer Slack messages and feel busy.
Here's what a fragmented calendar looks like:
This engineer had an 8-hour workday with only two meaningful blocks for deep work: 45 minutes before lunch and 90 minutes in the late afternoon. By the time you load your mental model of the codebase, half the block is gone.
GitHub's Good Day Project found that developers with minimal interruptions have an 82% chance of having a productive day. When interrupted most of the day, that drops to 7%.
Going from two to three meetings per day lowers your progress chances from 74% to 14%.
Yet DORA metrics would show this engineer as equally productive on both types of days, as long as they shipped commits.
How to Measure Flow
Stop trusting your gut. Your calendar data tells the real story.
Traditional engineering metrics only look at Git activity. They count commits, PRs, and deployments. They miss the calendar entirely.
I've been working with developer intelligence platforms like Span through the agency I'm working for, and I've seen how useful it is when you connect calendar data to code output. It shows you something most engineers have never seen: how much uninterrupted time you have.
This engineer thought they had 40 hours of work time. The data shows 20.5 hours of actual focus time, with 11.6 hours consumed by recurring meetings. The breakdown reveals where the time goes: 5.5 hours in 1:1s, 4.3 hours in small group meetings, and fragments in larger meetings.
The maps directly to what Paul Graham calls "Maker Hours" versus "Manager Hours". Makers need blocks of at least 2-4 hours. Managers can work in 30-minute increments. When you see your calendar data broken down this way, you can spot the mismatch: you're being paid to make things, but your schedule looks like a manager's.
Here's what the data typically reveals:
- You thought you had 30 hours of coding time per week
- Your calendar shows only 19.6 hours of focus time (2+ hour blocks)
- After accounting for context switching, you get 12-14 hours of actual deep work
The insight isn't that you're slow. The insight is that the system is slow.
The fragmented time report becomes evidence. You're not making excuses. You're showing math.
How to Reclaim Your Calendar
Once you see the fragmentation, you can fix it. Here are three tactics that work:
Meeting Bankruptcy
Decline every recurring meeting that lacks a clear agenda. If the organizer can't articulate what decisions will be made or what information will be shared, it's a status update disguised as a meeting.
Status updates belong in async channels, not on your calendar.
Clustering
Move all meetings to specific days or specific time blocks. Some teams do "Meeting Mondays and Thursdays." Others block 9-12 for meetings and protect afternoons.
The goal is to create contiguous maker time, not scattered 45-minute gaps.
Async Updates
Replace standup with a Slack thread. Replace status meetings with weekly written summaries. Replace "quick syncs" with Loom videos.
Async communication is searchable, referenceable, and doesn't fracture your calendar. Real-time meetings should be reserved for decisions, not information transfer.
Some developer intelligence platforms can automate this. They pull work from GitHub, Jira, and Slack to create weekly summaries without requiring humans to manually write status updates. You get the information transfer without the meeting.
The conversation with your manager looks like this:
"I know my deployment count looks lower than last quarter. Here's my fragmented time report. I had 4.2 hours of uninterrupted time per week last month. I'm not asking for special treatment. I'm asking for enough time to think."
Show the data. Propose the clustering solution. Most managers will say yes because they're also drowning in meetings.
Better Flow Improves DORA
Here's the irony: when you ignore DORA and optimize for flow, your DORA metrics usually improve.
A study of 10,000 programming sessions across 86 programmers found that only 10% of sessions resume coding in less than 1 minute after an interruption. The rest take significantly longer to rebuild context.
More fragmentation means more interruptions. More interruptions means more bugs. More bugs means lower change failure rate.
Better focus doesn't just make you feel better. It makes you faster and more accurate.
The Shopify example is instructive: after canceling recurring meetings with 3+ people, meeting time dropped 33% in two months. They expected to complete 25% more projects than the previous year.
That's better DORA performance from fewer meetings, not more sprints.
When you protect maker time, you write better code. Better code deploys faster and breaks less often. DORA metrics improve as a side effect of good engineering practices, not as a goal in themselves.
Your Dashboard Doesn't Define Your Worth
DORA metrics were designed to measure organizational performance, not individual productivity. The DORA team explicitly warns against using their metrics for team-by-team comparison or individual assessment.
Nicole Forsgren, who co-created DORA, went on to co-create the SPACE framework specifically because DORA was insufficient. The first letter in SPACE is S: Satisfaction and well-being. That was missing from DORA because DORA was never meant to capture the full developer experience.
Your deployment frequency says nothing about whether you had to sacrifice your weekend to hit that number. Your lead time doesn't show that you haven't shipped anything meaningful in months because you're constantly fixing the fragile system held together with technical debt.
Velocity is a management metric. Flow is a maker metric.
Your most valuable resource isn't your time. It's your attention span. Every meeting fragments it. Every interruption depletes it. Every context switch costs you 23 minutes of refocus time.
Protect your attention like it's your most valuable asset, because it is.
The green dashboard can wait. Your ability to think can't.
How do you protect your focus time? I'd love to hear what's worked (or hasn't) for dealing with meeting overload. Drop a comment below.
Top comments (0)