They say there are no dumb questions, but there are plenty of unnecessary questions.
I know you’ve had the experience: you’re deep into a programming problem when you’re suddenly brought up short by a someone asking you some trivial question. It takes you five seconds to answer the question and twenty minutes to rebuild your mental stack.
As a software engineer I’ve spent too many years trying unsuccessfully to educate managers and co-workers that interruptions like this are expensive. I’m not talking about legitimate questions, ones that only you know the answer to, ones that truly block the person asking. I’m talking about the silly questions that common sense or thirty seconds with Google could answer. These interruptions impair productivity on top of being just plain annoying.
Here’s my all-time “favorite” example; see if it reminds you of a similar experience. I was working feverishly on a critical bug that might sink the company. I was deep in the code. I had put on headphones and barricaded my cubicle door to forestall intrusions on my mental space. Naturally, despite these clear signals that I really didn’t want to be interrupted, a co-worker did just that. Are you all barricaded in there, he wanted to know, because you’re working on that big bug? “Yes,” I said, seething, “So what do you want?” To which he replied, and I’m not making this up, “Oh, nothing. I was just wondering what you were up to.”
They never did find his body.
In the Air and Under the Sea
Wearing head phones, putting tape across our cube doors, looking annoyed at frivolous questions, these clear signals do not seem to faze the people bent on interrupting us. All right, let’s accept the fact that techniques like these don’t work. When something doesn’t work it’s time to try something else. The trick, of course, is discovering a promising “something else” to try. I find that drawing analogies is a powerful way to discover and import solutions from other domains that I can try out to see if they can be usefully applied.
Trying to find such an analogy to the problem of interruptions for knowledge workers, I thought about various types of workers who are successful in not being interrupted. Yes, such workers actually exist. Let’s consider a few of them and see how they perform this miraculous feat. We can then see if they have come up with any tricks we poor software engineers can borrow.
The first type of worker that comes to mind is an underwater welder (to my mind, that is: I used to live in Hawaii). If someone wants to ask an underwater welder for a status update or to attend a meeting or to answer “a quick question,” they are going to have a wait on their hands. Absent an underwater communications line, the interrupter will have to cool their heels (perhaps, under the circumstances, literally) while they wait for the diver to decompress, return to the surface, and remove some dive gear before they can get an answer to that “quick question.”
Another example is a construction crane operator on a high-rise. While it’s possible or even likely that this crane operator has a walkie-talkie, consider the case where his manager wants a face-to-face meeting (because managers like that sort of thing). Once again, the manager is going to have to wait for the crane operator to set down whatever object he’s moving, climb down to a location where there’s an elevator, and descend to the ground. As before, the person asking the question has to wait a substantial time before getting what they want.
Now compare these examples with the case of a manager interrupting a thought worker. Here’s that scenario in full:
The manager walks in and starts talking.
The manager gets basically instant gratification of their desire for communication. The thought worker sits there in frustration and spends the next twenty minutes trying to reload their brain cache with what they were doing.
The advantage that the diver and crane operator have is that the burden of delay is shared between them and the person asking the question. Yes, the worker is delayed, but so is the manager wanting to talk to him. This manager is aware that asking the question is going to cost him thirty minutes. He probably doesn’t have any idea how much time it will cost the worker, but he has to know that there will be some cost. This presumably makes him think about interruptions before perpetrating them.
The people interrupting us generally have no such awareness. The cost to them of the interruption is effectively zero. They do not see the recovery time we have to expend, they just see that interrupting us was free to them.
Sharing the Pain
An obvious question is, how can we make these people aware of the cost they are inflicting upon us? Although obvious, it turns out that this is the wrong question, which is why solutions predicated on this question tend never to work. A better question is, how can we offload some of the cost onto the interrupter so that it becomes in their own best interest to limit their interruptions?
One technique that some of us use, probably without being especially aware of why we do it, is to hold up a hand when the person starts talking to us, and to continue to do our work for a moment or two. This simple trick can be surprisingly effective. When it works, we are forcing the person to wait for a few seconds while we finish the sentence, trace one more statement, or in general try to page ourselves to memory.
It’s educational to observe the reaction of people you put on hold in this way. They generally act surprised by this unexpected turn of events. It’s almost as if your hand has pinned them to the spot. They can’t very well keep talking, as you’ve made a completely reasonable and civilized request for a very short delay. They also seem to feel that they can’t just walk away, as the conversation has already started.
(Would I be bad if I admitted that I sometimes extend this moment, enjoying a slight discomfort on the part of the person interrupting me? I would? Then never mind.)
Imagine if this technique were formalized and that we went so far as to install a timer at the entrance of our cube. Imagine that a questioner had to press a button and hold it for thirty seconds—or one minute, or two minutes. At the end of this time a bell would ring and they could then start talking. The social rule would be that you were free to ignore them until the bell rang, but after that you had to give them your complete attention. We would have accomplished the goal of sharing the pain of the interruption with the interrupter.
I can imagine work environments where such a device and rule could be implemented successfully. I can also picture work environments where it would never fly. But even there perhaps some different implementation of the same principle would work.
How many fewer questions you would get if people knew they had to wait for a minute before they could interrupt you? I’m willing to bet that the number of in-person questions would drop dramatically while the number of questions by email or IM would increase—although not by the same amount. Some portion of the questions wouldn’t get asked at all. Knowing that they would be subject to a pause before asking the question might encourage people to do a quick Google search rather than interrupting you.
There are many other ways to share the pain. I recently implemented one by moving my cube to an unused area of our office that’s about a thirty-second walk from most of the other developers. This little thirty-second cost to ask me a question has dramatically cut down on the number of “quick questions” that I get.
A more drastic version of this is to disappear. At one point my manager suggested that I take my laptop and find an unused conference room or spot in the lab to hide out in. For me, that tactic wouldn’t have worked. Aside from it being a tacit admission that our developer culture was broken, it would also have forced me to leave my development environment. I’m blessed with dual 19-inch LCDs on my laptop (to read specifications, JavaDocs, Google etc.), plus another pair of big LCDs on my Linux development box for Eclipse/Mylyn. I didn’t want to leave all that for a laptop screen sitting in the corner of a closet.
But hiding out does work for some people. The editor of PragPub tells me that he has two offices: one among other people where it is understood that he can be interrupted, and another about thirty seconds away in a separate, otherwise unoccupied building with LAN and internet connections but no phone, where he goes to work uninterruptedly.
And despite my total lack of luck with them, you can always try the sign on the door or the tape across the cubicle opening or the sliding mesh barrier. Each of these relies on the good will and common sense of the interrupter. This means that they should work in some settings—but in my experience they only work with the people who wouldn’t be likely to ask a frivolous question in the first place.
Of course, we need to be interruptible some of the time. I’m not antisocial: I run a technical book club in my group and am generally seen as a mentor for developers. I actually love answering questions—but only after the person has invested at least a minute trying to answer the question themselves.
Here’s one more perspective that you might find useful. Think of interruptions in terms of negotiating. To me, and probably to you, time and attention are really the true currency. Anytime someone wants some of my limited time and attention, we enter a negotiation. An interruption is a tacit statement that my time is less valuable than the time of the interrupter. So it’s in general a bad deal, but I am far more willing to accept interruptions from people who have provided information to me in the past. The trade routes are open, so to speak. I’ve told a select few people in my company that they can always interrupt me, even if my headphones are on and the door is closed, because they’ve saved my butt in the past.
These are some of the strategies I have come up with to reduce interruptions. You may know of others. If you find a good one, be sure to share it with your co-workers. Just don’t interrupt them.
Brian Tarbox is a Principal Staff Engineer at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com.