← Blog

Leadership

The First Question a CEO Should Ask About AI Is Not the One They Are Asking

The question on most boardroom tables is how to implement AI. The better question is whether the organization is ready for it at all — and that readiness is the part of the job a leader cannot delegate.

In most boardrooms today, the question on the table is some version of "how do we implement AI." It is the wrong place to start. The better question, and the one that separates the businesses that get real value from the ones that accumulate expensive pilots, is whether the organization is ready for AI at all.

This sounds like a delay tactic but it isn't. The gap between a model that works and a model that changes something is almost never technical, and a leader who spends the first months of an AI effort asking engineering questions is usually solving the wrong problem.

The technology is ready. Your organization usually is not.

When an AI initiative fails to deliver, the instinct in the executive suite is to reach for a technical explanation. The model was not good enough, the vendor oversold, the data scientists missed something. That explanation is comforting because it is someone else's problem, and it is rarely the right one. In most cases the model worked. It produced the output it was built to produce. What was missing sat entirely on the organizational side — a process that was never designed to feed the model the right inputs, a team that did not trust the output, a decision no one was willing to own.

Implementing AI is a change-management problem at least as much as a technical one, and the technical half is usually the more tractable of the two. As an effort moves from a working demo to a real business implementation, the order of difficulty becomes clear. Implementing AI is first and foremost a process engineering problem, then a data engineering problem, and only finally a model problem. The model is the last and smallest of the three. The demo that impressed everyone in the room solved the easy part. Code is patient and literal. Organizations are neither.

The resistance is real, and it is rarely about jobs

The assumption baked into most executive thinking is that the resistance to AI is fear of lost jobs. That assumption shapes how leaders communicate, how they sequence rollouts, how defensive they become. The friction rarely lives where they expect it to. On balance, the wave of AI adoption has not produced the job losses that the loudest voices, many of them with something to sell, have promised. The disruption is real, but the day-to-day resistance inside a company comes from somewhere more ordinary, and it runs through one thread: incentives.

Your people are measured on something, and a new AI effort almost never lines up cleanly with what they are measured on. A regional manager rewarded for hitting a quarterly number has no reason to invest weeks in labeling data whose payoff lands two quarters out and accrues to someone else. Middle and senior managers, the ones whose buy-in actually determines whether a system gets used, often cannot see how the effort helps them personally win, and many quietly suspect it threatens the very expertise that made them valuable. This is a classic principal-agent problem wearing new clothes. The interests of the people who must do the work are not aligned with the interest of the organization that wants the outcome, and no model resolves that. Until the incentives are set so that the people closest to the work succeed when the AI effort succeeds, a technically perfect system will sit unused.

What has to be true before a model can matter

Picture a common AI ambition: a business sees an opportunity to capture margin that is sitting on the table, and someone proposes a model to go get it. The technical solution is usually within reach. Two things have to be true before that model can change anything, and neither of them is technical.

The first is conviction at the top. An opportunity that has sat untouched for years tends to get filed under the way things are rather than the list of things to fix, and capable executives carry a natural bias toward the problems they already know how to solve. A model aimed at a problem no one has decided is worth solving will never get the mandate it needs, however well it performs. So the first piece of work is making the problem matter to the people who own it. The leader has to decide, deliberately, that this issue is worth attacking rather than tolerating.

The second is ground truth, and this is where most efforts quietly die. Anything that learns needs a reliable record of what the right answer actually was, and most organizations simply do not have one, because they never had a reason to build it. The principle is old and unglamorous: what gets measured gets improved. Before AI can improve an outcome, you have to know what outcome you are chasing, you have to be able to measure it, and you have to have been measuring it long enough to have a record worth learning from.

Consider a plumbing business that has asked its technicians to close deals in the field. To bring any AI to bear, you first have to answer a question the business may never have answered for itself. What actually matters here, the close rate or the dollar value of each job? Those are different objectives, they reward different behavior, and a model built for one will actively work against the other. Once you have named the objective, you need a process that captures it on every job, consistently, so that a true record accumulates. Only then is there something for AI to improve. Skip those steps and you have asked a machine to optimize a number the business itself never defined.

This is the trap, and it is worth stating plainly. Most AI implementations prescribe the medicine before diagnosing the disease. They reach for a model before anyone has established what matters, quantified it, and built the process to measure it, and then everyone wonders why the problem was not solved. The diagnosis is the work. The model is what you reach for once the diagnosis is done, and in that sequence AI is first a process engineering problem, then a data engineering problem, and only finally a model problem. The model is the last and smallest of the three.

The same shape, in two more places

The pattern repeats across very different problems, and once you see it you start to see it everywhere.

A manufacturer wants computer vision to catch defects on the line. The ambition is reasonable and the technology exists. But today the defects are caught by one veteran inspector who has done the job for twenty years and rejects parts on instinct, and who has never written down what he rejects or why. There is nothing to train a model on, because the knowledge lives in one person's head and has never been captured. And no one has yet made the harder decision about whether the organization is willing to formalize a judgment that has always been tacit. The model is the easy part. The capture process and the organizational decision underneath it are the project.

Or take a leader who wants AI to optimize marketing spend. It is among the most common requests we see, and almost always the business cannot yet attribute its performance to a channel. Money goes out, revenue comes in, and the connection between the two is assumed rather than measured. There is no ground truth on what actually drove a conversion, which means there is nothing for an optimization model to optimize against. You would be asking AI to improve a number you cannot trace. The readiness project here has little to do with the optimization model. It is the attribution layer that has to exist beneath it, and building that is months of unglamorous work no vendor demo will show you.

In each case the desire is for a model, and the missing piece is a process and a measure of truth that the organization has never had a reason to build. The model is downstream of all of it.

The one thing a leader cannot delegate

The appeal of AI is that it lets you delegate execution. You can hand a pricing calculation, a routing decision, or a first-draft analysis to a machine and let it run, and for the right tasks that is exactly what you should do. But the decision about what to delegate, to what extent, and whether the organization is ready to act on the result is not something you can hand off. That judgment sits above every model, and it stays with you.

So the first question is not how to implement AI. It is whether you are willing to make a given problem matter inside your organization, and whether you are prepared to build the process that lets a working model change the outcome. The technology will almost always be ready before you are. Getting ready is the part of the job you cannot outsource, and it is where the real work begins.