Give your developers what they need: Uninterrupted time

Everyone knows that interruptions are productivity killers, but how do distractions apply to software developers, and how can we help developers minimize these interruptions and accelerate software velocity?

John Jenson

By John Jenson

Like many of us, I split time between multiple projects every day, and each has its own deadlines and complexities. While it sounds easy to divide time and attention throughout the day, we all know that it’s hard. Mental stamina and a productive headspace are both essential, especially when working on extremely complex tasks. Loading the moving variables of a particular problem into our brains takes time and focus. As developers typically work on highly complex tasks, mental context switches are especially costly. I have talked to dozens of developers about this, and all agree that once you are in a zone, it is costly to disrupt it.

Minimize context switches to increase velocity

If we can create a process to minimize context switches, everyone wins. Not only do leaders love a productive team, but developers – like anyone – are happiest when they gain a sense of accomplishment from completing work on time, on budget, in the highest quality way. This focus creates an environment where speed, quality, and innovation can flourish.

Let’s put aside the good feelings that come from productivity, and try to quantify the cost of an interruption. I’ve heard that every interruption results in a 15 minute loss of productivity. While I’m not sure of the scientific validity here, this seems pretty accurate to me. It’s helpful to differentiate between interruptions that aren’t a problem; those with little impact; and the mental hijackers that steal our headspaces.

Some interruptions are not a problem. For instance, if a coworker stops by to ask if I’m still planning on lunch, a simple “yes” will do, and I can respond without losing focus. When certain interruptions come at just the right time, they provide a needed break from intense focus. But meetings as well as other routine initiatives are more intrusive.

It’s similar to being deep in a book, or watching an intense movie. How easy is it to put the book down or turn the show off? Being interrupted while in a good coding groove is like having your TV cord yanked out of the wall during the final scene of a movie. Once disconnected, it is hard to get the musing flowing again. These mental energy expenditures result in productivity loss, which slows velocity and may even impact quality.

Context switches we can control

While many interruptions are outside of our control, the frequency and length of the following activities are within our control:

  1. Meetings
  2. Knowledge Sharing
  3. Code reviews

Each of these activities requires mental context switches when initiating and completing them. If you could skip every meeting, and avoid answering questions (knowledge sharing) for an entire day, your productivity would increase and your project would benefit. My colleagues do this periodically, and it pays off. While we can’t do this on an ongoing basis, managers should give developers long spurts of uninterrupted time when possible.

Adjusting your process to reduce meetings for developers, or grouping meetings together, will improve productivity and velocity. I will talk more about meetings, knowledge sharing, and code reviews in my next posts, but generally speaking, less is more. Less meetings, less code reviews, and less knowledge sharing leads to greater developer productivity. It’s definitely a balancing act – but one that’s worth doing in an era where speed counts.

Everyone knows that interruptions are productivity killers, but how do distractions apply to software developers, and how can we help developers minimize these interruptions and accelerate software velocity?

John Jenson

By John Jenson

Like many of us, I split time between multiple projects every day, and each has its own deadlines and complexities. While it sounds easy to divide time and attention throughout the day, we all know that it’s hard. Mental stamina and a productive headspace are both essential, especially when working on extremely complex tasks. Loading the moving variables of a particular problem into our brains takes time and focus. As developers typically work on highly complex tasks, mental context switches are especially costly. I have talked to dozens of developers about this, and all agree that once you are in a zone, it is costly to disrupt it.

Minimize context switches to increase velocity

If we can create a process to minimize context switches, everyone wins. Not only do leaders love a productive team, but developers – like anyone – are happiest when they gain a sense of accomplishment from completing work on time, on budget, in the highest quality way. This focus creates an environment where speed, quality, and innovation can flourish.

Let’s put aside the good feelings that come from productivity, and try to quantify the cost of an interruption. I’ve heard that every interruption results in a 15 minute loss of productivity. While I’m not sure of the scientific validity here, this seems pretty accurate to me. It’s helpful to differentiate between interruptions that aren’t a problem; those with little impact; and the mental hijackers that steal our headspaces.

Some interruptions are not a problem. For instance, if a coworker stops by to ask if I’m still planning on lunch, a simple “yes” will do, and I can respond without losing focus. When certain interruptions come at just the right time, they provide a needed break from intense focus. But meetings as well as other routine initiatives are more intrusive.

It’s similar to being deep in a book, or watching an intense movie. How easy is it to put the book down or turn the show off? Being interrupted while in a good coding groove is like having your TV cord yanked out of the wall during the final scene of a movie. Once disconnected, it is hard to get the musing flowing again. These mental energy expenditures result in productivity loss, which slows velocity and may even impact quality.

Context switches we can control

While many interruptions are outside of our control, the frequency and length of the following activities are within our control:

  1. Meetings
  2. Knowledge Sharing
  3. Code reviews

Each of these activities requires mental context switches when initiating and completing them. If you could skip every meeting, and avoid answering questions (knowledge sharing) for an entire day, your productivity would increase and your project would benefit. My colleagues do this periodically, and it pays off. While we can’t do this on an ongoing basis, managers should give developers long spurts of uninterrupted time when possible.

Adjusting your process to reduce meetings for developers, or grouping meetings together, will improve productivity and velocity. I will talk more about meetings, knowledge sharing, and code reviews in my next posts, but generally speaking, less is more. Less meetings, less code reviews, and less knowledge sharing leads to greater developer productivity. It’s definitely a balancing act – but one that’s worth doing in an era where speed counts.

Interested in partnering with us?

Send a message and we will work with you to understand your needs.

Related Insights from Our Experts
Related Consulting Solutions

Journey Mapping

Visualize your customer’s pain points and gaps, and create the future state customer journey. We put our tried and true journey mapping methodology to work to align your organization around your customer and use our Cora Journey360 platform to help create, store and share these assets.

Customer & User Research

Ground your CX initiatives on real insights uncovered via contextual inquiry.

2019-01-16T09:23:39-04:00