A client emails you on a Friday afternoon. "Quick one. How do I change the font size on just one word in the footer?"
Simple enough. You point them to the editor, explain inline styling, and move on. Half an hour later, another email: "Great, and how do I make it bold and red?" Then another: "Can I add a link to just that word?"
So you get on a call. Turns out they're trying to add a legal disclaimer to the footer. They didn't ask about that because they'd already decided the best approach was to manually style individual words inside the existing footer text. They were asking for help with step four of a plan you never saw steps one through three of.
This is the XY problem. It's one of the most common communication patterns in technical work, and once you notice it, you'll see it everywhere.
The short version
Someone has a problem (X). They decide on a solution and start working through it. They get stuck on a specific part of that solution (Y). They ask for help with Y. You answer Y, but Y was never really the problem.
The term has been floating around developer communities for years. The XY Problem website describes it simply: you want to do X, you think Y is the best way, so you ask about Y, but Y might not even be a good approach to X.
The key thing is that nobody does this on purpose. The person asking isn't being difficult. They've just already moved past the problem in their head and are deep in their attempted solution by the time they reach out.
You've definitely seen this
The file extension question. Someone on Stack Overflow asks how to get the last three characters of a filename. The answer is substr($filename, -3) and it works. But they actually want the file extension, and now their code silently breaks on .jpeg, .html, and every file with a dot in its name. What they needed was pathinfo(), but nobody knew to suggest it because nobody knew the real problem.
The CSS rabbit hole. A colleague asks how to set a fixed height on a div. You give them the answer. An hour later they're back, asking how to deal with overflow. Then how to hide a scrollbar. Then how to make it work on mobile. Eventually you find out they're trying to keep two columns the same height, and the actual answer is three lines of flexbox. But by the time they asked for help, they were four workarounds deep into a position: absolute approach and every question was about the workarounds, not the layout.
The PDF request. A client asks for the best way to convert their web pages to downloadable PDFs. You start researching headless browser solutions, Puppeteer configs, page-break CSS. Then in a meeting they mention it's because "visitors need to be able to print things properly." They don't need PDFs at all. They need a print stylesheet, which is a fraction of the work.
The "quick database question." Someone in Slack asks how to write a SQL query that joins four tables and filters by three date ranges. The query is genuinely complex and you spend twenty minutes helping them get the syntax right. Later you find out they were trying to check whether a single user had logged in this month. There was already an API endpoint for that.
In every case, the question made sense on its own terms. The answer was technically correct. But it was solving a problem that didn't need to exist.
Why everyone does this
It's easy to read those examples and think "well obviously you should just ask about the real problem." But there are good reasons people don't.
They've already invested time. If you've spent an hour going down a particular path, asking about that path feels natural. Stepping back to square one feels like admitting the hour was wasted.
They're trying to ask a focused question. Developers especially are trained to ask specific, narrow questions. "How do I get the last three characters of a string?" is tight and answerable. "I'm building a file upload system and I need to validate extensions and here's my whole architecture" feels like too much. So people trim the context, and the context was the important part.
They don't know they've made an assumption. The client asking about PDF conversion genuinely believes the problem is PDF conversion. The gap between "people need to print our pages" and "we need to generate PDFs" felt like a logical step, not an assumption. You can't question an assumption you don't know you've made.
They're being considerate. A lot of XY questions come from people trying not to waste your time. They've already done the thinking (they think) and just need help with one small piece. The instinct is generous even if the result is counterproductive.
Understanding this matters because it changes how you respond. This isn't a problem you fix by telling people to ask better questions. It's something you navigate together.
What to do about it
The awkward thing about the XY problem is that you can't always tell you're looking at one. Sometimes the person asking about substr() genuinely just needs substr(). Redirecting every conversation to "but what are you really trying to do?" gets old fast and makes you insufferable.
A few things that work in practice:
Answer the question they asked, then get curious. "Here's how you'd handle that. What's the bigger picture here? There might be a shortcut." This respects their time and intelligence while leaving room for the real problem to surface. If there is no deeper problem, you've just helped them and moved on. No harm done.
Watch for the tell. The biggest signal is when someone asks a very specific technical question with zero context. "How do I parse JSON inside an XML attribute?" is almost never the whole story. When a question is weirdly specific and the use case isn't obvious, it's worth asking what they're building before diving in.
If you smell a rabbit hole, say so. When you're three messages into helping someone and each answer spawns two new questions, that's a pattern. It's fine to say "I think we might be solving the wrong thing here. Can you walk me back to what you're trying to achieve?" Most people are relieved when you say this, not offended.
In client work, make it a habit. Some of the most expensive XY problems happen in proposals and scoping calls. A client asks for a feature, you quote it and build it, and three months later everyone realises the feature was their solution to a problem that had a much simpler fix. Getting in the habit of asking "what does success look like for this?" or "what happens if we don't build this?" catches these early, before they cost anyone real time or money.
Catching it in yourself
I do this all the time. The longer I've been stuck on something, the more likely I am to frame my question around my current approach rather than my actual goal. I'll spend an hour fighting a webpack config, then ask someone a very specific question about loader ordering, when the real answer is that I don't need that loader at all and there's a simpler way to achieve what I want.
The best check I've found is to write down what I'm trying to achieve in one sentence, without mentioning any tools, libraries, or technologies. Not "how do I configure nginx to proxy this request" but "I need this URL to serve content from a different service." If I can't separate the goal from the method, I've probably fused them together somewhere without realising.
It's a small habit but it's saved me from some impressively convoluted rabbit holes.
Further reading
If you want more on this, the XY Problem website is a concise overview with good examples. Eric S. Raymond's How To Ask Questions The Smart Way covers the broader skill of framing technical questions well. Some of the tone in that guide hasn't aged gracefully, but the substance holds up.
Top comments (1)
I'm sure you've come across this, even if you didn't know it had a name! Got any other good examples?