I’ve written before about reclaiming technology leadership. There’s one part of that argument I want to make sharper: a Head of IT, a CTO, or any technology leadership role should be filled by someone with a real technical background. Not a project manager who moved up. Not an analyst who was good with stakeholders. Not someone from sales who understood the product on a slide deck level. Someone who has actually built, broken, and fixed technology themselves.
This isn’t gatekeeping. It’s about being able to do the job.
And to be clear, this isn’t only about AI. The same argument holds for cloud, for security, for any major technology shift an organization goes through. AI didn’t create the need for technical leadership. It just raised the speed and the stakes to a point where the gap can no longer stay hidden.
Leadership without technical depth used to work. It doesn’t anymore.
For years, you could lead a technology organization by managing people and trusting your specialists. You set the budget, you set the direction, and you let the engineers and architects handle the details. That worked when technology moved at a predictable pace and the risks were mostly operational: a project ran late, a system went down, a vendor missed a deadline. Painful, but manageable, even if you didn’t fully understand the technology underneath.
This isn’t a new problem. I’ve watched it play out with cloud migrations that never delivered the savings on the business case, and with security overhauls that looked solid on paper and fell apart in production. Leaders who couldn’t tell a real plan from an optimistic one signed off on it anyway, because they had no way to tell the difference. AI didn’t create this problem. It just makes it move faster and cost more when you get it wrong.
AI is the clearest current example
IDC, in research done with Lenovo, found that 88 percent of AI proofs of concept never make it to wide deployment. That number comes from a survey of nearly 3,000 IT and business decision makers, not a handful of anecdotes. It means that for most AI initiatives an enterprise starts, the money and time spent on it lead nowhere.
The reason isn’t the technology. A demo running on clean data in front of ten people in a workshop almost always works. The problem starts the moment you try to move that same idea into a real organization: messy data spread across a dozen systems, security requirements that a demo never had to meet, integration with tools that have existed for fifteen years, and a scale that turns a clever prototype into a system that has to run reliably every day.
Getting past that point takes someone who actually understands how the technology works under the hood, not just what it can do in a controlled setting. And the part that matters most there is shifting. Which model you pick matters less every year, most of them are good enough for most tasks now. What actually decides whether an AI initiative works is how you integrate it into your existing systems and how you feed it your own data. That’s where the real work sits: building the pipelines that keep your data current and clean, connecting the model to the systems it needs to act on, and designing the checks that catch it when it gets something wrong. None of that is something you can hire out and leave unsupervised. Someone at the top has to be able to judge whether the plan in front of them will actually work at your scale, or whether it’s another pilot that will look great in a slide and die a year later.
Implementation is the actual skill
This is where the difference between a technical leader and a non-technical one shows up hardest, in AI projects and in every major technology shift before it. Anyone can approve a budget for “AI adoption” or “cloud transformation.” Far fewer people can look at an implementation plan and know whether it accounts for how the organization’s data actually looks, whether the architecture will hold up once real usage hits it, and whether the team building it understands the gap between a working prototype and a production system that can’t be allowed to fail.
I’ve seen organizations spend heavily on a technology shift and end up with a handful of half-finished pilots, because nobody at the leadership level could tell the difference between a good implementation plan and an optimistic one. The technology wasn’t the problem. The judgment on how to actually build and roll it out at scale was missing, and that judgment only comes from having done comparable work yourself.
What a technical background actually gives you
It’s not about writing code every day as a Head of IT. It’s about having earned the judgment that comes from having done the work. Someone who has designed a system knows what corners get cut under deadline pressure. Someone who has debugged production issues at 2 a.m. knows how confident vendor claims usually turn out. Someone who has actually integrated new technology into a real workflow knows the gap between a demo and a production system.
That judgment can’t be delegated. You can hire the best architects in the world, but if you can’t evaluate what they tell you, you’re not actually leading the technology decisions. You’re rubber-stamping them.
My view
I think technical depth was always a requirement for technology leadership roles, not a nice to have. AI just makes that impossible to hide anymore. The stakes are too high, and the pace is too fast, to lead technology from a distance. If you’re the Head of Technology, the CIO, the CDO, the CTO, or whoever is accountable for how your organization builds and adopts technology, you need to be able to sit in a technical review and understand what’s actually being discussed. Not delegate the understanding to someone else and hope they got it right.
Organizations that put technical people in technology leadership roles will make faster, better calls, on AI and on whatever comes after it. The ones that keep promoting based on people skills alone will keep finding out too late that nobody in the room actually understood what they agreed to buy.