consulting
Curiosity-Led Execution
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 and more to do with how 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 I learned weren’t always what I had expected.
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 and tangible 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 traveling, reviewing its source code at night, trying to understand why it worked the way it did. That understanding led to new ways of optimizing performance.
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 you apply it 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
Knowledge explains. Curiosity transforms. 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.
What’s the Prize If I Win?
In consulting and in sales, there is a tendency to believe that if you show someone how to find that proverbial “pot of gold at the end of the rainbow,” they will be motivated to do so. Seasoned professionals tend to ask, “What problem are you trying to solve?” to understand whether there is a real opportunity.
Sometimes a mere pot of gold just isn’t enough to motivate. Usually the motivation is something very personal. What’s in it for them? Not what’s in it for me?
The skill is determining what matters most to the decision-maker and in what order, then showing how the proposed solution will bring them closer to achieving their personal goals.
Case in point. Several years ago, I tried to sell a packaged Business Intelligence (BI) system built on our database platform to the customers most likely to need it. Qualification performed – check. Interested – check. Proof of value – check. Quick ROI – check. Close the deal – not so fast…
This application was a set of dashboards with 150-200 predefined KPIs (key performance indicators). The premise was that you could quickly tailor and deploy the new BI system with little risk (finding and validating that the needed data was available to support their KPIs was the biggest risk, but one we could identify up front). The business impact and ROI were there, and we could deliver tangible value at half the cost of a typical similar implementation. Who wouldn’t want that?
I spent several days onsite with the prospect, identified areas of concern and opportunity, and used their data to quantify the potential benefit. By the end of the week, I could show the potential for an 8x ROI in the first year. Remember, I estimated this using their data, not random or industry figures. Being somewhat conservative, I suggested that even half that amount would be a big success. Look – we found the pot of gold!
Despite this, the deal never closed. This financial services company had a lot of money, and the CIO had a huge budget. Saving $500K+ on this project would be nice, but it wasn’t essential. While the impact was there, the urgency was lacking.
I later learned he was pushing forward an initiative of his own that was highly visible. The new system I proposed could have become a distraction, and he did not need that reputational risk. Had I made this determination sooner, I could have easily repositioned the offering to better align with and support his agenda.
For example, the system could have shifted its focus from financial savings to project and risk management for his higher-priority initiative. The KPIs could be on earned value, scheduling, and deliverables. This probably would have sold, as it would have been far more appealing to this CIO and supported what was important to him (i.e., his prize if he wins). The additional financial savings initially identified would be the icing on the cake, to be reinvested later.
Several lessons emerged from this effort. In this instance, I focused on my personal pot of gold (based on logic and common sense) rather than on my customer’s priorities and prize for winning. That mistake cost me this deal, but it is one I have not made since – helping me win many other deals.
Why I Love Technology
Technology was not native to me, at least relative to children and young adults today. Simple four-function calculators started becoming popular when I was in Elementary School. I only had a single computer course in High School (it was the only one offered). We had a Timex Sinclair and, later, a Commodore 64 computer at home. It was fun, but I wasn’t hooked yet.
I started a car and motorcycle parts business when I was 18. Initially, I was looking for a way to get cheaper parts for myself and thought if I could make money doing it, then all the better. Nearly everything I did was manual. Then I learned about a Radio Shack TRS-80 at college that had a word processing program. I used that to create mailings to parts companies, distributors, and potential customers. Before long, I had a catalog of products I could sell and a small but loyal customer base buying products and services from me. If Quickbooks had been available back then, I may have kept the business running. Doing everything manually just took too much time. Even so, this was my first technology win, and I liked it.
A few years later, I was programming at a local marketing company. The MIS Director (what IT used to be called) purchased a new relational database product with a 4GL application language. This was in 1987, and this technology was very new. The product was sold as saving “75% of your development time and effort.” Most seasoned people in the group did not want to risk their reputations on something that might not work.
I was new and had nothing to lose, so for the next month, I read every manual cover-to-cover. Before long, I worked on new applications and soon became the in-house RDBMS/4GL expert. This led to a fast track of promotions and being selected to develop the majority of new custom applications sold by our company. It was not easy, but it was fun and good for my career.
My first and arguably most influential mentor was my manager at this job (Jim). He taught me how to design parameter-driven systems that were flexible and extensible. He also taught me that “good enough usually isn’t good enough.” Most people are lucky to have one really good mentor during their career. I’ve been blessed with four of them at different stages of my career. It has motivated me to return the favor and help others whenever possible. This job helped me grow in so many ways.
A few years later, I worked at a software company creating a new standard product on this database platform. Nobody was trained on the product, and most wrote their embedded C/SQL programs like any other 3GL program (i.e., non-transactionally). I pointed out to the VP of Development that this would be a problem. He didn’t want to hear that. I pushed for a concurrency test, and everything locked up. Many people were suddenly upset with me, but the longer you wait to solve problems like these, the more expensive it becomes.
We spent the next two months creating functions to manage transactions, optimizing everything (even table structures to get the best byte alignment), and making this new packaged system work. The VP now liked and respected me, which changed our working dynamics. That shifted the focus from people and personalities to technologies and results.
We also worked on other aspects of the system to enhance performance. We created a system much like Memcached in Perl (back in 1990) that allowed us to handle the workflow of even the fastest warehouses in near real-time. We did many leading-edge things at the time (HA clusters with automatic failover, automated restart of remote devices to resume work in progress to the point of failure, outsourcing to India using an X.400 connection that I configured, distributed systems, client/server systems, etc.) I learned a lot from that experience and was proud of the results.
Later, I worked for that database company (Ingres). This was in the heyday of consulting, where projects were huge, and rates were high. My first project (started on my second day on the job) was to redesign a Risk Management System at an insurance company that had started using our products. I soon found that the project had been in progress for two years and had binders full of specifications, but nothing was actionable. I did not make many friends those first two weeks, as I pointed these things out.
I offered to facilitate a JAD (joint application design) session with multiple lines of business. This pointed out issues that even they were unaware of and allowed us to begin designing a flexible system that would accommodate all lines of business. We used an agile approach to prototype the new system, demonstrations to get buy-in, and moved the project forward quickly. Six months later, the first part of that functionality went live. The system was fully functional within a year!
I had the opportunity to work on some of the largest databases at the time (roughly 300 GB total, which is small by today’s measures), work on leading-edge technology (Clustering, VLDB, and Enterprise Unix systems), and really become a true Consultant along the way (with the help of another mentor – Bill). I was sent to several Unix Internals courses and then worked with our Engineering team to improve our products and create configurations supporting other large companies with similar problems.
A few years later, I worked at a small start-up company that created the world’s first commercial JDBC driver. I have worked with many very smart people before, but now I worked with a couple of very brilliant people. My main contribution this time was on the business side, but we learned a lot from each other as we grew the business to over $1M in sales within the first year.
One thing that sticks with me is that I became interested in VRML (virtual reality modeling language) during this time. I had an idea (1997) that we could create a website to show the insides of buildings, productize them, and sell them to real estate companies and larger apartment complex owners. My idea was not well received by the team, but a few years later, systems like this were being developed, and a few people were making a lot of money. That taught me to have more faith in ideas based on new technology, regardless of what others thought. It also brought me back to an important concept in business and consulting: being able to communicate ideas and benefits in ways that are easy for everyone to understand, rather than focusing on the technology itself.
Over the years, these lessons learned have helped with BI (business intelligence) – building dashboards using relevant KPIs tailored to the specific audience, mobile computing, cloud computing, IoT, and big data. Most people think these things are “not important until they become important,” often 6 – 12 months (or more) later. From my perspective, the real trick isn’t in trying to understand the next big thing, but in considering better, easier, and more efficient ways of doing the things you do today.
This is why I love technology. It has helped me accomplish many things that have had a tangible impact on the businesses I have worked for and consulted with. It has taught me to think about problems and ideas from various perspectives and to leverage lessons learned in one area to help solve problems in another (i.e., transfer knowledge and skills from one area to another). Technology has provided me opportunities to learn about and work on solving business and technical problems in several industries as I ponder, “Why not?” It has been a wonderful journey.
My interest in technology has allowed me to meet and work with many interesting and incredible people throughout my career in many industries and settings. That’s much more than I ever expected when I took my first programming course so long ago, and it has become a significant aspect of almost everything I do. My diverse background has proven beneficial many times over, but the greatest gift has been the ability to consider other possibilities based on those experiences.
Welcome to this journey of discovery and sharing.
Where Ideas, Experiences, and Lessons Learned Intersect 