problem solving
Curiosity-Led Execution (5-minute read)
Most organizations don’t struggle because they lack solutions—they struggle because they misdiagnose problems. A structured, curiosity-led approach accelerates alignment, reduces rework, and leads to solutions that actually stick.
My Starting Point
I was not a fan of consultants when I first started working with them. Most were arrogant, had limited focus, and viewed problems or goals in isolation. I later learned that the same could be said for salespeople, executives, and more. It had less to do with the role but was more evident when people presented themselves as experts.
Switching to consulting was a tough sell. When I finally accepted a position, I expected to learn proven methodologies from seasoned experts. The lessons learned were not always what I had anticipated.
Many of the senior consultants I worked with had been highly successful early in their careers. But over time, that success calcified into rigid frameworks and default approaches. They weren’t completely wrong—but they weren’t adaptable or as effective as they could have been, either.
It reminded me of the old metaphor: “If the only tool you have is a hammer, everything looks like a nail.”
At one point, I seriously questioned whether consulting was the right fit for me.
Then I stepped back and looked at the best consultants I had worked with—the ones clients trusted and consistently delivered outcomes. I asked a simple question:
What do they do differently?
The answer wasn’t just expertise. It was curiosity, combined with the desire to deliver a positive experience that delivers tangible positive outcomes.
From Depth to Insight
Early in my career, I went deep—sometimes excessively so.
I read dozens of manuals for a relational database system, cover to cover, just to understand how it worked. Then I spent years, while traveling, going through its source code, trying to understand why it worked the way it did.
That effort paid off. I became recognized as an expert for that product, which opened the door to many challenging and exciting consulting engagements.
But it also revealed a limitation: Depth alone doesn’t scale.
What scaled was the mindset that I developed with it:
- Looking beyond surface-level symptoms.
- Viewing problems from a systemic perspective. Understanding how systems interact (not just how they function).
- Asking how and why decisions were made, not just what decisions were made.
I learned to read between the lines—technically and organizationally. To understand not just systems, but the people and processes behind them.
That context is powerful, but difficult to extract—especially quickly.
The Breakthrough: Structured Curiosity
What ultimately worked wasn’t just knowledge. It was a repeatable approach built on three elements:
- Establish credibility
Demonstrate enough expertise early to build confidence. - Lead with curiosity
Ask thoughtful, relevant questions that show genuine interest—not interrogation. - Close the loop
Articulate your understanding back to stakeholders to confirm, refine, or challenge it.
This creates a feedback loop:
Curiosity → Insight → Validation → Alignment
That loop is where trust—and progress—happens.
A Practical Tactic: The “Columbo Technique”
One of the most effective tools I’ve used is commonly called the Columbo Technique.
The idea is simple: Lower defenses by creating psychological safety—and a sense of control.
Instead of pushing for answers, you:
- Ask informed questions
- Make partial observations
- Then, intentionally leave a gap
Something like:
“I might be missing something, but I’m not fully connecting how X impacts Y…”
This does two things:
- Signals humility (reducing resistance)
- Invites correction (which reveals deeper truth)
People tend to open up—not because they’re forced to, but because they want to contribute. They feel safe because you are focused on understanding the situation and solving the problem, and not pointing fingers or assigning blame.
And once that happens, you get access to what actually matters: the “why” behind the “what.”
Applying This in the Real World
This approach works across consulting, sales, and leadership—but only if applied deliberately.
Here’s how to operationalize it:
1. Start Broad Before Going Deep
Don’t jump to solutions. Map the landscape first:
- Stakeholders
- Systems
- Constraints
- History
2. Use Their Language
Mirror terminology and examples. It builds alignment faster than forcing your own framework.
3. Validate Early and Often
Don’t wait until the end to present conclusions. Share evolving understanding:
- “Here’s what I think I’m seeing…”
- “Does this match your experience?”
- “Can you help me identify reasons why this might not work?”
4. Balance Confidence with Curiosity
Too much confidence shuts people down.
Too much curiosity erodes credibility.
The balance is where influence lives.
5. Optimize for Adoption, Not Perfection
The best solution is the one that gets implemented and sustained—not the one that looks best on paper.
A great example of this is at a large insurance company, where I led a successful 18-month redesign and implementation of a common Risk Management System used across three distinct businesses.
Before I came, they spent two years and several million dollars with a Big 5 Consulting company. The output was several 3” binders filled with specifications, definitions, and design documents. It was amazing, but wasn’t implementable. I have seen that far too often on consulting engagements.
A section in the middle of this post describes what happened with that project.
Make It Repeatable with the CLEAR Framework
This is a simple, reusable model that can help anyone new to a company or role.
The C.L.E.A.R. Framework
C — Credibility
- Establish baseline trust quickly.
- Demonstrate you “speak their language.”
L — Learn
- Map systems, stakeholders, constraints, and history.
- Ask high-quality, layered questions.
E — Expose
- Surface gaps, contradictions, hidden dependencies.
- Use techniques like the “Columbo Method.”
A — Align
- Play back understanding.
- Build shared clarity before prescribing.
R — Recommend
- Deliver solutions optimized for adoption and results, not elegance alone.
Why This Matters
When you lead with curiosity, you move faster—not slower.
You avoid rework.
You uncover hidden constraints early.
You gain stakeholder alignment before decisions are locked in.
And occasionally, you can help solve problems that have existed for years—in a matter of weeks—because you’re solving the right problem.
If this sounds interesting and you would like to discuss it further or seek out assistance, contact me here.
Never Panic!
Panic is not a good problem-solving tool, regardless of your position or role. It is especially bad when you are in charge of people or brought in for your expertise. Panic leads to a myopic view of the problem, hindering creativity.
The point in my career when this became readily apparent was when I was working for a small software company. We had a new product (Warehouse Management System) and were launching our third deployment. This one was more complicated than the rest because it was for a pharmaceutical company. In addition to requirements like refrigeration and lot control, there was a mix of FDA-controlled items requiring various forms of auditing and security and storage areas significantly smaller than previous installations. It was a challenge, to be sure.
A critical component, “Location Search,” failed during this implementation. About 10-12 people were in the “war room” when my boss, the VP of Development, began to panic. He was extremely talented and normally did an excellent job, but his reaction negatively affected the others in the room. The mood quickly worsened.
I jumped in and took over because I did not want to be stuck there all weekend and mostly because I wanted this implementation to succeed. I asked my boss to go out and get a bunch of pizzas. Next, I organized a short meeting to review what we knew and what was different from our prior tests and asked for speculation about the root cause of this problem. The team came up with two potential causes and one potential workaround. Everyone was organized into three teams, and we began attacking each item independently and in parallel.
We identified the root cause, which led to an ideal fix a few days later and a workaround that allowed us to finish the user acceptance testing and go live the following day. A change in mindset fostered the collaboration and problem-solving needed to move forward.
But this isn’t just limited to groups. I was a consultant at a large insurance company on a team redesigning their Risk Management system. We were using new software and wanted to be sure that the proper environment variables were set during the Unix login process for this new system. I volunteered to create an external function executed as part of the login process. Trying to maintain clean code, I had an “exit” at the end of the function. It worked well during testing, but once it was placed into production, the function immediately logged people out as they attempted to log into the system.
As you can imagine, I had a sinking feeling in my gut. How could I have missed this? This was a newer system deployed just for this risk management application, so no other privileged users were logged in at the time. Then, I remembered reading about a Unix “worm” that used FTP to infiltrate systems. The article stated that FTP bypassed the standard login process. This allowed me to FTP into the system and then delete the offending function. In less than 5 minutes, everything was back to normal.
A related lesson learned was to make key people aware of what happened, noting that the problem had been resolved and that there was no lasting damage. Hiding mistakes kills careers. Then, we created a “Lessons Learned” log, with this as the first entry, to foster the idea of sharing mistakes to avoid them in the future. Understanding that mistakes can happen to anyone is a good way to get people to plan better and keep them from panicking when problems occur.
Staying calm and focused on resolving the problem is a much better approach than worrying about blame and the implications of those actions. And most people appreciate the honesty.
As the novelist James Lane Allen stated, “Adversity does not build character; it reveals it.”
Occam’s razor, our Maxima, and the Sage Mechanic
My wife has a Nissan Maxima and loves her car. Over the past 9 months, there has been a persistent but seemingly random problem where the radio is used for a few minutes while the car is off and then the battery dies when she goes to start the car. This has happened more than a dozen times over the past 3 1/2 years, and it has been seen by two dealerships for a total of three times recently with no success – the most recent visit being one day before this problem occurred.
Saturday morning, I was running errands when my wife called and let me know that this problem had happened again (the second time this week, and she was very frustrated). I was pretty excited because this time, the problem occurred at home, not at some parking lot like usual, so I had the luxury of time to try to make a root cause determination. I’m somewhat mechanical but no professional, so I followed my consulting advice and contacted a professional.
Dave T. is a mechanical guru with an uncanny ability to offer sage advice with only a modicum of information. He is incredibly busy but always willing to spend a few minutes and give helpful advice. It helps that he is a great guy, but it also helps him generate business (leads and referrals). It is an approach that helps create a constant backlog of work and a very loyal clientele, which is good business.
I called Dave, described the problem, and mentioned what I had read on various forums (i.e., similar electrical problems observed after some arbitrary mileage). Next, I mentioned that this had just been to the dealership, and they did not find anything wrong. Dave laughed, stating, “There is a 99%+ likelihood that the alternator is bad, possibly both the alternator and battery.” He sounded very confident.
There was a pause, and then he asked, “What’s more likely – that there is some completely random problem that only happens when your wife is out and your son stays in the car and listens to music for a few minutes, which by the way only happens to Maximas after X number of miles, or that there are issues with the alternators where they tend to fail after a certain amount of use, which causes them not to charge the battery properly and leads to a condition where there is not enough of a charge to start the car?”
When Dave explained it like that, I felt kind of stupid, consoled only by the fact that other professional mechanics had not resolved the problem before me. He added, “Anything that could drain a battery within a few minutes would be noticeable. It would start a fire or melt wires and smoke or smell. You haven’t seen or smelled anything like that, have you?”
I described my plan to troubleshoot the problem, and Dave suggested that I also test the alternator and the specific gravity of the individual battery cells. So, less than five minutes into that call, I had a plan and was off and running.
Yesterday afternoon I spent several hours using a methodical approach to troubleshooting, documenting everything with pictures and videos to help me recall details and sequence if needed. Sure enough, Dave’s knowledge and intuition led to the correct conclusion.
I called him to thank him, and while talking, I wondered aloud why the dealership could not figure this out? Dave replied, “It’s not that they couldn’t have done what you did, but instead, they focused on the symptoms you described. The mechanic probably sat there for 10-15 minutes with the lights and radio on while the car was off. After that, the car started, so they assumed everything was fine.
I listened to what you said, ignored the randomness and speculation, and honed in on the likeliest problem. The fact that this happened again so soon also made sense because now your battery was run down from the testing performed by the dealership.” He added, “In my business, I get paid for results, so I can’t get away with taking the easy way out.”
I’m big on lessons learned, wanting to make the most of every experience because I have learned that skills and knowledge are often very transferrable. As I thought about this, I realized that Dave’s analysis was the perfect practical application of Occam’s razor. It’s a very helpful skill as a Consultant, but more importantly, it can help when problem-solving in any line of work.
Where Ideas, Experiences, and Lessons Learned Intersect 