Distracting software engineers is more harmful than managers think (even in the AI times)
Sep 2025
Our work culture changed mainly for the better after COVID-19, but there were also some negative changes - like an increase of 13.5% in the amount of meetings per employee.[1]
The problem? There's a huge gap between how managers think about meetings versus how engineers think about them.
In the famous “Maker’s Schedule, Manager’s Schedule” [2], Paul Graham wrote:
“When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.”
This problem hasn't gone away with AI coding tools - if anything, it's getting worse as managers assume engineers can now be productive in smaller time chunks.
Over the past 2 years, we've studied hundreds of engineering teams to understand what the best ones do differently. In this article, we'll share their proven strategies and actionable steps you can implement today.
First, let’s talk about deep work:
So what is deep work?
The term was coined by Cal Newport, in Deep Work: Rules for Focused Success in a Distracted World book [3].
Deep Work is the kind of work that requires a big part of your brain power and usually gives some unique value. It can’t be done while distracted! If you can do a task during a Zoom call, it means it’s NOT deep work.
Shallow Work is the opposite - things you can do without engaging 100% of your brain. Things like answering Slack messages/emails, reviewing a document, and so on.
Software engineering used to be a haven for people who enjoy deep work. There is a reason why some people still think that software engineers work alone with their headphones in the basement.
Today it’s becoming harder and harder to get those ‘Deep Work’ times - and I believe they are even more critical while using AI coding tools.
Why Deep Work is so critical
Working deeply is the only way to achieve the famous ‘flow’ state - AKA being in the zone.
More deep work helps engineers to:
Make fewer mistakes
Support their work-life balance - they’ll get more work done in less time, so more free time will be left.
Improve their skills - in those focused times the toughest challenges are solved, and the biggest improvements to skills happen.
A big mistake managers make is assuming that with AI coding tools, it’s no longer critical. That engineers need to get used to constantly task switching - as you anyway have to wait for a couple of minutes between prompts, so who cares about distractions.
What happens then is that the quality of our thoughts and prompts go down. We fall into endless loops of asking the AI to fix the problems, while giving mediocre context.
If you stay in the flow state, deeper in the problem, you’ll need many less iterations to achieve the same result. No data for this one, only my experience and gut feeling.
So what’s the problem with deep work?
Remote work should have been an answer to this - no commute, fewer distractions. In reality, only the first part is true.
Since 2020, in addition to the 13.5% increase in total meetings, there has also been a rise of 60% in remote meetings[5]. The unsurprising part is that 92% of people say they multitask during those meetings[6] - and I would guess the number is just about 100% for software engineers.
There are 2 main problems with that:
1. Work that should be Deep, becomes Shallow
Remember the simple test we discussed above? If you can do it in a Zoom meeting => it’s shallow work.
A great example is reviewing PRs. If you have a busy day filled with meetings, when would be the best time to review them?
During the meetings of course… But reviewing a pull request should be deep work! Same for bug fixes, or writing design documents.
Doing those tasks during a meeting starts a horrible cycle:
The quality of the work gets poorer so more problems arise → more meetings are scheduled to address them.
People are being distracted during meetings so no good decisions are taken → more meetings are scheduled…
And it’s not the fault of your multitasking engineers - it’s the fault of your meeting culture.
2. Engineers are not reaching the flow state
It takes 15 minutes just to get going and only by the 45-minute mark (!) you will hit your peak, when you are fully immersed in the problem.[7]
Every time you’re distracted, that clock resets thanks to context switching. In a study done by Meta [8], they’ve shown how severe the problem is - engineers get just 2 1-hour sessions a week! (And I find it crazy that a 3 minute session is considered ‘focus time’ at all).
It was not just the time in meetings that is lost. Every distraction sets you back 15-45 minutes, leaving you by the end of the day with just 1-2 hours of productive time in the BEST case scenario.
I love this analogy, borrowed from this Reddit comment[9]:
Imagine developers are like miners. digging is our job. Every time you have a meeting, we need to pack our things, and get to the entrance of the mine on time.
After the meeting is finished, we need to walk alllll the way back to where we were working, assuming we even remember the right path...
So if you want us to get you some diamonds, let us work in peace.
Software engineers need at least 4-5 hours of uninterrupted time a day, and it’s our job as managers to provide it.
How can we create deep work time
Improve the meeting culture at your company
It’s not that hard to fix - you ‘just’ need to get all the managers to commit to basic rules:
Meetings should be effective - obvious right? But still rare… Have a clear agenda, and clear outcomes.
Have a fixed daily time for meetings - and leave big chunks of ‘no-meetings’ time. You can either do no-meeting days, or no-meeting hours, it depends on your organization.
Invite only people who are really needed - this is something that remote work is bad at - it has become too easy to just invite everyone. People think to themselves: “Worst case, they’ll multitask, and be available in case they are needed”.
This is an awful approach! Remember - you cannot achieve a flow state while multitasking.
But the best way? Get rid of as many meetings as you can!
In the past 2 years, we’ve studied how hundreds of engineering teams operate. The engineering team at Pylon really impressed us.
When we asked to see a senior engineer's calendar for the week, it was completely empty. No standups, no sprint planning, no recurring meetings of any kind.
There's still plenty of collaboration, but it happens when needed instead of recurring meetings. This is probably possible because they're in person 5 days a week, but even in remote settings you for sure can get rid of some meetings.
And if you can’t get rid of all meetings, we recommend at least having some company-wide blocks of focus time. After analyzing data 600,000+ PRs at Weave, the data shows that most engineers are the most productive at 10:00-12:00 and 14:00-16:00:
Rethink your PRs workflow
Better yet, do you actually need all those PRs?
The other thing that surprised us about that team at Pylon is that they have almost no code reviews. Engineers merge their own code and only request reviews if they need input, think they have a risky change, or are still onboarding.
Code reviews are a big distraction on both sides - when it comes your way you want to do it as fast as possible to not block others, and when the answer comes you are tempted to look at it and address it immediately. In both cases, it can ruin the flow state.
This goes against conventional wisdom about code quality, but their thought process is simple: if you hire skilled engineers and trust them, there's no reason to bottleneck every change with mandatory reviews.
Set an example
Once you get the meetings under control, you can deal with the other interruptions.
The best way to create a good culture is to cherish your own deep work time, and make sure your team respects it. I have to admit that I’m still struggling with this one - I schedule focus time in my calendar, and put on my headphones, but I still sometimes check Slack and answer when interrupted.
I know this sets a bad example for my team - deep work time should be sacred, and people should know it’s completely acceptable to not be available in Slack for a couple of hours.
Focus time in 2025 becomes critical
I believe that the more we start to depend on AI, the more important focus time will become. The models will become much faster with time, and I believe that companies and engineers who learn to enter the flow state with AI will hugely outpace everyone else.
[1] https://www.notta.ai/en/blog/meeting-statistics
[2] https://paulgraham.com/makersschedule.html
[3] https://www.goodreads.com/book/show/25744928-deep-work
[4] https://hbr.org/2014/05/create-a-work-environment-that-fosters-flow
[5] https://www.cfo.com/news/remote-meetings-up-60-since-2020-weekly-stat/654749/
[6] https://www.flowtrace.co/collaboration-blog/50-meeting-statistics
[9] https://www.reddit.com/r/programming/comments/1bbcoec/comment/ku9i16h/
