For CIOs, the practical shift is to attach every technology update to a business decision. Instead of reporting only delivery status, frame discussion around trade-offs the leadership team must own: speed versus control, customization versus maintainability, innovation versus operational readiness, cost savings versus resilience. That changes the CIO from technical explainer to decision architect.
There is also an organizational implication many leaders miss: if the CIO is the only executive consistently raising workflow, training, support and operational-friction questions, the company may have a broader governance gap. Those issues should not sit solely in IT. They should be shared across operations, HR, finance, security and the business unit sponsoring the change.
A useful test is simple: after your update, does the room leave with a technical answer, or with a clearer enterprise choice? If it is the former, the conversation is still too narrow. The most effective CIOs do not just translate technology for the boardroom; they force the boardroom to confront the organizational consequences of its technology choices.
It’s possible to be on the agenda and still not be part of the real conversation.
Earlier in my career as a CIO, I found myself in a pattern many senior IT leaders would recognize. Technology had a place on the agenda. I was expected to provide an update, answer questions and move on.
At first, I did what a technically credible IT person would do: I gave the update, made sure it was accurate, answered the questions, and tried to be clear and useful.
There was nothing wrong with that. The problem was not the update. The problem was that the update could easily become the entire role. If I showed up only to report on IT activity and answer technical questions, I was reinforcing a narrow view of the CIO role. I was included, but only in the lane expected from IT.
Most IT leaders build their careers on technical credibility. That credibility matters; it is probably part of what got us into the role in the first place. You do not become a credible IT leader without knowing the work, understanding the risks and knowing what happens when people underestimate a decision.
But technical credibility can also become a narrow box.
You become known as the IT person with the answer. You’re the person who can explain the system. You are the person who can fix the problem; the person who can tell the room whether something is technically possible. But once people are used to engaging you that way, they tend to keep engaging you that way. And if you answer only at that level, you may be training the room to keep asking only at that level.
That was the part I had to own.
Yes, organizations often underuse technology leadership. They bring IT in too late and frame technology as downstream execution. Yet, if I kept giving them exactly what they expected, I couldn’t be surprised when they kept expecting the same thing.
So, I started changing the conversation.
The move was not to stop answering technical questions. If users can’t work, if there is a security issue or if a major project is at risk, the technical reality must be understood.
I answered the question, but I learned not to stop there. Over time, I shortened the technical answer and moved more quickly to the bigger concern. That phrase, or some version of it, became one of the most important shifts in how I communicated:
“The bigger concern is …”
The technical status might be fine, but the bigger concern is the operational impact. The project might be on track, but the bigger concern is whether we as an organization are ready for the change. The request might be technically possible, but the bigger concern is what it will cost in capacity, complexity, security, support or maintainability.
For me, the bigger concern was often operational: Can people still do their jobs?
Technology decisions are not just system decisions. They change how work gets done. They affect employees, workflows, support, training, risk and the friction people experience just trying to do their jobs. That’s why the executive conversation can’t stop at whether the technology works.
The better conversation is what the decision means for the organization. Does it help people work better? Does it slow them down? Does it create risk no one planned for?
Those are executive questions, and the CIO is often the person best positioned to raise them. Sometimes, the CIO is the only one close enough to both the technical mechanics and the operational consequences to see the full picture.
When I started changing the conversation, the room didn’t transform overnight. Some people still asked technical questions. That was fine. I answered them. But over time, the questions started to shift. They became less about technical mechanics and more about scenarios: What would that mean? What would the impact be? What risk would we take on?
That’s where the CIO can create real value, not by overwhelming the room with technical detail. The value is in translating technical understanding into executive judgment. That doesn’t mean dumbing it down. It means raising it up.
One of the hardest lessons for technical leaders moving into broader executive authority is that the room rarely changes first. Technical expertise still matters. A CIO without technical credibility will struggle. But at the executive level, expertise is the foundation, not the finish line. Technical credibility may get you on the agenda, but executive judgment is what changes the conversation.
So, yes, answer the technical question. Be clear. Be accurate. Be credible. But do not let the technical question define the whole conversation.
The next time you’re asked for the IT update, give it. Then move to the bigger concern.
What are your tips for moving past being ‘the IT person’? Let us know: email [email protected].
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.