Comment by pdimitar
3 years ago
In my life experience, 95% of the troubles with the XY problem stem from the fact that the people are not aware that they have over-fixated on the potential solution Y for the problem X.
They quickly assumed it, solidified it in their heads, and then most of the time spent with them is allocated to making them disentangle Y from X.
Once that happens, the solution has usually presented itself already at this point -- because the disentangling process involved a healthy amount of discussion.
Sometimes the entanglement happens because Y is the entire elevator pitch for the whole thing.
Get rid of Y, and you're left with "I used Z as intended and it solved the problem with some minor annoyances" or "Yeah, I just shaved it down a bit to fit and used epoxy, no need to CNC an adapter".
Especially when X isn't the actual problem. Sometimes the actual problem is "I've become obsessed with stuffing Y into something".
Another aspect of this: more often than not Y is a solution that has side benefits that are not explicited in the request.
The obvious ones are buying a new computer to use a resource intensive software. There might be options to upgrade the existing parts to cleanly meet the requirements, borrow/rent a machine for the length of the project, spin up a machine in a cloud, straight ask someone else with an adequate machine to inherint the task etc.
Those could all be more optimal solutions, but I'd still totally ask for a new computer instead.
In my case it's very often the opposite: I have already thoroughly examined potential solutions Z, W, V, and Q, and have found them to be unworkable, decided that Y is the path forward, but am not sure how to implement it.
And then I have to spend two hours explaining X, and then patiently explaining why Z, W, V, and Q don't work before my colleagues finally agree with me that Y is what we need to do. Sure, very very occasionally do they come up with alternative T or perhaps K, that I hadn't considered, but I usually find that Y is still the way to go, or at least workable solution of similar complexity.
This is what working with people is like. You will need to make your case and get buy-in from people if you expect their support. You can't just bluntly expect them to respect your conclusion. If you fixate on your conclusion, you will be unable to explain your reasoning getting there, since it will seem irrelevant to you now that you are sure your conclusion is solid.
Understanding what doesn't work is also an important part of understanding the problem.
If One Is Truly to Succeed in Leading a Person to a Specific Place, One Must First and Foremost Take Care to Find Him Where He is and Begin There. -- Kirkegaard
I am often in a situation where a developer is asking help for Y and I'm wondering why he's doing that instead of Z, W, etc. He might be right in going for Y, but I still need to adopt his reasoning, if I am to defend the solution on a system and organizational levels, for reasons like budget/resource/risk/customer experience/technical debt, and ensure buy-in from other stakeholders (product managers, commercial stakeholders etc).