Don't Be a Detached CEO

When you decide to build something with AI, you are committing more than money. You need time from the developers, time from the people who will test it, training, coordination, and room for all of that alongside the work the company already has to do.

And if you build the wrong thing, the cost can follow you into the next attempt. It is demoralizing to put that much effort into something that doesn't work, and from my perspective, the risk to future efforts can cost more than the money you spent.

That is why I think business owners need to spend time exploring AI themselves. You need to understand what the technology can do and how it connects to your business strategy, even when someone else handles the technical work.

You can trust your technical team and still take responsibility for learning enough to have that conversation. It doesn't require becoming an engineer or being the person who solves everyone's problems.

I didn't know where to start either

The scariest question for me when I started with AI was where to begin. I was looking at it as an owner, trying to understand where it fit in my own business, knowing what a wrong decision could cost.

In one of my companies, we started with the basics, what a language model was and what it could do. We tried putting it into all kinds of work, and most of those early ideas or projects failed, but we kept exploring.

For me, a big change came when AI started helping with things I hated doing manually, copying and pasting content from different places, organizing data and files, configuring spreadsheets and creating document templates.

I also used it to test workflows and configurations, and to read logs and data to help identify bugs and problems. Those were things I understood from doing the work myself, so I could recognize what the help meant.

Working with an assistant on my computer made the possibilities much clearer. I created a folder of text files with information that mattered to me, and worked with the assistant to gather information, test tools and draft documents.

There is a difference between reading an answer about how to do something and watching a tool work with your files. Seeing that in my own work gave me more things to ask about.

That is my experience, not a promise that your company should follow the same path or build the same things. Start with something you recognize and develop your own understanding from there.

AI leadership: learn enough to join the conversation

When I say understand AI, I mean knowing what the tools can do, seeing how other businesses use those capabilities and learning the common terms well enough to follow a conversation about them.

That can take you a long way without going deep into how the software is built. You can ask what AI can help with in 3D modeling or video editing, or what it means for an assistant to use a computer, without deciding to build any of those things yourself.

If your experience stops at asking a chatbot to write text, go and look at work beyond that, then ask what the tool actually did and what the person still had to do.

And when you look at another business using AI, pay attention to the work around the tool. What were they trying to change, what information did they give it, and how did people use what came back? Their example can give you something to consider without becoming a plan you should copy.

The language matters too. If someone uses a term you don't understand, ask them to explain it through the work they are proposing.

If they say an assistant needs access to a system, for example, ask whether that means reading information from it or being able to change something inside it.

You don't need to pretend to know the answer before asking. Getting comfortable with those questions is part of learning, and I would rather have that conversation than agree to something I don't understand.

A capable technical team can advise you on what is possible and how to build it. Your understanding helps you connect that advice to what you want the business to do, instead of leaving the entire conversation to the people who know the tools.

You can explore without a company project

But how do you start learning when you don't yet know what would be useful? You need room to try things before every idea becomes a proposal for the company.

If you are going to commit developers and ask people to change how they work, you need a reason for that investment. Personal exploration has a different purpose, you are finding out what the technology does so you can think about it for yourself.

You can be curious about whether an assistant can organize some information without making a plan to change how the whole team organizes theirs.

If every experiment has to come with a business case, you are asking yourself to explain the value of a tool you haven't had the chance to understand yet. That puts the decision ahead of the learning that could help you make it.

Some of what you try will suggest a business use, and some won't. You don't owe the company a new system every time you learn something.

Try something you want to understand

I would start with a question or a piece of material you know well, something where you can look at the result and judge whether the tool did what you asked.

For example, take copies of non-sensitive notes you are allowed to share and ask an assistant to help organize them into a document you could use.

If the tool can work with files, keep the experiment in its own folder. If you're using a chat tool without that access, paste the text and work with the answer there.

Keep its access limited to what you are trying. Anthropic's safety guidance recommends a dedicated folder and care with sensitive information, which is a sensible boundary for this kind of exploration.

Then look at what comes back and keep working with it. If something important is missing, explain what you needed and try again.

Notice what you had to tell it, what it handled and where it went wrong, because that is the experience you are there to get.

When you see another business using AI in a way you hadn't considered, bring that question back to your own exploration. Ask how that work is done, get the unfamiliar terms explained and try the part you can reasonably test yourself.

You can also ask the assistant what else it could help you do with the material you've been working on. Treat those suggestions as things to investigate, not proof that it can do everything it describes.

A useful experiment doesn't commit your company

Something working for you in an experiment doesn't mean it is ready for other people to rely on in their daily work. Deciding what to put into a well-designed workflow for the company is a separate decision.

You may learn that the tool needs information you can't give it, or that the work still takes more help than you expected. You can leave that idea alone and keep exploring something else, without asking the company to pay for a build just because you were interested in it.