One of the common frustrations in IT support – other than customers who don’t realise their hardware isn’t plugged into the wall – is spending 45 minutes trying to figure out what the person is actually trying to do. This happens because, often, people will ask for help based on their attempted solution (“I’ve tried X, and it’s not working.”) rather than the underlying problem (“Y has gone wrong. Do you know what might be causing it?”)
They call this the XY Problem. It was coined by American software developer Eric S Raymond, it’s an easy trap to fall into. Both for users and IT professionals.
What is the XY Problem?
The best way to explain the XY problem is to offer an example. Imagine your car won’t start. Instead of calling a mechanic and getting them to diagnose the actual problem, you assume it’s a flat battery, so you call your friend and ask for a jump-start. Only it turns out the problem wasn’t the battery after all. You’re back at square one, and now your friend’s involved too! If anything, you’ve just made things worse.
The XY problem is when a user thinks they have a good understanding of their problem (Y), and try to fix it by doing X. When X doesn’t work, they ask for help with X, not Y. See the issue?
Eric S Raymond put it this way:
“If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation.”
How do I get around it?
The first step is not to assume anything. Remember, you’re trying to find the underlying problem, then a solution. Never the other way around. If a user comes to you and says “My Y won’t start, so I’ve tried X, and it’s not working. Can you come and help me with X,” that’s a red flag that something else is going on.
Author Laurence Enderson has a good quote that’s relevant here: “We can be too quick to blurt out what we believe are the correct answers, when more value can be gained by searching for a better question.” What he means is, you must go in with an open mind, and a curious mindset. Don’t take anything for granted.
So, what’s the one, important question you need to ask?
The magical IT support question
The magical IT support question isn’t “Have you tried turning it off and on again?” (which, we’ll admit, solves more tickets than you’d expect). The question is: what are you trying to do?
Simple as that. What are you trying to do? What’s your actual goal? By getting users to explain their fundamental objective, you can quickly trace things back to their roots and start again. Here are some follow-up questions you can add to help the process along:
- How did the problem first occur?
- What were you doing?
- What were the initial symptoms?
- What happened?
- What steps have you taken to solve the problem so far?
- What was the outcome?
- Can we reproduce the problem now?
These questions are all useful, but without the first one – “What are you trying to do?” – they can all lead you down the XY path. You need that original objective because that’s the real problem you’re trying to solve.
Try and get people to be objective here, too. The only useful information is what’s actually happened, not what a user thinks might have happened. In other words, you need symptoms, not guesses, because symptoms don’t lie.
It’s also important to get the user to frame their problem in detail. The more detail the better. Don’t just settle for “The printer’s not showing, I can’t get it to work.” A better IT call might go something like, “I’m trying to connect this printer to the network, but it’s not showing up on the list of suggested devices. I’ve refreshed the list and re-started the WIFI, but nothing’s changed.”
See the difference? The first call lays out a problem, but the second call gives the support worker context, detail, an actual objective, and a couple of solutions that have already been tried. By getting the user to frame the question correctly, you’ve already saved yourself time – and future headaches.
