Stop interrupting your developers!

I mean, for the love of God. Do not allow anyone to interrupt your developers as they see fit. Period. Whether it’s about taking a look at the specification document “real quick”, fixing this bug “real quick” or explaining how to use this API “real quick”, your developers will need 10 to 15 minutes to start editing code after resuming work from an interruption, according to a study from Georgia Institute of Technology.

So if one developer gets interrupted 10 times a day x 10 minutes to get back to what they were doing, that’s 100 minutes, almost 2 hours, lost every day! Multiply this number by the number of developers in your organisation, and you get a picture of the lost productivity just because of “real quick” interruptions. And I’m not even talking about planned interruptions (meetings) and self-interruptions.

I mean, you’ve been there. You’re in the middle of deep work. Someone taps on your shoulder… and, it’s gone. So if it’s clear for everyone that interruptions are bad and have a major impact on a tech organisations’ productivity, why do we keep allowing them?

Why interruptions happen

Put aside the obvious (your developers are nice people and they want to help their colleagues), the modern workspace is actually organised to maximise interruptions. Open spaces where everyone is in the same room are like giant signs inviting to interrupt your colleagues. Phone calls, loud discussions and animated fussball games are no better. And if you think an unplanned interruption is bad, how about a planned one? If you know you have a meeting later today, your whole day is ruined because you unwillingly tailor it to make sure you finish your tasks on time. Paul Graham, the founder of Y Combinator, points out how meetings (a.k.a planned interruptions) can “blow a whole afternoon”:

For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from one task to another; it changes the mode in which you work.

What to do about it

When I was still managing my startup, our open space was like a monastery. Not a single sound for the most part of the day so all the makers (product managers, developers…) could focus on deep work. Interruptions were strictly forbidden, and this allowed us to really move the needle on our product. But how were people interacting?

We actually had 2 types of planned interruptions: office hours and time bomb meetings.

Office hours: that’s something I borrowed from my teaching activity at EPITA engineering school. As a professor there, I have office hours with my students every Tuesday. If they have a question, they can, of course, e-mail it to me but, if they want a face-to-face, they will wait until the following Tuesday. You can do the same in your company. At Basecamp, the project management software company, calendars are private and employees post “office hours” when they’re available for meetings.

Time bomb meetings: as an individual contributor, I hated meetings that lasted for hours (especially when no decision was taken at the end). So to make them really effective, each time we had to have a meeting, I brought in a big timer, with a 15-minute countdown. At the end of the 15 minutes, we’re supposed to make a decision.

Another solution is to promote remote work. At some point, 50% of my staff was remote and it was also a great way to protect the developers’ deep work moments. Of course, to make it work, you should enforce a strict Slack policy so that your team won’t get digital taps on their shoulder 😉