XY problems: ask for the outcome
Aug 1, 2026
“Can I get admin access to the reporting database?” is a clear, courteous, decidable request. It is also not the real request. Somewhere upstream sits a need: walk into Monday’s 9 a.m. review with current numbers. Between the need and the asking, a chain of private reasoning has hardened into a proposed remedy—credentials. The recipient sees only the final link. Grant it, and you have introduced security risk to solve a scheduling problem. Refuse it, and you have solved nothing. Debate it, and you are now arguing database security with someone who has never run a database.
Programmers call this the XY problem.
X is the underlying objective;
Y is the requester’s proposed means of achieving it.
The problem arises when someone asks how to do Y
without disclosing that what they actually need is X.
The recipient is therefore invited to optimize, approve, or reject a solution whose purpose remains hidden. In this case, X is obtaining current numbers for Monday’s review; Y is acquiring database credentials.
The phenomenon has older, better names: design fixation, in which the first solution crowds every alternative from view; and goal displacement, in which the means quietly supplants the end. Marketing supplied the durable parable: nobody wants a quarter-inch drill; they want a quarter-inch hole. Call it solution fixation. The cure is not to have fewer ideas. It is to stop letting the first idea impersonate the need.
Fixation imposes a second cost, quieter and usually paid by the requester. A proposed fix is an accidental claim of expertise in someone else’s discipline. Ask for admin access and you have implicitly taken positions on permission models, audit exposure, and blast radius—positions you must now defend, in a vocabulary you do not speak, before the one person in the room who does. This is how untrained people find themselves trapped in technical arguments: not through presumption, but through phrasing. The request conscripts them. Medicine has observed the pattern for centuries. The patient who demands a drug must argue pharmacology; the patient who describes the symptom need only be truthful.
Every request can be spoken in one of two languages. There is the system’s language—the language of statuses, permissions, schemas, and mechanisms—and there is yours, the ordinary language in which Monday mornings, missed deadlines, and board presentations occur. A Y is a sentence written in the system’s language by someone who does not live there. The exercise on this page reverses the translation. It carries the request out of mechanism and back into purpose: the one register in which you are fluent, authoritative, and impossible to out-argue. X is not a different request. It is the original request, recovered before the proposed solution took possession of it.
For the curious—the sheet works without the theory. The ring is the machine a well-formed request enters: here an emergency department, but every competent institution draws the same shape. The case is accepted at the green port in the vernacular—a complaint, a symptom; in your world, a bug report—and the institution descends the register scale into its DSL only on the interior, surfacing back into plain language at the exit. Both ports face outward; the DSL never reaches the doors. A Y-shaped request is an attempt to enter at the bottom of the ring—the patient arriving with the prescription already written, the commit handed across the front desk—and it skips the differential, the one station that could have said whether Y actually treats X. The ladder below runs the same scale the other way, because that is where you are starting: fluent in the fix, climbing back up to the outcome before you knock.
The tell is always the same shape: one specific mechanism, presented as the only obvious path, with no world around it. Fixation is compression—the requester did real work, felt a problem, imagined a fix, and then shipped only the fix, because the fix is shorter and feels actionable. What compression discards is the history: the problem, the constraints, the alternatives never weighed. Putting the history back is mechanical. Start by writing the fix down.
Five short steps, about three minutes. Nothing leaves this page until you copy it.
Write the fix you were about to ask for
This is your Y — exactly as you would send it, in the system’s language.
Tracing runs on one question: so that you can…? Ask it of your fix and write the answer. Each rung is a step of translation: if the answer still speaks the system’s language — a status, a button, a permission — it hasn’t left the technical register, so ask again on the next rung down. Stop when the sentence has gone fully vernacular: a result for a person, with no system nouns left in it, something you would still want even if the fix above never ships — something a stranger to the system would understand completely. That bottom rung is X, the requirement in your own language. Everything above it, your fix included, has just become a candidate.
Ask “so that you can…” until you reach X
One or two rungs is usually enough. Stop when the sentence is fully vernacular — no system nouns left.
A good place to stop: you’d still want this rung even if the idea in step 1 never ships, and no system word is left in the sentence. When one reads like that, mark it as the outcome.
The receiver can’t weigh X without the world it lives in — what happens today, who it happens to, what it costs. This is the half of the request only you can supply.
Describe today without the fix
Who hits it, how often, what it costs. Rough numbers are fine.
Fixation survives on “only way.” You don’t break it by liking the alternatives; you break it by being able to name them. Write two other routes to X — producing siblings for your fix is what demotes it from destiny to option.
Name two other routes to the same X
They don’t have to be good — only possible. That demotes your fix from destiny to option.
What you send is a small contract. You own whether X is real — the problem, its cost, why it matters. The receiver owns the mechanism: the design, the tradeoffs, the side effects one change can have three systems away. You get your outcome guaranteed rather than your mechanism humored; they get a requirement instead of a design order. The split sorts the conversations, too: every question that can now come back at you — is it really an hour, really every Monday? — is a question about your own world, answerable with no training at all, while the schema, the permissions, and the side effects stay between people equipped to argue them. And because the request names X, it is falsifiable — when something ships, anyone can check whether the Monday hour actually came back.
Copy the request — outcome first
X leads. Your fix rides along as one candidate.
Your fix rides along as one candidate. Whoever owns the system owns the mechanism; you own whether the outcome is real.
On the receiving end, run the same trace in reverse—the same push, pointed the other way: don’t meet the request in the system’s language until it has existed in plain language first. Get X owned out loud before any solution talk—“so the goal is current numbers by nine, yes?” Ask them for three routes rather than proposing your own, because a counter-proposal starts exactly the ego fight the trace exists to avoid. And pressure-test their Y instead of attacking it: steelman it, walk it forward, let them find the wall. People abandon a fix they discover is broken far faster than one they are told is broken.
And when the system isn’t yours to change—you’re the coordinator, the account manager, the front of the house—the discipline tightens rather than relaxes. Don’t adjudicate the Y at all. “That should be fine” is a verdict in a register you aren’t licensed to speak, and it will be remembered as a promise by someone who never heard your caveats. Your competence in that moment is the trace itself: get the X owned out loud, capture the world it lives in, and hand the sheet to whoever owns the mechanism. That is not the junior role in the exchange. Eliciting the X while the requester is still in the room is the one step nobody downstream can perform.