Setting an AI strategy without a CTO of your own

Almost everything written about AI strategy is written for organisations with a technology function. It assumes there is a CTO to own the plan, a data team to assess feasibility, and some kind of governance forum to approve it. If your company has between fifty and three hundred and fifty people, you probably have none of those, and you have noticed that the advice stops being usable around paragraph three.

This page is for that situation, which is the normal situation.

What the missing CTO was supposed to do

It helps to be precise about the gap rather than treating it as a general absence of expertise. In a company that has one, the CTO does four separable things in an AI decision:

They judge whether something is technically feasible and roughly how hard. They know what the existing systems can and cannot do. They can tell whether a supplier is describing something real or something aspirational. And they own the decision, meaning there is one person the board holds responsible for the technology bet.

The mistake is assuming you need to fill all four with one hire. You do not. Three of them can be sourced differently, and the fourth cannot be outsourced at all.

Two people talking. Without a CTO, the strategy conversation belongs to the people who know the operation.

Who covers each piece in a company without a CTO

Feasibility judgment: buy it by the day, do not hire it. This is genuine specialist knowledge and it is needed in bursts, not continuously. A few days of an experienced technical person at the point of a decision is worth more than a permanent hire who then has to find things to do. It is also the cheapest of the four to fix.

Knowledge of your own systems: you already have this, it is just not written down. Someone in your company knows why the ERP does that strange thing with order lines. Usually that person is in finance or operations, not IT, and nobody has ever asked them to write it down. See Hoe je AI-kennis verankert for why leaving it in one head is a risk in its own right.

Judging suppliers: this is a skill you can partly systematise. You do not need deep technical knowledge to ask a supplier which decisions their tool makes autonomously, what happens when it is wrong, what they warrant about output correctness, and who else your size is using it. The answers to those four questions separate real products from demos more reliably than a technical audit would.

Owning the decision: this one is yours, and it cannot be delegated. This is the part that matters most and gets the least attention. Every serious failure we see is not a failure of technical judgment; it is a case where nobody owned the outcome, so nothing was decided and the pilot drifted until it quietly died.

A pen over a clipboard. A strategy you can write on one page is a strategy people can follow.

The four functions, and how to cover each without hiring

The last row is the one to read twice. Three of the four functions have a workaround that costs very little. The fourth has no workaround at all, and it is the one most often left vacant because it does not look like a gap on an org chart.

The one-page strategy

Without a technology function, a strategy that runs to twenty pages will not be read or followed. What works at this size is a single page answering four questions, reviewed every quarter.

Where are we betting? One or two areas of the business, named. Not "become an AI-driven organisation." Something like "we are betting that quoting and scheduling can be substantially faster, and we are not betting on anything customer-facing this year."

What are we deliberately not doing? This line does more work than the previous one. A strategy without exclusions is a wish list, and at this size the main risk is not choosing wrong, it is spreading thin across five half-projects.

Who owns it? One name, at director level. Not a committee.

What would make us stop? Agreed in advance, while everyone is calm. Something like: if after three months the tool still needs heavy editing more than a third of the time, we stop and reconsider rather than persevere.

That is the whole document. It fits on a page because at this size, anything longer describes an organisation you do not have.

Why the enterprise version does not scale down

The standard corporate approach spends its first phase building capability to make decisions: a governance structure, a centre of excellence, an assessment framework. That is rational when you have four thousand people and forty simultaneous initiatives to coordinate.

With eighty people, the coordination problem does not exist. There is one decision-maker, everyone knows each other, and building a governance layer to manage a conversation that could happen in a corridor is pure overhead. Your advantage over a large company is that you can decide on Tuesday and start on Wednesday. Adopting their process throws that advantage away and replaces it with their disadvantages.

The things that do scale down are narrow: writing down what you decided, deciding in advance what would make you stop, and being explicit about who owns it. Those three are cheap at any size and are the parts most often skipped.

About this page

The four-function breakdown of a CTO's role in an AI decision is Radical's own framing, developed from working with companies in exactly this size band. The one-page strategy structure is the format we use in practice. No external framework is being restated here, and nothing on this page requires you to hire anyone. Written by Radical's own team; no client data was used.