When Should I Interrupt Someone?

How many times have you sat there trying to work through a technical problem, and thought:

Is it OK if I interrupt someone else to get them to help me?

—Pretty much every engineer ever

Since I work with companies that are in the process of moving to Cloud Native technologies, there is often a huge gulf in knowledge and experience between the “early adopters”/”pioneers” and the rest of the organisation.

Bridging that gap is a very costly process involving a combination of approaches such as formal training, technical mentoring, gentle cajoling, and internal documentation.

Very commonly, the more junior technical staff are very wary of interrupting their more senior colleagues, whose time is perceived as more valuable, and whose knowledge and experience can inhibit them from seeking help.

The problem

Most of the time this isn’t a huge problem, as engineers negotiate between them when it’s OK to interrupt by observing how often others do it, developing good relationships with their peers, and so on.

It becomes a problem when people are unable to feel safe to interrupt others. This might be because:

• They feel “left out” of the team.
• They feel like they ‘should’ be able to solve the problem themselves.
• They think asking for help is a failure signal.
• They don’t want to “waste others’ time.”

Of course, all of these reasons are related to psychological safety, so often cited as a core characteristic of high-performing teams. This article can’t solve a lack of psychological safety in your organisation, but seeks to help with one aspect of it. If you have rules around when and how it’s “OK” to ask for help, it can make you safer about seeking it.

If people feel unable to ask for help, they can (at the worst extremes) sit there sweating for days making no progress, while feeling under enormous stress about their work. At the other end, you can get employees that ask for help after getting stuck immediately, wasting others’ time as they have to explain their problem to someone, and very often fixing the problem themselves as they talk.

The rule of thumb

Early in my career, the first consultancy I worked with had a really simple rule for this:

If you’re stuck for over an hour, seek help.

This beautifully simple rule works very well in most contexts. It stops people sitting on blockages for days, and stops them from jumping out of their seat early in a panic.

A further piece of advice which I add to this is:

When you seek advice, first write down everything you’ve tried.

This has at least three benefits:

1. It acts as a form of rubber duck debugging. Very often, in the process of taking a step back and writing down what you’ve tried, you’ll see what you missed.
2. When you go to get help, you have evidence that you’ve gone through some kind of structured thought process before raising the alarm, rather than just asking for help as soon as the going got tough.
3. You will save time explaining the context to someone else you’ve forced to context switch.

An essay is not required. Just set down enough notes to explain clearly and concisely what problem you’re facing and what your thinking was about how to solve it.

The formula

The rule of thumb is simple and useful, but there are other factors to consider if you want to get really scientific about when and how it’s OK to interrupt others. If you’re in the business of knowledge work, every time you interrupt someone you reduce their efficiency, and cost your business money.

Bosses are notorious for being cavalier with their subordinates’ time, but there’s often a good justification for this: a manager’s time is worth more to the business than yours.

So I came up with a formula for this, embodied in this spreadsheet:

The formula takes in a few parameters:

• “Time taken thus far” (i.e., how much time you’ve spent stuck on the problem) (“T3F”)
• Time it will take to explain to someone else (“T3E”)
• The “interruption overhead” to the interruptee (“IO”)
• The relative worth of your time and the interruptee’s time (“RTW”)

This formula tells you whether it’s OK to interrupt, as well as how much time you should still spend looking at it before interrupting. The interesting extra parameter here is the “relative cost” of your time to the interruptee’s. This will be difficult to estimate accurately, but it can be set by the more senior staff as a guide to when they want to get involved in a problem. The last thing a more senior engineer should want is for their juniors to be spending significant amounts of time neither solving the problem nor developing their knowledge and capabilities.

The formula, for those interested is ...

Interrupt if: T3F > RTW (IO + T3E)

If you use it, let me know!

A version of this post originally appeared on the blog zwischenzugs.