Put It Down And Come Back To It Later…

Taking A Break From Troubleshooting
Believe it or not, this is a legitimate troubleshooting strategy.
(image: Timothy Krause, license: CC BY 2.0)

You’ve probably been told at least once in your life:

“You should sleep on it.”

It’s a solid, common-sense thing to do before making a big decision. I sometimes imagine asking Wilford Brimley for advice and, besides sternly telling me to eat a healthy breakfast of whole grain oats, I bet one of his go-to nuggets is “sleep on it.” As I’ve hinted at before, troubleshooting has lessons for life, and conversely life’s lessons have something to teach the Troubleshooter. The benefits of “sleeping on it” are available in either realm: you gain perspective and insight by temporarily stepping away from your problems.

You may have implemented this strategy by accident. That is, you hacked away at something until you:

  1. Got too hungry.
  2. Got too tired.
  3. Got a call from your sweetheart, asking if you were coming home soon.

Circumstances forced you to take a break and so you put down your tools and came back to the problem later. You might have noticed that when you did return to the issue, after eating or sleeping or doing damage control for being late to dinner, frequently the solution was staring you in the face! Why is this?

While you were distracted, your unconscious mind was doing some work on its own in the background. The “why” and “how” hasn’t exactly been nailed down yet, given that the science on the unconscious mind’s problem-solving abilities is an area of ongoing debate and research. Beyond a vague notion that some kinds of complex mental tasks may benefit from either conscious or unconscious processing, the understanding of why (especially on the level of what is actually happening in the brain) is probably a long way off. That’s okay though, we don’t have to understand how electricity works in order to benefit from its use. In the context of sleep, we know that unconscious processing is critical to the consolidation of memories in the “acquisition → consolidation → recall” model of learning. It also makes it clearer why your perspective is changed the morning after you’ve “slept on it”: you probably assimilated a lot overnight! Troubleshooting can involve a lot of learning, especially if the failure condition or system is new to you, so it’s not surprising that sleep is beneficial.

There’s also a concept called “fractionation,” used by hypnotists, that I also think is relevant here. Hypnotists know that to put someone deeper into a state of trance, it’s useful to take them out of trance temporarily. Then, when you put them back under, they’ll go in even deeper. Intense troubleshooting can closely resemble a state of trance: you’re very focused on the problem, often to the exclusion of the world around you. Sometimes, I’ve been working on fixing something and been concentrating so intensely that I didn’t even notice someone enter the room! However, a plateau will eventually be reached and the only way to get any further is to break your concentration, entertain a distraction and then go back. And, when you do, it’ll be deeper.

You might also be “looping,” trying the same thing over and over again with little progress. We usually think of being interrupted while working as a bad thing, and, in our high-tech world of fractured attention spans, most of the time I think that’s true. However, if you’re chasing your tail, an interruption can be very useful to breaking the pattern. In formulating this strategy, I was impressed by the number of times I’d be sitting in my office, “looping” on a problem and the phone would ring or someone would knock on my door. We’d chat for a few minutes and then I’d turn back to the problem and BOOM!, the answer would hit me.

If I may add something original to the observation that being forced to step away from a problem is useful when troubleshooting, it’s this: do it intentionally! Don’t wait for yourself to get too hungry or too tired or for that angry phone call to get some much-needed distance from a problem. That’s right, you will be a much more effective troubleshooter if you take regular breaks. Some people like to use a timer (e.g., the Pomodoro Technique) to know when to step away. I prefer a more open-ended approach based on how things are progressing: I now have a good sense for when diminishing returns of spending additional time on a problem have taken hold. For me, that’s the best time for a break. This ties in nicely with the research about the role of conscious and unconscious processes while learning: there is a point when you’ll become saturated on either front (most likely the conscious side). If you’ve noodled all day straight on a problem and are stuck, it’s unlikely you’ll make further progress without some intervening time away for unconscious processing (like sleep). To do that intra-day, I usually like to take a short walk. You can choose your own pleasant distraction.

If you’re a Type A fidgeter who must be busy every second and don’t think you can handle stepping away, try this instead: switch to a different aspect of the problem. Move on to another component or subsystem that needs inspection, read the manual, collect some data, or do some research on the Internet. You can also keep going by simply switching strategies which, after reading The Art Of Troubleshooting beginning to end, you’ll have many options from which to choose. Basically, do anything that will distract yourself from the thing you’re stuck on, so when you return to it you’ll see it with a fresh pair of eyes. Changing course is also good for those cases where it would be, how should we say, unprofessional to take any sort of break. In the middle of a crisis you can’t really tell a client who’s losing thousands of dollars every hour that you’ll be unavailable while you’re “fractionating.”

By the way, I followed my own advice while writing this: several times I came to an impasse, put it down, and came back to it later. I’m sure it’s better for it.

*** Questions? Comments? Have a related troubleshooting story that you’d like to share? Feel free to leave your feedback in the comments section below! ***

References

3 Comments

Add yours →

  1. I really like fractionating as often as possible…

    Like

  2. In my 30+ years of analyzing problems I have learned one absolute rule. When a client says “It was working fine and just quit. Nobody did anything, it just quit. There was a Tech here last month and he said everything was fine. I saw a Telecom Truck in our parking lot so it must have been caused by them.” In the majority of situations none of what was said had anything to do with the problem. The exception is “We have had Tech's from AT&T, Cisco, Verizon, the local Telco, and they all say “Their portion of the job has been tested and meets all requirements.” If you accept any of the above statements as fact you could find yourself spending hours and days trying to solve a problem that doesn't exist. Always, approach a problem with clear eyes. Assume nothing. Examine the situation, make notes, do some testing, take a break and read over your notes. When you return, the job is always easier.

    Like

  3. Anonymous, thanks for sharing your obviously hard-won experience as a troubleshooter.

    I absolutely agree that you must be cautious when evaluating problem reports from clients. See my article on the virtue of skepticism for more:

    https://artoftroubleshooting.com/2011/09/20/skepticism/

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: