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 reasons to do with psychological safety, so often cited as a core characteristic of high-performing teams. This article can’t solve that problem, 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:
- 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.
- 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.
- You will save time explaining the context to someone else you’ve forced to context switch.
An essay is not required. Just 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’s 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 inferiors’ time, but there’s often a good justification for this: their 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’ (ie 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”)
and 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!
If you enjoyed this, then please consider buying me a coffee to encourage me to do more.
zwischenzugs 
That’s really interesting, but what is really lacking is how do I know how to find out RTW?
Most companies don’t even have clear ranks. I worked with “Senior developers” who didn’t know why they were seniors, or they were really junior.
Indeed. Obviously this valuation is a very political process…
A simple rule of thumb you might use is 2x for each ‘level’ up, making it less time before you approach a peer than a superior. But in reality, you’d probably want to tweak this iteratively as you go per team.
You could define RWT as the ratio of your colleague salary / your salary.
That matches, by definition, what your company estimates is worth your manhour vs their manhour.
That could lead to some interesting revelations in most orgs…
Yeah. That is assuming all companies have open salaries. Most German companies I worked for have a clause in the contract that forbids telling other about the salary. And in general in Germany it is a very private thing.
So I’m all in for the theory but I don’t know how useful it is if I can’t calculate the ratio.
In the end it boils down to trust. If you know your colleagues well and you know what the work on, you know when it’s ok to ask.
I would never have thought of trying quantify this. What a great formula!