True partnership with the business begins when CIOs stop searching for products and start experimenting themselves, bringing forward solutions grounded in evidence, not assumptions.
The business came to me with a clear request. We need to find a product that can reduce our document review time. The right tool might cut the workload by 80% and ease the pressure on future hiring.
It would have been easy to start comparing platforms or scheduling vendor demos. But before anything else, I had to ask the question that guides every meaningful technology decision. What problem are we actually trying to solve?
Once the team walked me through the reality, the answer became obvious. The bottleneck was not a system. It was the hours of human interpretation, analysis, and recommendations required to turn documents into decisions. The process could not scale with the speed the business needed.
Their instinct was to search for a product.
My instinct was to understand the problem.
And once I understood it, I knew what had to come next. I had to test the theory myself. Can I leverage AI to assist? I had to understand what was possible before asking my team to move in any direction. How could I expect them to follow a path that I had not walked myself?
That is where the real work began.
From the Boardroom Back to the Computer Lab
To explore the problem, I had to shift out of the boardroom mindset and return to a place I had not been in years.
Back to the feeling of long nights in a college computer lab surrounded by half empty bottles of Mountain Dew and a pile of Snickers wrappers. Back to a time when laptops were too slow to build much of anything and when AI did not exist. A time when collaborating with classmates to prove out a simple “Hello World” felt like real progress.
There was something grounding about returning to that mindset. Curiosity. Experimentation. Trial and error. No business case slides or governance checklists. Just a problem, a keyboard, and the desire to figure it out.
As I began working through the first version of the proof of concept, muscle memory took over. Without realizing it, I started building the way we always have. Complex logic. Structured rules. Rule Based code. If, Then Paralysis. The same patterns that shaped those late nights in the lab.
Then the realization hit me. This was not innovation. This was familiarity. I was not using AI. I was rebuilding the past.
It was time to see what AI could really do.
It was time to take it for a test drive.
Letting AI Be the Brain Instead of the Structure
That pivot changed everything.
I brought in enterprise grade models for testing from OpenAI and Gemini and let them take on the thinking. Their role was to interpret, analyze, summarize, and recommend. They handled the cognitive work our teams were spending hours on every day.
My role shifted to building the structure around that intelligence.
I defined the proprietary rules that matter to our business, the compliance constraints that could not be violated, the data relationships unique to our operations, and the guardrails that kept the outputs aligned to our standards.
The division became clear.
The model provides the intelligence.
The code provides the structure.
There was no reason to create a tangle of deterministic rules when the model could already outperform them. My job was no longer to out code the model. It was to guide it.
A Proof of Concept That Proved Real Potential
Once the model became the engine, the results shifted quickly.
The proof of concept demonstrated exactly what the business hoped to see.
- Up to an 80% reduction in review time.
- A significant lift in throughput.
- A clear path toward easing future hiring pressure.
This was not a polished production tool. It was not hardened or scaled. It was a true proof of concept. It showed possibility rather than promise and created enough confidence to move to the next step.
What mattered most was simple. We proved that AI could solve the problem at a level that justified further investment.
Knowing When to Hand It Off
Once the concept was validated, the work evolved.
I brought in our development partner. Their responsibility was to harden the architecture, secure the environment, instrument the process, build observability, and turn the experiment into a pilot that could succeed in the real world.
This is the natural progression of modern CIO work. You lead the exploration. You test the theory. You validate the potential. Then you let the builders take it forward.
At that point, the challenge is not the technology. It is aligning people, process, and data so the organization is ready for what the technology can now deliver.
Experimentation is personal.
Scale is collaborative.
The Future Belongs to CIOs Who Experiment
This experience reinforced an important truth. Modern CIOs cannot lead AI adoption from the sidelines.
We cannot rely on vendor demos, theoretical discussions, or secondhand knowledge. We must experiment ourselves. We must be willing to build, test, and learn in small cycles so we can give our teams direction grounded in experience, not assumption.
The greatest risk is not AI.
The greatest risk is assuming we understand it without touching it.
So, I ask other CIOs the same questions I asked myself.
- Are we solving the real problem or the problem we are most comfortable with?
- Are we letting AI think or forcing it into old patterns?
- Are we experimenting early enough to lead with clarity?
- Are we giving our teams direction shaped by firsthand understanding?
AI will not replace the CIO.
But CIOs who avoid learning how to work with it may quietly replace themselves.
Sometimes the most strategic thing a CIO can do is the simplest.
- Roll up your sleeves.
- Go back to the computer lab mindset.
- And rediscover what is possible.
Trusted insights for technology leaders
Our readers are CIOs, CTOs, and senior IT executives who rely on The National CIO Review for smart, curated takes on the trends shaping the enterprise, from GenAI to cybersecurity and beyond.
Subscribe to our 4x a week newsletter to keep up with the insights that matter.
