I love engineers*
Engineers are the ultimate problem-solvers. They see a problem and the need to fix it. Engineers believe every solution can be improved, every process can be more efficient, and every system optimized.
Which is why I nearly fell out of my chair when, after explaining (again) the importance of asking 5 Whys when interviewing customers and asking why the team was struggling to do so, an engineer said,
“We troubleshoot the why. Asking would be a show of not knowing.”
Wha?!?!?
In my head, I screamed, “But we don’t know! We don’t know the problem because the customer defines the problem! But people are terrible at defining problems, so we ask why. So that we can understand the root cause, then articulate the problem, then solve it!”
Instead of actually screaming, I took a deep breath and said, “Mmmmmm, interesting.”
Admittedly, not the most helpful response.
Why Asking “Why?” is hard
How often do you ask, “Why?”
How often do people on your team ask, “Why?”
Probably not often and probably for reasons that feel very sensible:
- It’s my job to know why
- I don’t want people to think I don’t know
- I don’t know, but I think I should
- People will think I’m stupid/not good at my job
- I’ll lose credibility, and that will impact my job/job prospects/paycheck
And, let’s be honest, those reasons are quite sensible depending on the circumstance.
But feelings aren’t facts, and I still didn’t understand why problem-solvers struggled to ask, “Why?”
So, I sought out an engineer and asked, “Why?”
He took a deep breath and said, “Mmmmmm, it’s complicated.”
When asking “Why?” should be hard.
There are lots of different types of engineers, but when you focus on engineers working in companies (as opposed to those in academia or research labs), most of them work on machines, code, systems, or processes, that exists or are knowable.
In this context, when there’s a problem, it’s the engineer’s job to identify why the problem occurred and how to fix it.
To troubleshoot the Why, engineers use tools specifically designed to collect and analyze data. While those tools aren’t perfect, engineers know how to calibrate the data by applying different allowances and tool combinations.
“So,” I summarized, “when you’re dealing with something objectively knowable, like a machine or code, and you have a proven tool for troubleshooting, you shouldn’t ask, ‘Why?’ Right?”
“Sure,” replied the engineer, who is very used to me over-simplifying things and knows better than to try to convince me that his long and complicated answer is a better way to go.
When asking “Why?” should be easy
Humans can also be thought of as machines, code, systems, and processes, but, unlike those that engineers work on, we’re not objectively knowable. As neuroscientist Antonio Damasio wrote, “We are not thinking machines. We are feeling machines that think.”
In this context, when a human has a problem, the human is the only one who knows why the problem occurred. This means that we must find the Why before we can troubleshoot it.
Finding the Why and troubleshooting in this circumstance is challenging because we don’t have tools specifically designed to collect and analyze data. We ARE the tools. We must ask the right questions and listen without assuming or interpreting to ensure that we get accurate answers.
How to make asking “Why?” easier
As a problem-solver, it’s always essential that you find the root cause.
How you find that root cause varies.
If the problem is occurring in something that is objectively knowable and accurately measured and assessed with proven tools, then yes, it IS your job to know why there’s a problem and troubleshoot it.
If the problem is occurring in something not objectively knowable (like a human), then it is your job to ask Why (usually several times) before you troubleshoot.
After all, even if you’re an engineer, you can’t solve a problem if you don’t know why it exists.
* I’m married to an engineer, but that’s not the only reason I love them