Someone asks "how do I get the last three characters of a filename?" You help, they struggle, and forty minutes later it turns out they wanted the file extension, which isn't always three characters, and the whole line of questioning was a dead end. This pattern is so common it has a name: the XY problem. People ask about their attempted solution instead of their real goal, and it wastes staggering amounts of everyone's time.
Key Takeaways
- The XY problem is asking about attempted solution X instead of the actual problem Y (the XY problem).
- It burns time because helpers solve a strange sub-problem that often can't even solve the real one (XY problem).
- The fix is to ask why: what are you ultimately trying to accomplish?
- It shows up in support tickets, code reviews, and how teams brief each other.
The Pattern
The XY problem unfolds predictably (the XY problem). You want to accomplish X. You don't know how, but you have a hunch that doing Y would get you there. You don't know how to do Y either, so you ask for help with Y. Now everyone helping you is confused, because Y is a strange thing to want, and they burn time solving it. Eventually it comes out that you actually wanted X all along, and worse, Y wouldn't even have solved X. All that effort was spent on a path that was doomed from the first question.
The insidious part is that the question sounds reasonable. Nobody asking about Y announces that it's a workaround for an unstated X. They present Y as the problem, so helpers answer Y, and the real issue stays hidden until someone thinks to ask why.
Why It's So Costly
The waste compounds because the person asking has already narrowed the solution space before anyone competent looked at the actual problem. They picked Y, often a bad approach, and by asking only about Y they hide the context that would let an expert say "don't do that, do this instead." A support agent, a senior engineer, or a teammate can only redirect you toward the good solution if they know the real goal, and the XY framing withholds exactly that (XY problem).
| What gets asked | What was needed |
|---|---|
| "How do I do Y?" | "I'm trying to achieve X" |
| A narrow workaround | The real goal + context |
| Help on a doomed path | Redirection to a better path |
| Time spent, problem unsolved | Problem understood, then solved |
A Concrete Version
A junior engineer messages the team channel: "How do I parse this specific log format with a regex?" A senior spends twenty minutes helping craft the regex. It half-works, edge cases keep breaking it, and after more back-and-forth the senior finally asks "wait, what are you actually trying to do?" The answer: "figure out how many requests failed last night." The real solution was a one-line query against the metrics the system already emits, no log parsing at all. Twenty minutes went to a regex that should never have existed, because the question was about X, the attempted fix, not Y, the goal.
The Honest Counterpoint
"Always ask about the real goal" can be overdone into interrogating everyone who asks a simple question. Sometimes X really is the question: an experienced engineer who's already reasoned through the problem may genuinely just need the syntax for Y, and demanding they justify their whole objective is condescending and slow. The skill is calibrated curiosity, a quick "what are you ultimately trying to do?" when a request smells like a workaround or the asker seems stuck, without turning every quick question into a discovery interview. Trust experience; probe confusion.
What This Means for Teams
The XY problem is really a communication skill, and it cuts both ways in a team. Good engineers ask for help by leading with the goal and the context ("I'm trying to achieve X, I thought Y might work, here's where I'm stuck"), and good helpers instinctively check for the hidden X before diving into Y. That habit, surfacing the real problem before solving the stated one, is the same instinct behind rubber-duck debugging and clear async communication, and it's especially valuable on distributed teams where a misframed question can cost a whole timezone-lagged day. See available engineers.
Frequently Asked Questions
What is the XY problem?
Asking for help with your attempted solution (X) instead of your actual problem (Y). Helpers waste time on a strange sub-problem that often can't even solve the real goal, because the real goal was never stated.
Why does it waste so much time?
Because the asker narrowed to a (often bad) approach before anyone saw the real problem, and by asking only about that approach they hide the context that would let an expert redirect them to a better solution.
How do I avoid it?
When asking: lead with the goal and full context, rather than the workaround alone. When helping: if a request seems oddly specific or the person is stuck, ask "what are you ultimately trying to accomplish?" before diving in.
Should I always ask people to justify their question?
No. Sometimes the narrow question is exactly right, and interrogating an experienced person is slow and condescending. Probe when a request smells like a workaround or the asker is clearly stuck, and trust experience otherwise.
The Bottom Line
The XY problem wastes time because people ask how to do their workaround instead of what they're actually trying to achieve, hiding the context that would unlock a better answer. Lead with the goal when you ask for help, and check for the hidden real problem when you give it. One question, "what are you ultimately trying to do?", saves more engineering time than almost any tool.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
