A man wants to restructure his house and decides to tear down a wall to create a beautiful open space, so he goes to his neighbor and asks for the biggest hammer he could lend him, and after lots of sweat and hammering he’s done!
The neighbor visit the home, and he compliments the man for the work:
Neighbor:<<Hey nice work man!>>
Man:<<Lot’s of hammering, but worth it!>>
Neighbor:<<Really? You needed my hammer for this?>>
Neighbor:<<Gosh! It would be better if you had asked me for my concretesaw!>>
What can we learn from this story? That often instead of asking help on a particular problem, we ask for help on a solution that we think may solve our original issue. We have hit the infamous XY Problem!
People get stuck on what they believe is the solution and are unable to step back and explain the issue in full.
By asking about our solution, we immediately limit the solution space and lose the opportunity to think about brilliant alternatives.
We also hide the real problem from our interlocutor effectively reducing his chances of helping us with different ideas and perspectives.
And finally our attempted solution may not be a working solution to the original problem, and so we waste a lot of time on something useless.
What can we do to reduce the impact of this fallacy?
We can try to focus and nail down the real essence of the problem, and not thinking about the solution right away. And that’s hard as we are naturally inclined to jump immediately to a solution and because everyone wants to be the smart guy in the room!
So before immediately thinking about what to do, try instead to improve clarity on the problem and its context. To do that we may adopt different techniques to explore the original issue.
For example, we can start using the “Five Whys” or the “Ishikawa Fish Bone Diagram” to deepen the knowledge about our problem and try to identify the causes and other contextual pieces of information.
Equipped with this knowledge, we can then brainstorm different options and approaches (maybe with a diverge and merge strategy!) and work from there.
In the context of software development, designing and building a system or a set of features that does not address the real problem leads to massive waste of times and resources, and that’s the reason why cross-functional teams need to be engaged with the root issue by the stakeholders and not on attempted solutions. A resourceful team will generate many viable options and together with the stakeholders they can choose the best path to reach the desired goals.