Here is a number worth sitting with. In 2004, people spent an average of two and a half minutes on one screen before switching to something else. Today it's 47 seconds.
Gloria Mark, a professor of informatics at UC Irvine, has measured this for about two decades. She shared the numbers on Microsoft's WorkLab podcast, and they line up with her book, Attention Span.
Zach Mercurio, who joined Debra and me on Corey-osity Unleashed, frames this stat as a mattering problem. If your attention flickers every 47 seconds, you miss the small moments where people feel seen. He's right, and I've written about the human side before in Hurry and Care Don't Live in the Same Room and Being in the Room Isn't Listening.
This post is about the other half. The half engineering leaders own.
Your team didn't drift into a 47-second attention span. You built the system around them. One channel, one "quick call", one @here at a time.
The Workday Is One Long Interruption
Microsoft looked at anonymized Microsoft 365 signals and published the results in its 2025 report, Breaking Down the Infinite Workday. The headline numbers:
- Meetings, emails or chats interrupt employees every two minutes during core work hours. Add it up and you get 275 interruptions a day.
- The average worker receives 117 emails a day and 153 Teams messages per weekday.
- 57% of meetings are ad hoc calls with no calendar invite.
- Meetings after 8 pm are up 16% year over year.
Read the third one again. More than half of all meetings happen without anyone planning them. Somebody had a thought, hit the call button, and pulled two or three people out of whatever they were doing.
Nobody in leadership signed off on 275 interruptions a day. Nobody needed to. It's what happens when every tool defaults to "instant" and nobody sets a different rule.
Engineers Pay More Than Most
Every knowledge worker loses something to an interruption. Engineers lose more, because the work lives in their heads.
When I'm deep in a bug, I'm holding a model of the system in working memory. Which service calls which. What state the cache is in. The three things I already ruled out. A tap on the shoulder doesn't pause the model. It wipes it.
Chris Parnin and Spencer Rugaber studied this directly. They analyzed about 10,000 recorded programming sessions from 86 programmers and surveyed 414 more. What they found:
- Only 10% of sessions had programming resume in less than a minute after an interruption.
- In about 30% of sessions, the gap before the first edit was over 30 minutes.
- Only 7% of sessions involved no navigation to other parts of the code before editing.
In other words, after an interruption, almost nobody picks up where they left off. They wander back through the code, rebuilding the picture piece by piece, before they write a line.
So when someone says "it's only a two-minute question", they're right about their two minutes. They're wrong about the cost.
Your Team Isn't Slower. It's More Stressed.
Here's the part I didn't expect.
Gloria Mark, Daniela Gudith and Ulrich Klocke ran an experiment on interrupted work, published as The Cost of Interrupted Work: More Speed and Stress. People facing interruptions finished their tasks faster, with no drop in quality.
Sounds great. It isn't.
The researchers' read: people compensate for interruptions by working faster. They pay for it in stress, frustration, time pressure and effort. And this showed up after only 20 minutes of interrupted work.
Twenty minutes. Your engineers live in it for eight hours, then pick up the after-hours messages.
This is why the dashboard looks fine while the team burns out. Velocity holds. Tickets close. The cost doesn't show up in Jira. It shows up in the exit interview.
You Set the Timer
I'll say the uncomfortable bit plainly. Most of the interruptions on an engineering team trace back to the leaders.
Not because leaders are thoughtless. Because leaders are busy, and the fastest way to get an answer is to ask someone right now. Every time you do it, you teach the team three things:
- Fast replies matter more than deep work. If the boss pings and you answer in 30 seconds, you're responsive. If you answer in two hours because you were in the code, you're unreachable.
- Status lives in chat, not in the work. If you ask "where are we on this?" in a DM, people learn to keep chat open all day to be ready for the next one.
- Your attention is the scarce thing, and theirs isn't. You protect your calendar. You let theirs fill up with your ad hoc calls.
Nobody writes these rules down. They don't need to. The team watches what you reward.
Here's a test. Look at your own sent messages from yesterday. Count how many were questions you'd have answered yourself with ten minutes of reading. Count how many needed an answer before the end of the day. I'd bet the gap between those two numbers is most of the noise on your team.
How to Give the Minutes Back
You won't get your team back to two and a half minutes per screen by sending a memo about focus. You change the defaults. Here's what I'd start with.
Make response times explicit
Write down what each channel means. For example:
- Pages and phone calls: production is down or someone is about to be harmed. Answer now.
- Direct messages: answer today.
- Channels and email: answer within a working day.
The point isn't the exact numbers. The point is to kill the unspoken rule where everything means "now". Once people know a DM is fine to answer at 3 pm, they stop watching for it.
Protect a shared focus block
Pick a block of hours, several days a week, where the team holds no meetings and expects no chat replies. Mornings work well for most teams. Put it on the shared calendar so it's visible to everyone outside the team too.
Then the hard part. You honor it first. If you send a "quick question" during focus time, the block is dead by Thursday.
Batch your own questions
Keep a running note for each person on your team. When a non-urgent question comes up, add it to the note instead of sending it. Bring the list to your next one-to-one or send it once at the end of the day.
I like this one because it costs nothing and it changes your own habits, which is where the problem started.
Stop asking for status
If you need status, look at the board, the pull requests or the deploy log. If none of those tell you what you need, fix the reporting, not the engineer. A status ping is an interruption dressed up as interest.
Measure the noise
You measure deploy frequency and cycle time. Measure interruptions too. Ask the team once a month how many focused two-hour blocks they got last week. Track it like any other metric. When it drops, find out why.
The Moments You Miss
Back to Zach's point. His work on the power of mattering comes down to people feeling noticed, affirmed and needed. You won't notice anyone if your own attention resets every 47 seconds. And your team won't do their best work if you keep resetting theirs.
The two problems feed each other. A leader who pings all day trains a team who answers all day. Then everyone sits in the one-to-one half-listening, because their phones are already buzzing with the next thing.
You set the timer. You get to reset it too.
So try this. Tomorrow, before you send a message to anyone on your team, ask yourself one question: does this need an answer before they finish what they're doing? If not, put it in the note. Count how many messages you didn't send by Friday.
Then tell your team what you did, and ask them to hold you to it.