AI didn’t expand the CTO’s job. It changed when the business needs the CTO’s judgment. The org chart hasn’t noticed yet.
A Tuesday, a few weeks ago. I spent the first hour of the morning with two spreadsheets open side by side. Two AI platforms had each read the same medical record, a couple hundred pages of scans and faxes, and disagreed about how many doctor visits it contained. One found roughly half as many as the other. The dashboards couldn’t settle it. Somebody had to read the record, so I did.
By late morning I was on a cost curve: what a page costs to process on one platform versus another, and how that number moves when the model underneath changes. After lunch, positioning for a product offering that didn’t exist a year ago, then a staffing model for a team that now runs part of its work through agents.
Three different jobs, by the look of it. The same handful of facts underneath all three. What the model can do with a messy page. What it costs to do it. Which data the business can reach, and how fast.
Six months ago I wrote that the CTO role doesn’t die in transitions. The shape changes and the function persists. I still think that’s right. But the shape this time has a feature I didn’t fully see in May, and that Tuesday is what it looks like from the inside.
When the cost of a page decides the product
For most of my career the sequence ran roughly one direction. The business decided what to sell. Product decided what to build. Technology figured out how to deliver it reliably and at an acceptable cost. Technology was in the room, often early, and its opinion shaped what got sold. But the technical inputs held still long enough for a planning cycle to finish. You could price a product in January on cost assumptions that were still true in December. That’s the part that changed.
Take a records business processing documents with AI. At today’s cost per page, you have a premium product for a narrow set of buyers who can justify the spend. Cut that cost by two-thirds and the addressable market changes, and so does the competitor set. Cut it by an order of magnitude and you’re in a different business: volume, bundles, maybe platform pricing instead of per-transaction fees. Those aren’t three price points for one product. They’re three different companies, with different buyers, different channels, and different competitors. Cost alone doesn’t pick which one you are; pricing power, distribution, and quality still do their work. What cost decides is which of the three are available to you at all, and that depends on model capability, inference economics, and a few architecture choices that nobody outside the technology organization is positioned to evaluate.
Cost isn’t the only variable, which is what makes this harder than a procurement question. Three things have to be read together. Whether the model can do the work at all on the pages you actually receive. Whether the economics hold at scale. And whether the data can be reached in time, under the right authorizations, at volume. Possible, viable, deliverable. A product can clear one and fail the other two. A year ago the capability wasn’t there. Six months ago the cost wasn’t. The data access question is still being answered. Product strategy can’t be finalized until all three are, and all three are moving.
So the sequence inverted. Not because the CTO reached for strategy, but because the inputs strategy depends on now sit with the technology organization and change on a model-release cadence instead of an annual planning one. Consumption economics did a version of this in the cloud era. This is the current shape of the same inversion, compressed, with the facts moving faster than the decisions built on them.
The decisions moved. The organization didn’t.
The difficulty isn’t that technology leaders suddenly have more important decisions to make. It’s that more business decisions now depend on technical facts that are still changing while the decisions are being made.
From the seat, it feels like this. You’re asked to validate the AI economics behind a new offering, to say whether the product is viable, to defend an investment priority to a board, and to deliver the operating savings the plan already counted. Accountability for those outcomes lands on you. Influence over them, you have. Formal authority over the assumptions underneath them, often you don’t. Some CTOs hold broad executive mandates and feel this less. Many don’t, and the misalignment between what they’re accountable for, what they influence, and what they actually control is the texture of the job right now.
A concrete version. The financial plan assumes savings from AI-assisted engineering. The same plan expects the modernization roadmap to hold its dates and a new AI product line to ship. Each assumption is reasonable on its own. Together they describe a team that gets smaller while doing more, and the person accountable for all three didn’t set any of them.
Meanwhile nothing that was already running stops. The legacy platform still needs people. Security and compliance obligations didn’t shrink because an agent showed up. Modernization keeps its schedule. Leadership sees AI-driven cost reduction, which is real in places, while the technology organization still carries the operational load it carried before, plus the new work of evaluating, governing, and integrating the thing that’s supposed to reduce the load. New product opportunities arrive faster than the company can absorb them. And every model generation reprices a decision somebody made four months ago in good faith.
That last one deserves its own line. A decision about which platform to build on, what a capability should cost, or how many people a function needs can be correct in March and wrong by July without anyone having made a mistake.
Control without owning everything
Ownership gets discussed as if it were about assets. Build or buy. Own the model or rent it. That framing is too blunt for where this is going.
You can rent the inference model, outsource a chunk of development capacity, run on managed infrastructure, and partner for data access, and still run a company that controls its own direction. What has to stay inside the building isn’t a list of things you possess. It’s a set of decisions you keep the ability to make on your own: what the product is, what the quality bar is, how the proprietary data is structured, where the integration boundaries sit, what a page should cost, and when to switch vendors.
The test for each is the same. If the vendor changed terms tomorrow, could you still make this decision on your own information and your own timeline? One example from the evaluation work: a regression suite that runs identical test cases against two platforms isn’t a quality tool, or not mainly. It’s the thing that keeps the vendor decision yours. Without it, the decision belongs to whoever you’re already paying.
For a PE-backed company the stakes here are explicit. A capability built on a vendor’s platform still has value at exit. What a buyer discounts is a capability the company can’t reprice, can’t move, and can’t prove works without the vendor’s say-so. Decision rights, your own evidence, and the structures that make a switch possible are what hold that value up.
Three decisions that keep coming back
The practical part of this isn’t a checklist. It’s three decisions I’ve faced repeatedly since May and expect to keep facing.
What you can responsibly commit to. A forecast and a demonstrated result look identical on a slide. They aren’t, and there’s a third thing between them that gets mistaken for both. A capability that gets nine of ten hand-graded records right is a test result. It tells you about those ten records. A capability that holds that rate across months of production volume, measured, is a validated metric. A capability that will get there once the next model lands is a forecast. A board that funds forecasts as results will eventually stop funding you, and a board that funds a ten-record test as a production number will stop sooner. The evidence has to be as strong as the decision resting on it. Separate the three in your own reporting before someone else does it for you. The organization will push you to blur them, because the plan already assumed the number. Don’t.
What has to stay reversible. Model selection, vendor dependency, parts of the infrastructure, and some of the operating model, because the economics will change again before the hold period ends. But reversibility isn’t free, and this is where the advice usually goes soft. Every abstraction layer is engineering hours. The no-code platform you can’t easily port is also the one a non-engineer can iterate on without filing a ticket. Reversibility is a cost decision, not a principle. The honest version is choosing which three or four things are worth paying to keep open and letting the rest be what they are.
What stays within your control. Quality criteria. Proprietary context. Integration boundaries. And the one that’s easy to miss: the information you need to make an independent decision at all. If the only evidence about whether a capability works comes from the vendor’s dashboard, you’ve already given up the decision. Generating your own evidence is unglamorous work. It’s also the work that keeps the first two decisions yours to make.
Still in the middle of it
I want to be careful about what this piece claims. Much of what I’ve described is in motion: strategic plans, active programs, capabilities that perform in evaluation and haven’t yet proven their projected economics in production. Some of it will come in under the forecast. Writing from the middle of a transition means writing without the ending.
For most of my career the problem was making technology capable of delivering what the business had already decided it needed. Increasingly the problem is knowing what the business can become because of what the technology now costs, and getting that read right while the number is still moving.
In May I argued the role evolves and the function persists. That holds. What’s being redrawn this time isn’t the line between the CTO and the engineers, or between the CTO and the CIO. It’s the line between technology and the business itself.