Rules Of Interruption

This thread started by Ross Chapman highlights an old problem.

What’s odd is that in the world of development teams where everything becomes a documented process, or code of conduct, or concensus of behaviour, this is still poorly handled.

In an ideal world, collaborative environments would have rules of engagement for conversation. However enforcing them across teams is next to impossible and lets be honest, you mostly come across looking like a dick.

But what would those rule look like if they did exist? Here’s my shot at them:

Update: It’s been pointed out that “Rules” sounds authoritarian. “Considerations” is probably a better term. However we only have to look at the daily Twitter misunderstandings to see that power of poor communication. So while I would stop short of printing this in red letters on every wall in an office, I would absolutely discuss this with team-members. Not everyone is naturally gregarious and human interaction is genuinely hard for some. Knowing the parameters and expectations can’t harm the interaction in a team, but ignorance could.

1. Plan your interruption

If you need to interrupt someone, literally plan your interruptive sentence word by word. What is required for your colleague to respond appropriately?

Do

  1. Be polite but terse.
  2. Say “May I interrupt you?”. Acknowledging the inconvenience can lower defenses.
  3. Include one or more of:
    • The urgency of the problem
    • Whether you’re blocked
    • An estimate of how much of their time you’ll need.

e.g “Hi Dave, may I interrupt you? I’ve need a 5 minute code review.”. “Hi Dave, may I interrupt you? I’m blocked and I need to ship this in an hour”.

Don’t

  1. Include forced pleasantries. Your colleague may already be annoyed, don’t waste their time with etiquette.
  2. Provide any technical detail. It’s a form of “earworm”, like saying “Don’t think of a cat”. The slightest whiff of detail will distract them however hard they try to focus.

2. You are always interruptible

But if your colleague has followed the steps above, you should be able to triage their interruption with minimal impact on productivity. Importantly: Having heard them out, you reserve the right to immediately postpone the interruption when necessary.

Many people suggest if you don’t want to be disturbed you should wear headphones. This works some of the time, but you’re neglecting your obligations to function as a team member. Your colleague needs their question answered. Are they to waste their own time repeatedly checking whether you still have your headphones on every few minutes?

Even if you’re focusing on a problem, you should be able to spare the cognitive capacity to politely reply “No problem, I’ll come and find you in 30 minutes once I’ve finished this” or “Please come over again in 30 minutes”.

3. Take responsibility for helping

If your colleague is blocked and their summary suggests it’s mission-critical, consider taking one for the team and dropping what you’re doing. Greater good and all that.

If you postponed an interruption and your colleague returns after the elapsed time, be aware that you managed to continue working. You got your shot, now give your colleague theirs.

4. Take responsibility for working without help

If you’ve got a problem that only Jane The DB Guru can help you with, tell her, then find something else to do. You can’t continue that work now, but Jane will help you if he’s signed up to these rules.

Your productivity has already hit rock bottom (why else did you need to interrupt Jane?) so the best you can do is to move onto something more productive in the meantime. A change of scene may give you fresh perspective to solve it on your own.

Feedback? Thoughts? Let me know.