It had taken me the whole of morning yesterday to arrive at the strategy and algorithm we would be using for optimizing the performance of a database intensive application. To be sure that the algorithm will work and perform well under all scenarios, I was just trying to run it through various scenarios, on paper. As I was in the middle of one of the scenarios, someone tapped me on the shoulder and said, “I finished the system architecture document and it is there in the version control system, can you take a look at it when you have time?”. Ah, it was so painful and frustrating to look away from what I was doing. But I managed to smile and say “I will”. And I started to run through that scenario all over again 
That is a typical interrupt I am talking about. But interrupts can be of all kinds, some are really urgent while some can wait. But most often they tend to be productivity killers, specially in places where concentration and continuity are important. I had attended an interrupt management workshop a few years back. It was enlightening to realize how much we can gain in terms of productivity with proper interrup management protocols.
The most common problem about interrupts is the choice of meduim. Most often people choose to interrupt (or lets say, communicate) through the wrong medium. For example, the person who asked me to review the document wanted me to review it when I got time, but still chose a face-to-face communication over an email that would have been sufficient. The only way out in the long run is to have everyone learn interrupt management. For example, we now have an urgency-status attached to each mode of interrupt. The highest being a verbal face-to-face communication, and the lowest being an email. There would be others in between, like a phone call or an intant message. So before we decide to interrupt someone, evaluating how urgent it is, can help us choose the correct medium.
The other aspect is to allow for less in-your-face interrupts yourself. Like, not having those popup email alerts that say “You have new email”. I assume unless you are waiting for an email or are in a job where each email is super urgent, one does nto need that alert. And in most cases, even synchronizing with the mail server should be put off to every 10-15 minutes only. And if something is very urgent, people will actually call/meet you.
Then there is another thing we had tried, using a DND hour. This typically shows best results when the team is very large. We just defines a couple of hours in the day when you should nto interrupt your colleagues, unless really critical and cannot wait. Of course, each team member had the flexibilityt o decide if they wanted to participate so that nobody interrupts you during the DND hour. And for the large team it paid off, most of the programmers said it increased productivity and allowed better scheduling of discussions. But as always this is really a matter of the work culture you adopt in your organization and whether you see this as a good practice.
