How do you measure Deep Work? At what point do you reach a level of focus deep enough to transcend surface-level efficiency?
Depends who you ask. Some say you need at least 60-90 minutes of focus time to call it Deep Work. Others say they do their Deep Work in short 15-minute increments or longer blocks of one to three hours. There are even those who can fit an impressive eight hours or more of Deep Work into each day. So who is doing it right?
According to Cal Newport — the authority on the subject — most of us have about four hours of Deep Work in us each day. The best way to break up that time is up for debate. But at Uplevel, we measure Deep Work as uninterrupted time blocks of two or more hours during a normal workday. Here’s how we arrived at that recommendation.
Why a two-hour minimum?
Whether starting or resuming a task, there is typically a “resumption lag” period before work begins. This is especially true for interruptions, as it takes time and effort to stop existing work and then address the interruption.
The emotional strain/energy draw you feel when shifting focus from one interruption to another is called context switching. And too much context switching can lead to some unwanted outcomes.
For example, with less time to code and do other high-impact work, devs are likely to feel more pressure to meet their deadlines. They may wait until evenings, when interruptions are limited, to finish what they were too busy to do during regular working hours. In the short term, this could result in increased effort and a performance boost. But over time, that kind of “Always On” behavior can devolve into emotional strain, decreased efficiency, and burnout.
Interruptions are believed to have an even bigger impact on software development than other domains. So much so that one research study introduced the concept of “edit lag,” a measure of resumption lag specific to devs. Edit lag measures how long it takes devs to regain context and resume edits after an interruption. In the study, around 30% of participants took half an hour or more to resume work.
Anecdotally, devs are also somewhat reluctant to start cognitively demanding work when they have a meeting in the next hour or two. They know that once they finally get into a groove, it will be time to shift into meeting mode. So what’s the point in even getting started?
With all that in mind, a one-hour block didn’t seem like enough time to enter a state of Deep Work. A recent report found that ICs are interrupted 31.6 times throughout each workday, averaging only 2.24 hours of actual productive task work. For us, that two hours felt like the bare minimum for Deep Work, and it aligned with recommendations we were seeing in the one- to three-hour range.
Why not a four- or five-hour minimum?
Deep Work that falls into the range of four or more hours is an ideal state. As we already mentioned, we typically have around four hours of Deep Work in us each day — total. Anything beyond that is gravy.
If you can work in four-plus-hour stretches of focus time each day, that’s great! But many devs have competing priorities that prevent them from reserving that much time for Deep Work. Even if they could manage it some days, it would be difficult to sustain, requiring planning to mitigate potential impact on the team.
In reality, Deep Work is often a brief experience, cut short by meetings, chats, and other interruptions. You can set aside a four-hour block for Deep Work each day, but it would be difficult to maintain focus the entire time, even without interruptions. Think of how your mind sometimes wanders the longer you read an article or book — you just scan through the words and sentences, taking in none of their meaning. For tasks like this that require our full attention, our ability to stay focused tends to decrease over time.
In these situations, brief disengagement from the task can help refocus attention. If devs don’t have the time or ability to spend four hours in Deep Work mode, breaking it into two-hour chunks is a good goal.
Deep Work blocks of four hours or longer could even have a negative impact, depending on your work culture. Performance-oriented cultures that use Deep Work to achieve “maximum” levels of productivity could see dev health and performance fizzle. In fact, a 2012 meta-analysis found that the average length of maximum performance is around one day.
Four-plus hours of Deep Work can also be harmful if it gets in the way of collaboration. With 50% or more of the workday devoted to focused work, it may be more difficult for team members to give or receive timely help. There are strategies to mitigate the impact, such as collecting all information needed to complete a task prior to focus time. But in general, we think it makes more sense for dev teams to aim for a minimum of two-hour time blocks for Deep Work.
In conclusion, there are many thoughts on the best way to measure Deep Work. After doing our research, we identified two hours as the minimum for developers. That doesn’t mean you can’t shoot for more — if it’s sustainable. Just make sure to plan accordingly to minimize the impact on your team.
Schedule a demo to see how Uplevel gives dev teams visibility into Deep Work metrics to better manage developer health.