I spent more than twenty years in quality, reliability, and manufacturing. I've worked in environments where a single defect could shut down a production line, ground an aircraft, or put a product recall on the news. In those environments, you learn very quickly that reacting to problems isn't enough, you have to understand them. Deeply. Structurally. Down to the root cause.
The irony is that nobody taught me this in school. I learned it on the job, the hard way, over years of doing it wrong before I started doing it right. And when I look at what kids are being taught today, I see the same gap I walked into on my first day as an engineer: they're being taught to identify problems, but nobody is showing them how to actually solve them.
The Way Engineers Think About Problems
Here's the difference. Most people — and most students — approach a problem by jumping straight to the fix. Something went wrong, so you correct it and move on. The grade was bad, so you study harder next time. The friendship fell apart, so you give it space. These aren't wrong responses, but they're surface-level. They treat the symptom without ever asking what caused it.
Engineers are trained to resist that impulse. Before we touch anything, we ask: what actually happened, and why?
One of the most powerful tools in my toolkit is the 5 Whys — a deceptively simple technique developed at Toyota. You take the problem and ask "why" five times in a row, with each answer becoming the input to the next question. It sounds almost too simple, but it works because it forces you past the obvious explanation and toward the real one.
Here's a concrete example. A manufacturing line keeps producing parts with a surface defect. The obvious fix is to slow down the machine. But ask why five times and you might discover that the real cause is a supplier delivering material with inconsistent hardness, a problem that no amount of machine speed adjustment will ever solve. Fix the machine, the defect comes back. Fix the supplier spec, it goes away for good. That's root cause analysis.
Another tool I used regularly is the fishbone diagram (also called an Ishikawa diagram), which maps every possible cause of a problem across categories like people, process, equipment, materials, and environment. It's a structured way of making sure you haven't missed anything before you commit to a solution. Engineers use it because experience has taught us that the obvious cause is rarely the only one, and almost never the most important one.
Then there's PDCA: Plan, Do, Check, Act. It's a cycle, not a checklist. You plan your solution, implement it on a small scale, check whether it actually worked, and then act on what you learned. The "check" step is the one most people skip. Engineers don't skip it, because we've been burned too many times by solutions that looked right but weren't.
Why the Gap Matters for Kids
These tools: 5 Whys, fishbone diagrams, PDCA, root cause analysis are not exotic. They're not advanced. They're the everyday language of people whose job it is to fix things that are broken. And yet they're almost entirely absent from K–12 education.
What that means in practice is that kids grow up developing a kind of problem-solving instinct that's really just pattern-matching and guessing. They try something. If it works, great. If it doesn't, they try something else or give up. There's no framework underneath it, no structure, no way to learn from what went wrong.
That matters because the problems kids face, failing a class, a conflict with a friend, a project that keeps going sideways, have root causes just like a manufacturing defect does. And if you never learn to look for the root cause, you'll keep treating the same symptom over and over again.
The skill that takes engineers years to develop on the job can be taught earlier. It just needs to be translated into language and examples that actually connect with a kid's world. That's exactly what I set out to do when I wrote the SOLVED book, to take the same structured thinking I used in quality and reliability work and rebuild it in a form that a ten-year-old can actually use.
You can read more about the framework itself on the SOLVED Method page. The short version is that each letter of SOLVED walks a kid through the same logic an engineer uses: define the problem clearly, observe what's actually happening, figure out what's causing it, and then design a solution that addresses the cause, not just the symptom.
What This Looks Like in Practice
Think about a kid who keeps forgetting to turn in homework. The surface fix is obvious: remind them more, set an alarm, check their bag before school. Some of those things might help. But ask why five times and you might find out that the real issue is that they don't write assignments down in the first place because they're embarrassed to ask the teacher to repeat instructions, which happens because they're afraid of looking confused in front of their classmates.
That's a very different problem than a missing alarm. And it has a very different solution.
That's root cause thinking. It's not complicated, but it takes practice. It takes a framework. And it takes someone showing you how to do it before you've spent twenty years learning it the hard way.
Give Them the Tools Early
I wrote SOLVED: The Kid's Guide to Fixing Anything That's Broken, Late, Lost, or Failing because I believe every kid deserves to learn what engineers know. Not the jargon, not the technical details, but the underlying logic: the habit of asking why before jumping to what.
If you have a kid who gets frustrated when problems don't go away, or who keeps making the same mistake without understanding why, this book was written for them. It gives them a repeatable process they can use on any problem, whether it's a grade, a friendship, a broken habit, or anything in between.