Lesson 4: Before You Fix the Problem, Make Sure You’ve Found the Right One
The riskiest moment in any operational improvement project? It’s when you convince yourself you’ve nailed the answer already. Let’s talk about the one step that saves you from fixing something that wasn’t broken while the real problem gets ignored.
A surprising, costly mistake smart leaders fall into all the time: They spot an issue, come up with a hypothesis backed by solid data, experience, gut feeling riskiest moment in any operational improvement then jump right to solutions. Suddenly, they’re fixing the wrong thing and the real issue keeps humming in the background, untouched.
Trust me, I’m guilty of this myself. Every COO I know has been there. The gap between seeing something go wrong and actually understanding why is way smaller than it looks. If you leap from identification straight to action without checking your assumptions, you’re setting yourself up for trouble.
But there’s a simple fix – and it cost almost nothing. Before you rush into solutions, go talk to the people closest to the problem.
The Principle: Never Assume. Verify.
So, you’ve mapped your processes, shadowed some teams, found your main failure points. At this stage, it’s tempting to dive in and start fixing stuff. Hold off a little longer. Right now, what you have is a hypothesis. Sure, it’s well informed, but it’s still just a guess. The only thing standing between your hypothesis and the real root cause is a handful of short conversations with folks living the problem every day.
Skip the surveys and the lengthy feedback programs. Just grab five focused chats, each fifteen minutes, same three questions for everyone.
You’ll spot patterns fast. Those answers will either confirm what you thought, or steer you away from wasting time and resources on the wrong track.
A Real Example: The Planning Problem That Wasn’t a Planning Problem
Here’s the story that keeps me from skipping this step.
A company kept missing project deadlines. Looks like a planning issue, right? That’s what the data screamed: deadlines weren’t met, so obviously planning was the problem. The plan? More project management training, stricter scoping sessions, tougher timeline reviews.
Before any of that happened, I talked to the people on the project team. Every single one pointed to the same cause – and it had nothing to do with planning. The plans were fine. The timelines were realistic. What was actually happening was requirements kept changing after the work started. Stakeholders would sign off, teams would begin, and then – sometimes days, sometimes weeks in – the scope would shift, requirements got updated, completed work had to be scrapped and rebuilt.
So, the team wasn’t missing deadlines because they couldn’t plan. They missed deadlines because they kept having to redo what they’d already finished.
What we did? We made one rule: no project begins until requirements are fully documented and signed off. Simple. Honestly, pretty obvious looking back, but it took hearing the team’s side to see it.
Here’s what happened:
- Rework dropped off fast.
- Deadlines became predictable for the first time in months.
- Team frustration – understandably high – tanked.
If we’d skipped those interviews and rolled out “planning fixes,” we’d have wasted time and money on training, never touched the real friction, and left the team just as frustrated.
How to Run These Interviews (Tactical Version)
This whole process is easy. Conversations with the front line, fifteen minutes each, same three questions:
- What slows your work down the most?
- What mistake happens most often?
- What’s the easiest improvement leadership could make right now?
Especially pay attention to that last one. Usually, people doing the work already know what needs fixing – they just haven’t been asked.
A few quick pointers:
- Don’t lead the witness. Keep your theory to yourself. Show your cards and you’ll influence their answer.
- Listen for repetition. You’re not collecting every complaint; you’re hunting for patterns. When the folks name the same friction, you’ve got your culprit.
- Take the answers seriously, even when they sting. Sometimes you’ll confirm your hunch. Sometimes, you’ll land on more uncomfortable territory: a leadership call, a structural issue, a process someone important is attached to. That’s the stuff you need to hear.
The Honest Lesson
I got it wrong in that story. I was confidently, logically, absolutely wrong. If I’d missed those conversations, we would have “fixed” the wrong problem, measured success on a metric that wasn’t the actual issue, wondered why nothing got better, and moved on to another pointless fix.
Those little interviews are a tiny investment to avoid a massive waste – precision with zero accuracy, executing perfectly on the wrong solution.
Before you start fixing, confirm what you’re actually fixing. Ask the people who already know. They’ll tell you.
So, what’s the operational problem you’re sure you’ve figured out right now? When did you last chat with someone deep in it? That conversation might only take fifteen minutes. It might change everything.
In my next post I will be talking about How to publish a ‘One-Page Process Map’. See you then