← All articles
AI Driven Development

The first conversation with a CTO who wants to "just introduce AI"

It is always the same conversation. And whether anything comes of it is decided in the first ten minutes.

I have had this conversation many times by now. A CTO, a CIO, sometimes the CEO himself. It almost always begins with the same sentence.

The sentence it starts with

"We need to introduce AI now too."

Sometimes in variations. The board wants it. The competition is doing it. A developer showed something that looked impressive. The budget is there, it just has to be spent.

I understand the sentence. It is honest. But it is not a goal. It is a feeling that you are missing something. And a feeling cannot be implemented.

My four counter-questions

I then always ask the same four questions. Not to show anyone up, but because the answers tell me whether we can work together.

1

Which decision should be made faster or better in the end? Not which tool, not which model. Which decision.

2

Who in your company is responsible for the data this is supposed to run on? A name, not a department. Someone who can say where it comes from, who writes it, who changes it, and which system counts when two systems say different things.

3

Does anyone know the data quality of your company, in numbers? Not "we have a lot of data". How complete it is, how current, how unique. How many customers exist twice. How many mandatory fields are empty. How often master data in two systems does not match. And whether someone measures that regularly, or whether we are asking it today for the first time.

4

What happens when the AI is wrong? Because it will be wrong. Who checks the result before it takes effect? How do you notice a mistake, and how fast? And what is the way back: to a human, into a queue, or nothing at all?

What the answers reveal

The first question is often followed by a pause. Then a list of ideas: chatbot, document search, code assistant. Those are tools, not decisions. If we get from the list to a decision together, that is already half the success. "We want a case worker to check an application in two minutes instead of twenty" is a decision. You can work with that.

The second question usually gets a name, and then: "But he has no time." That is the most important piece of information in the whole conversation. Fact is: if the person responsible for the data has no time, the project will fail. No matter how good the model is. I say that openly. And if no name comes but "that is distributed", that is an answer too: then the data belongs to nobody, and what belongs to nobody is maintained by nobody.

The third question is usually followed by silence. Almost nobody knows the data quality of their company in numbers. That is not a problem. Not wanting to know is. Without data quality nothing works, the best model computes with what it gets. That is why the first step is never the model. The first step is measuring: duplicates, gaps, contradictions, age of the data. Then define which source counts, who maintains it, what happens on contradictions. That is called configuration management, and it sounds more boring than it is. And then someone has to pick up the broom and clean up. That is unspectacular, it takes time, and it is the part everyone wants to skip. Whoever skips it trains a model on garbage and is surprised by the result.

With the fourth question I notice whether someone has ever operated a system that makes mistakes. Whoever says "that must not happen" has not. Whoever says "then it goes to a human, and we log it" has understood what this is about. A model is not a program that is right or wrong. It is mostly right. And for the mostly you need a human who sees the exception, a place where the mistake becomes visible, and a way for the job to get done anyway. Whoever does not plan that at the start plans it after the first incident, under pressure.

I do not need a CTO who understands AI. I need one who knows which decision he wants to improve, who in his company knows the data, and how good that data really is.

When I say no

There are conversations after which I decline. Not many, but they exist.

When the goal is to have something to show within a quarter, no matter what. When nobody knows the data and nobody wants to free anyone up. When the idea is that AI is a tool you install, and after that it runs. In these cases I would be taking money for something that will not work. I no longer do that.

I then usually say: Start smaller, without me. Take one developer and one coding agent and one real ticket. See what happens. Call me when you know which decision you want to improve.

How a good conversation ends

A good conversation does not end with an offer. It ends with a task. For the CTO.

Find the one decision. Talk to the person who knows the data and ask what they would need. Get an honest answer on how good the data is, and plan the clean-up. Think about who should see the first mistake. Then we talk further.

Those who do this come back. And then we build something that runs in day-to-day business. The others have bought a tool a quarter later that nobody uses. I have seen both often enough.

What stays

"Introducing AI" is not a project. Improving a decision is one. And without knowing how good the data is, it is neither. The difference is decided in the first conversation, and usually in the first ten minutes.

How this text was made

Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.

Read more All articles

Honest thinking.
Straight to your inbox.

One or two emails a month. No gloss, no spam.