When Should I Interrupt Someone?

I had one developer who was VERY smart but would ask for help at the smallest problem. Usually I'd be able to help him fix it in 5 minutes, or he'd rubber duck it himself explaining to me. So what I did is he'd IM me if asking if I could stop by, I'd say sure let me finish this code I'll be over in 15. Five minute later I'd get an IM saying n/m I fixed it. I'd ask him about it later in the day so he didn't feel ignored. I think it worked out pretty well for both of us.

As the senior most developer on my team, I want you to interrupt me as soon as you need help. It is a far better use of everyone's time to get you on the correct track right away. I tell this to every developer on the team, and especially the junior developers. In a sense, since I helped designed and write many of the systems, I view it as my main job to assist other developers so they can do their job to the fullest extent.

I have two rules for interruptions:<p><pre><code> 1. Please do, but 2. If I signal that I need time, respect that. </code></pre> #2 is the flip-side of interrupting: Don&#x27;t persist if there are any signs you should not.<p>I am more than willing to help people with their problems, and I love answering questions, teaching, providing advice, discussing thorny problems...<p>...but I won&#x27;t countenance an &quot;interrupt&quot;: Come to my office, knock on my door, say my name, whatever, but if my hand shoots up with the &quot;Just a moment&quot; index in the air, respect that.<p>If I do that, it&#x27;s because what I have in my head will take me far too long to regain once lost - and the interruption will blow it up.<p>I need to checkpoint. Maybe even solve. I need anywhere from a few seconds to an hour (and, yeah, I may forget you were there, foibly human and all that).<p>Pretty much everyone I&#x27;ve ever worked with has learned that I have all the time in the world for them, except when I don&#x27;t, I will let them know when I don&#x27;t, without being rude (well, perhaps debatable, it is the barest acknowledgement), and when I can I will give them all I can.<p>Unless you persisted. On a good day, when I am feeling open and relaxed, hopefully we can talk about how to manage things differently, figure out a way that works for us.<p>On a cross day, an impatient day, I will kill you with fire. Metaphorically. Being a foibly human. Who sometimes overvalues his time. We are both likely to regret this. Hopefully we will find occasion to laugh about it later.<p>(Over the decades, the &quot;just a moment&quot; finger comes up less often, at least in part because I&#x27;ve learned those thoughts I was holding were neither so valuable nor so fragile as I once thought. Often, it barely starts to rise and I&#x27;ve already shifted gears, caching things away for later. I had to teach myself that because I really do prefer taking the interrupt and helping to breathing flame.)

I was in architecture for years, and I would help anyone who came to me on one condition. They would need to go back to their desk, and write up a 3 paragraph description of their problem, what they tried, and where they were stuck. It has a lot of benefits.<p>1. It weeded out the people who wouldn&#x27;t invest anything.<p>2. It let a good 25% of the engineers &quot;rubber duck&quot; their way out of a problem.<p>3. When the problem got past the first two filters, the problem was much better defined when we worked on it together.

“When you seek advice, first write down everything you’ve tried.”<p>Remote working has made this super easy as often the way of reaching out to people is with a Slack message or equivalent. So many times over the past year I’ve answered my own question as I type out a lengthy Slack message explaining a problem to someone.

I resent doing other people&#x27;s work for them, I don&#x27;t resent helping them when they can no longer help themselves.<p>Interrupt me after you&#x27;ve tried as many ways as you can to solve the issue, and present them to me so either I can determine the remaining set you haven&#x27;t tried or we can brainstorm. It shows initiative and thoughtfulness and creates a starting point for our solutioning.

I read the headline and thought this was going to be about interrupting someone during conversation.

I advocate a twenty minute rule. It&#x27;s not hard and fast, but shouldn&#x27;t be more than an hour, and shouldn&#x27;t be less than 20 minutes.<p>This is the amount of time the person needing help should try to solve it themselves. After that they should write down what they&#x27;ve done (they should be doing this anyway in an engineering notebook or worklog file), and then ask for help.<p>The delay is to make sure an attempt is made to solve it themselves. It&#x27;s long enough to get them to try to understand the problem, and short enough to not put them far behind.<p>I&#x27;ve also found that if they need to get help often then it&#x27;s not their problem, but the problem of who is tasking them. Their tasking, or the context of that tasking, is probably not being communicated well, or might not be defined well-enough.

I created 3 slack emojis to signal this more clearly:<p>1. I’m thinking harder about this thing but not blocked.<p>2. I’m still not blocked, but could really use a pair right now.<p>3. Actually stuck.<p>They basically act like andon cords for my quality of understanding of a task.

This is interesting. We’ve arrived at a very similar set of guidelines on our team. One slight difference is that sometimes people want to reach out to a senior person not so much because they’re “stuck” in the middle of something, but before they even start on some new feature or development story. They want help with design or help with even determining what approach to take. Similar to the author’s suggestion to ask them what they’ve already tried, we ask for them to do their best to propose a solution, and then we go from there. That way they’re still in the drivers seat, and we evaluate the pros and cons of their approach so they get meaningful feedback for improvement.

When I interrupt people, I make sure I have exhausted all avenues of finding the answer, and I tell them exactly what steps I tried. If they see that I’ve put in significant effort, then it usually assuages any issues with them being interrupted. In a similar way when people interrupt me, I like to see the same.

I have a different answer to this problem. If you get stuck, send me an email and work on something else for a while. That way I don&#x27;t get interrupted and you get your answer. Asynchronous communication is great.

Turning this question on its head:<p>What should I do when someone asks for help?<p>Coach, don&#x27;t fix.<p>If you help someone find the answer to a problem, and give them the support they need to learn, you&#x27;ll find that you both resolved the underlying issue, and that you gave them tools they need to become better at what they do. You&#x27;ll also set an example for them when someone comes to them for help.

It is far more likely you&#x27;re waiting too long than not long enough if you&#x27;re thinking about this at all, imo.

If you instantly &quot;escalate&quot; your problem to your teammate without having made an effort it gives the impression that you don&#x27;t respect their time or concentration.<p>So make an effort first so that when you go to your colleague you can tell them a few things that you have already tried. You may find an answer before you need to go to them. And if you don&#x27;t find the answer the list of things that you have already tried can help set the context and help your colleague to help you better.<p>This is particularly important if the problem is easily google-able. If you keep going to your colleagues for help and they search a few keywords on google, go to the first result and show you the answer right there that&#x27;s the sign that you are not making and effort to solve it yourself first.

&#x27;when should I ask for help&#x27; might be a better title.<p>Each org I have seen is a bit different. Some projects just seem to be more geared towards gurus (aka, the software is wonky, no way anyone could know about that without asking).

As someone who has been on both sides of the problem I think something thats really important is making sure you write down notes after you received help and at the very least make sure you searched the code and documentation for relevant information. Its frustrating when you take time to write documentation or code comments and they are blatantly ignored.

Having some sort of &quot;office hours&quot; seems to solve this problem. I&#x27;d allocate certain office hours that I was willing to assist other employees. This policy was implemented when I was unable to concentrate on my work as a result of being interrupted too frequently.