Recently our education partner SystemsWay School of Management and Leadership published an article on the difference between How and Why. Every executive, manager, and individual contributor will agree that understanding this distinction is critical. Many executives and consulting companies talk about it and advocate "Ask Why," but their explanations often fall short for a simple reason: How vs. Why is a philosophical concept that requires deeper examination.
The Core Insight: Science Answers How, Not Why
Here's the summary of the original article's key insight: Most people, especially scientifically-minded individuals trained in analytical sciences like physics, chemistry, and engineering, don't understand the true difference between How and Why. The biggest learning? Science does not answer WHY questions, science only answers HOW questions.
Consider this example: If we ask "Why is the sky blue?", a PhD in physics will give a detailed answer involving light waves, Rayleigh scattering, and electromagnetic spectrum. But Manish points out that this is actually a HOW answer, not a WHY answer.
Where's the problem? Manish explains there's no problem with knowing HOW—it's a great and fundamental pursuit of science. The issue arises when we accept HOW answers to WHY questions and move on, believing we've found the WHY. When this happens, we never truly seek the WHY answer, leaving us uneducated about the actual WHY.
In the sky example, the WHY belongs to biology or the design of the eye and mind that allows us to perceive short wavelengths as blue. HOW is the concept of non-living systems—meaning how systems operate. WHY belongs to the designer of the systems.
All the discussion about scattering of light and Rayleigh effects is the same for anyone watching because nature operates the same way for every living being—that's the HOW. The reason WHY a colorblind person or a dog perceives the same phenomenon differently lies in the design of their visual systems. HOW questions are answered from the operations of designed systems; WHY is answered from the design or designer's perspective.
A Real-Life Example
This is a hard concept to grasp, so Manish provides a real-life example where we intuitively get it right. If your boss asks "Why did you sign the contract?", they'll be angry if you answer "I picked up the pen, opened the cap, pressed it against the paper, and moved my hand." That's the HOW, and the boss doesn't care about HOW—they care about WHY. They want to know your reasoning because you were designing a system based on your understanding, believing that signing the contract would cause X, Y, Z outcomes.
Application to Software Development
What does this philosophical question have to do with software development? This question is more applicable to software development than perhaps any other profession because we are knowledge workers. Since HOW and WHY together form the System of Knowledge and Understanding, taking HOW answers to WHY questions prevents us from truly improving the systems we're working with.
Manish provides an excellent example of how technologists' understanding of HOW and WHY isn't explicit, so they intermingle them constantly. He references the Five Whys of Root Cause Analysis (RCA) and demonstrates that nearly all five "whys" are actually five "hows." For each why, the answer describes how the system operated to deliver undesired results. The solution becomes fixing what went wrong in the system's operation—figuring out how the designed system failed to operate as intended.
But because WHY belongs to the designer or the designer's mental model, we never fix the design of the system that drives operations the way it does. Manish argues that asking WHY—the true WHY—will cause redesign of systems, not just fixing future operations.
SDLC.works' Approach
At SDLC.works, we make many decisions counter to what enterprises typically do: we use monorepos over polyrepos, flexible release checklists instead of hard gates, and hundreds of other decisions—including not allowing application developers, DevOps, and SRE teams to design the SDLC. These decisions don't come from asking HOW questions or accepting HOW answers to WHY questions. These decisions come from asking WHY questions and ensuring we get WHY answers—meaning design-cause answers to WHY questions.
If the problem lies in the design of the system (which you discover by asking WHY), fixing HOW will ensure those problems happen again. When design is the problem, fixing HOW can enable short-term survival but never long-term success.
The AI Era Consideration
Especially in the age of AI, we should not deploy AI on each part of HOW systems work. We should ask WHY systems are working the way they are (meaning examining their design) and, given AI, whether we would design them the same as in the pre-AI era. If you believe the answer should be "No," then we should redesign those systems.
The Pipe Example and RCA
Manish gives a fantastic example of "Why did the pipe break down?" where he demonstrates how we accept HOW answers to WHY during incidents. Does your organization, during RCA and Five Whys exercises, really discover WHY answers or only HOW answers? If the latter, what are you missing in systems improvement?
Personal Reflection
Having read this and seemingly understood it, in conversation with Manish, he constantly points out that I keep answering HOW to WHY questions. If Manish didn't interrupt me, I wouldn't have caught these mistakes. According to Manish, changing this pattern takes time, and the better way to change is to attend his Introduction to Systems Thinking class. Once you take that class and truly understand how HOW+WHY forms the system of knowledge and understanding, Manish says you'll stop accepting HOW answers to WHY questions.
I'm looking forward to it and waiting eagerly.
Your Turn
Do you have examples of people asking WHY questions and getting HOW answers in software development? We're sure you do, and we predict that's the case in every RCA incident that you and your organization have conducted.
Conclusion
I'm happy to be realizing that we are knowledge workers, and if we are knowledge workers, then we should know what knowledge is, what epistemology is (which Manish teaches and no one ever mentioned to me), and how and why epistemology is the system of HOW+WHY.
If you're interested in Manish's course on Systems Thinking and Epistemology, please sign up here
