A client came to us with a “motor problem.” Their device was overheating during extended use. They wanted us to spec a more powerful motor with better thermal characteristics.

We found the real problem in two hours: a firmware bug that was running the motor at 100% duty cycle when it should have been pulsing. The original motor was fine. The fix took a day.

The Surface-Level Trap

When something goes wrong, there’s pressure to fix it fast. Ship the patch. Swap the component. Move on.

But surface-level fixes have a cost:

  • They don’t actually solve the problem — they mask it
  • The real problem resurfaces later, usually at a worse time
  • You accumulate technical debt that slows everything down

The motor example? If we’d just spec’d a bigger motor, the client would have paid more for components, the device would have been bigger, and they still would have had firmware that wasted power.

The 5 Whys (Actually Using Them)

Everyone knows the “5 Whys” technique. Few people actually use it.

Here’s what it looks like in practice:

Problem: Motor overheating

Why #1: Motor is drawing more current than expected → Most people stop here and spec a bigger motor

Why #2: Motor is running at 100% duty cycle during normal operation → Some people stop here and add a thermal throttle

Why #3: Firmware isn’t implementing the control loop correctly → Getting closer

Why #4: The control loop was copied from a different project with different requirements → There it is

Why #5: No code review process caught that the copied code wasn’t appropriate → Root cause: process problem, not technical problem

When to Dig Deeper

Not every problem needs five levels of analysis. Sometimes the surface-level fix is the right answer.

Dig deeper when:

  • The problem is recurring
  • The problem appeared suddenly in something that was working
  • The obvious fix seems too easy
  • Multiple symptoms might share a root cause

Accept the surface fix when:

  • It’s a known tradeoff you’re making intentionally
  • The cost of investigation exceeds the cost of the fix
  • You’re shipping and need to move, but you document the debt

The Discipline

Root cause analysis isn’t hard. It’s just uncomfortable. It takes longer. It sometimes reveals that the problem is your process, or your architecture, or your earlier decisions.

That discomfort is information. Lean into it.

The best engineers I know aren’t the ones with the most technical knowledge. They’re the ones with the discipline to keep asking “why” until they find something real.

At Expertise Engineering, we dig for root causes — not quick fixes. Let’s talk about your project.