Deep Work_ Why we measure in two-hour minimum time blocks

While many popular frameworks for measuring engineering performance tend to outline lagging indicators and outcomes, they don’t focus on the how. That’s a mistake, because successful digital transformations end with “lower cycle times” or “more frequent deployments” but they don’t begin there — they begin with time for deep work.

That’s one resource that engineers don’t get a lot of. Uplevel data found that engineers at enterprise organizations spend, on average, more than half of the day bouncing between meetings and  “short fragments” of work that are interrupted by chat pings and other distractions. Our data is confirmed by a recent report that ICs are interrupted 31.6 times throughout each workday, averaging only 2.24 hours per day for deep work. 

Engineering leaders shouldn’t wait for falling DORA metrics to tell them when their teams are burning out. Encouraging deep work has intrinsic value to people health and engineer well-being, but that’s not the only benefit in itself. It’s also better for organizations, which is why Uplevel measures it as part of a holistic picture of engineering performance.

Why Focus on Deep Work?

Why should engineering leaders care about deep work? It’s an effectiveness concern. The opposite of deep work is context switching, which occurs when engineers are constantly changing focus from one task to another. Just like in multi-threaded programming, each switch has an overhead. As your engineers transition between tasks, neither is moving forward, and making progress on either one becomes difficult. 

Engineers want to build substantial and meaningful things that align to goals and deliver business value, but that requires time to focus. Interruptions can pull them away from work on high-impact projects and business priorities.

engineering-deep-work-inputs

With less time to code and do other important work, developers 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.

How Uplevel Measures Deep Work

The estimated deep work time available in a day is based on details available in the metadata from your team’s calendar, chat tools, and work sources. 

Our Deep Work metric is calculated as two or more hours of meeting-free, uninterrupted time to truly focus. For example, blocks of time you’ve added to your calendar without inviting anyone to a meeting or a free block of time between meetings would count. 

Why Two-Hour Focus Blocks?

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. This creates smaller amounts of time which we call “short fragments,” and they are accompanied by the resumption lag and the emotional strain of context switching. 

Screenshot 2024-03-14 at 1.28.40 PM

Interruptions are believed to have an even bigger impact on software development than other domains. Researchers have even 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. 

We also find that engineers are 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. 

Using Machine Learning to Decode Engineer Availability

Uplevel is the only engineering intelligence platform that uses machine learning (ML) models to estimate deep work based on signals from your team’s work tools. 

For example, our Chat Interruptions model examines Slack or Teams message metadata (timestamps and character counts) to differentiate between a quick, two-second answer to a question and a derail into a side conversation. Extended time spent responding to chat messages is deducted from the estimate because context switching takes away from the focus value of the deep work session.

Uplevel also classifies meetings for greater insight into how your team is spending their time by using ML and natural language processing to interpret meeting titles, durations, attendees, and the org chart relationships of attendees (e.g. manager-direct report, on the same team, etc.). If engineers are in meetings an average of three hours per day (as our data suggests), the general category of those meetings becomes more important to helping them optimize their time. Are they in two hours per day of scrum meetings? That’s likely too many. Are the meetings code reviews or pair programming sessions with mentors? That might be a different story. 

Promoting Software Engineer Deep Work Time

Low deep work isn’t a problem in isolation, but a symptom of unclear expectations and lack of support. A culture of ineffective meetings, lingering decisions, and frequent “fires” and distractions can leave little or no time for intentional work. The good news: it’s fixable. 

Deep work can be a warning that the delivery process and expectations aren’t in place to enable effective development cycles. Simply asking a team to “do more” isn’t helpful, but ensuring that they have time to do the work they’re assigned helps to address the root cause. 

But First, Visibility

The first step is knowing to what extent low deep work is a problem. This can help you set the right expectations and habits. Gaining visibility into which teams are at risk for burnout, which teams are prioritizing deep work and which are struggling, and how much meetings and interruptions are impacting productivity is a good first step.

Product_3

How Managers Create Space for Effective Work

Efficiency and effectiveness takes intentional effort, and those changes start with leadership. Depending on your company rules and team agreements, some may be more feasible than others. But these are all strategies we have used successfully at Uplevel:

Encourage your engineers and managers to set aside time blocks for deep work. Better yet, schedule team- or company-wide deep work schedules throughout the day. 

Make meetings contiguous, scheduling them at the beginning or end of the day. Practice this with your engineering managers, and help them do the same with their teams. 

Learn More

Cut down on the number and length of meetings. Make sure meeting agendas are well defined with takeaways listed, helping invitees determine if their presence is needed. 


Protecting Deep Work: Steps for Engineering Leaders

It’s not enough to just create space for focus to happen. Interactions and distractions fill our days, pulling us away from our work and making it harder to get things done, even if we’re technically in deep work mode. 

Here’s how you can help your teams protect their deep work:

  1.  Establish rules for how your engineering teams handle incoming communications. It will make it easier for them to decide when to break deep work to answer chat messages and emails. For example, give your teams the option to pause notifications during deep work hours without anyone expecting a response — assuming others can still get through for critical requests.

  2. Encourage managers to set up a rotating Responder role for their teams. That person can respond promptly and delegate work appropriately without breaking everyone’s focus.

  3. Rethink how your teams are allocating their time. If KTLO tasks and bug fixes are pulling them away, work with them to shift time and headcount toward your high-priority investment areas.

  4. Be mindful of the opportunity cost of context switching. Bouncing between goals isn’t free. Make sure everyone understands the impact of interruptions on deep work and delivery goals. Quantifying that impact will make it easier to help your teams improve.

  5. Interrupt them less. You ping a manager for progress updates, they ask their engineers, and suddenly the entire team has switched focus. Consider this question before you reach out: Is it critical to product function, or are you just curious? 

Deep Work As a Means to Excellence

Change to work habits at the enterprise level all starts with gaining visibility. Organizations are often so large that it's difficult to see what's happening at the team level, let alone helping individuals manage their time. But we find that organizations that can help their developers prioritize deep work often see improvements in quality and performance metrics like change failure rate and number of deployments.

Schedule a demo to see how Uplevel gives engineering teams visibility into holistic quality, productivity, and people health metrics to meet commitments, deliver on time, and grow sustainably.

Stay up to date with Uplevel
news and resources