Who Owns AI in Your Company? Get It Off the CEO's Desk

I opened this week's Executive AI Roundtable with a question. Name one process in your company that you handle yourself and would like to hand to someone on your team: you stay accountable for it, they become responsible for it, and AI does most of the work. The conversation went to what has to be true before that hand-off can happen, and most of it was about the team.

The takeaway: AI tooling changes too fast to be a CEO's job, and the systems a CEO builds stay the CEO's problem until someone on the team can run them. Three things make that hand-off possible: state what each system is for and where to check it, teach the team every week, and start each person on the one small task that person hates.

What follows are notes from this week's Executive AI Roundtable discussion, shared under the Chatham House Rule.

Keep the Accountability, Move the Maintenance

The strategic problems in a business are stable: sales, marketing, delivering the right product to meet needs. The solutions are what keep changing. I see technical leaders switching to Codex, then back to Claude, then back to Codex, and a model that came out and was top for a week got beaten the week after. Anything that changes that fast is not strategic, and it does not belong at the C-level.

One founder gave the cost of treating it as strategic. Three years ago they built a RAG system for their data analytics. It worked well, and then the technology moved on: "all that tooling that we built is useless now." They look at the agent systems developers are building and want one, then count the time and the management it takes: "is that what I need to be focusing on when there's so many other things changing in the industry right now?" And underneath that: "Is that all going to just disappear in 6 months when someone releases Asana for Claudebots" for $50 a month?

Where I see CEOs getting in trouble is that they build the automated systems themselves. They are responsible for a system because they built it, and also accountable for it as the CEO. When it starts making mistakes, or stops working, or a security breach gets it switched off, there is nobody on the team who can fix it.

My proposal is narrower than "delegate AI." Take one thing you are maintaining and move the maintenance to someone else in your organization, so a daily or weekly activity becomes a monthly report from the person who owns it: here is how the system is performing, here is what I think we should adjust. You stay accountable. If that person decides an off-the-shelf product is a better fit than the thing you built, that is their decision. The operational decisions, like which AI model to use, no longer lie with the CEO.

One founder named a related assumption: "we have this idea that support and that continuing maintenance is not a thing," that people can go because AI will do the work, with no plan for "what's going to happen when it breaks, and who is bringing in new thoughts into the system." They call AI an average machine. It follows average best practices and doesn't come up with new ways to think about things, so humans need to stay in the loop to identify problems and create solutions. What they want is "the marriage of process, human and AI" rather than process plus AI.

Not everyone at the roundtable accepted the split between stable problems and changing solutions. One founder warned against "associating the strategic with the stable." For many companies, the core of the business is what is changing, and "when the tsunami hits you, it doesn't matter that you delegate it." Some changes in AI are noise, and some change the economics of how a business uses models, especially a business that uses AI agents. Telling them apart is the CEO's work: "Being able to separate the signal from the noise? I mean, that is the job."

I agree, to some extent. A CEO must remain accountable and informed. However, I think it's a rare company that requires even weekly monitoring of new AI tools. A strategy has to say no to most of what is changing. C-level leaders react to a changing competitive landscape, but the AI changes that deserve their attention are the few that matter to the strategy. Even if your strategy requires this level of CEO involvement in AI tooling, building and maintaining the systems that come out of those decisions can move elsewhere in the organization.

What counts as strategic depends on the business. The CEO of a frontier lab and the CEO of a CRM for one vertical have different expectations. But the CEO of a fast-growing company does not have the bandwidth to keep up with every change in AI, and saving $20 a month on a bill is probably not strategic for your organization either.

Another founder added what this means for hiring: "implementation is not the same as creativity." Adjusting ad budgets used to take "an army of people," and AI does that now. What companies still need, in support, marketing, and engineering, are people who can manage a shifting reality.

Delegation Pays More Than It Used To

Management skill used to have a ceiling on what it could return. Being better at delegating was always a good idea, one founder said, but "those things had only a certain amount of leverage and juice we could squeeze out of that in the olden days." Now: "if I was awesome at managing a team of 100 people or 1,000 people, I could actually afford that," because the team would be AI. Getting good at delegating, and at the higher-level work, returns far more than it did.

Another founder pointed out who else has to learn this: "Basically, every person in the team has an AI assistant now. They have to delegate stuff and don't micromanage it, and don't be too unspecific." Most of the people they know are bad at delegating to people, and now the same thing is being asked of everyone with an assistant. Their question for a leader is how you get your team to be good leaders of their AI assistants.

The raw material for that delegation is written. "People who have content and process are winning so much right now," one founder said. Companies with years of written content are winning the marketing game, and companies whose internal processes and SOPs are documented feed them straight into AI and automate them. "It's like all the things that I put off for way too long." Written context gives the model continuity: here is how we have behaved in the past, keep going this way. More on keeping that material alive in AI knowledge capture.

Automate the Job Your Developers Hate Most

One founder went looking for the tasks in the development cycle the team hates most, and documentation was one of them: "It never gets done on time. It never gets done right because you have to do screenshots and videos and all this stuff."

So they built a documentation monitor. It checks every pull request and commit that lands on master and updates or creates documentation to match their documentation flow. Screenshots were the burden, so a screenshot is no longer an image file: "It's a script." Each one is a Playwright script, and when the documentation builds, any script that changed regenerates its image. A feature with many steps can get a video the same way.

The same machinery fixed the part of working with Claude they hated most, the report at the end. "It sends this giant like 6 page thing of things it did. And reading Claude prose is like tearing my eyes out with needles." Now every pull request has to include an annotated video of Claude clicking through what it built, with subtitles saying what it is doing and what it is checking at each step. They watch the video, then tell it what it forgot or what looks wrong, instead of reading six pages and clicking around the app to confirm the work is finished.

From there the documentation flows outward. Internal docs, with the videos, serve Claude and the developers. A second system strips them into external docs. A third turns those into marketing pages, and a fourth feeds the marketing pages into ad generation, producing a video and the images in every size each ad platform demands. One rule holds at the copy step: "we still don't let Claude do any copy, because it's horrible at it." Humans write the copy; AI reshapes it into the ad variants, and the split tests are managed through Claude. The founder's explanation: "the superpower of developers has always been we're super lazy. And so like, what is the thing that I never want to do again? And how can I build a system to do that?"

I asked who in the organization built all of it. "I tried to get the team to do it. I tried." The whole pipeline is the CEO's.

One operator has Claude update the documentation at the end of every session, straight to the docs rather than through a pull request, because the support bot that answers customer questions runs on that documentation and has to be at the same level as the product. And one marketing team, given a hand-built UI for managing pages, ignored it. Their marketing sites moved to Astro with Claude behind them, and the team writes a page, describes the layout, and tells Claude to upload it.

Give Your Team a Reason to Learn It

CEOs, and technical ones especially, are excited about AI. Much of the team listening is worried about their job. Part of the leadership role now is showing people that learning this is good for their career. Excel is the comparison I use: a few people are wizards with it, and ordinary people open it to add some numbers and make a bar chart. AI is going to be that kind of basic skill. Nobody expects every employee to be at the highest level, and the case to make to them is the rote work it takes off their plate and the more interesting work it leaves.

One founder dated the best time to start: "the best point in time to grab your team and teach them AI and show them stuff and convince them was three and a half years ago." Their first town-hall demo of ChatGPT was in January 2023. "The second best time is today." Their prescription is to teach the team weekly, because everything changes weekly.

One founder's employee returned from leave, and all of that person's tasks had been automated by AI. The company offered them a place on the onboarding team, helping customers set up the software, which would have been a poor fit before AI tools. With Claude and the documentation, the technical side is learnable now, and the person has moved into a better job.

Another founder has spent the last six months bringing their team onto AI and reports happier customers, because the team is more responsive, solves bigger problems faster, and no longer lets things linger. "They are themselves having a whole lot more fun."

My own version is from AMD. When the company created AMD64, I was on a software team there, and we moved our tooling from DOS and Windows to Linux. The company ran weeks of training on Linux and kernel internals; the trainers were good, and most people, skeptics included, came out excited about custom kernels and all that control. Only one die-hard DOS person remained skeptical. It was a large transition, and I think it went well because the training led us through it instead of leaving each of us to struggle alone. We did hands-on labs, asked the trainers questions, and learned how they thought about the transition, and that built confidence across the team. That is what seems to work: hands-on training from someone people can question, with a dose of optimism on their behalf.

Start With the Small Thing They Hate

One founder's approach to the people furthest from AI is to look for "a small thing that gives a person superpower with AI. The thing that they hate at the moment, that you force them to do."

Their sales team hated documenting calls in the CRM. "They love talking, and they type with two fingers, and it's awful, so we gave them Wispr Flow, and now they love it." Each call is now documented well, and that documentation feeds customized follow-up emails, which the team likes because it is work they no longer do. Their accountant still handles paper receipts, so the founder showed them how to build a Claude skill: photograph the receipt, and it generates the slip that used to be filled out by hand. "Even small things that you hate accumulate, and it's awful." Solving one is easier than the complex agent you wish they would build, "because it gives you the feeling that you can do that."

Showing beats telling. It is easy to say this will make your life better; having someone do it themselves is a different experience.

The interface can be part of the fix. Nothing says an employee has to use a chat window. For example, I've helped a client build a small web interface specific to one role: put the inputs in, press a button, get the output. It's just software. Under the hood, it runs AI systems; the person in the role sees a simple web page. The pushback one founder hears, "this is too complicated," is partly about the interface and partly about the person, and the two answers differ. A chat window can be replaced. A skill-set fit has to be judged against the whole organization, remembering that people have more than one skill and only one may be showing up at work.

Expect a Spectrum, and Decide Sooner

In an organization of fifteen or twenty people, you will almost certainly have one or two people with no interest in AI. Some engineers are thinking what a lot of CEOs are thinking: I am ready to retire; I do not want to learn this new thing. If you cannot convince them it is interesting, you may have to let them go.

Most people are somewhere between that and enthusiasm, and the pessimists are reacting to real things. People at frontier labs say a lot of foolish things about the end of jobs, which puts technical people off. Employees who are not paying for a model use free or old ones, get worse results and more hallucinations, and conclude from their own experience plus the news about lawyers filing hallucinated case law that AI does not work. Their experience with AI is much worse than yours. Those people can be convinced by trying better models themselves, and by noticing that humans are sometimes confidently wrong too. Delegation is a skill either way: you need a feedback loop that keeps checking the output is still appropriate for whatever it is being used for. More on that loop in Close the AI Feedback Loop.

One founder added a fourth kind of person: convinced, enthusiastic, and using it badly. A team member asks the model a question and treats the answer as the decision: "AI said this, and so let's do it." The founder's comparison was the 1980s, when computers were going to optimize everything automatically, and then people learned "garbage in, garbage out, and it's just another tool." We seem to be getting to that point with AI, though people have been failing to internalize garbage in, garbage out since then at least.

Another founder's reason to have some sympathy for the people who struggle: the cause is rarely talent. "It's because they signed on for a job for stability." The people two layers down did not join for change. They joined for a good job with mastery, autonomy, and purpose, and none of those three is about change. Leaders are entrepreneurial and go looking for change, so asking people who chose stability to accept instability is a bigger request than it looks from the top. Their other observation: a company's turnover usually happens once, when new management arrives, and then settles. This change restarts it, and firing people is one of the most emotionally draining things a leader does.

This argues for deciding sooner. Leaders usually know well in advance that someone has to go, and they procrastinate, maybe because that person still does a couple of things the leader needs. The team is waiting for the decision and is relieved when it comes; a visibly underperforming colleague hurts everyone's performance. The job market looks hard right now, but I still think making these decisions sooner is better for everyone involved, including the person. Letting someone linger in a role they are not suited for is not necessarily a favor.

Design the Checkpoints Before You Hand It Over

A system can be handed over only if the person receiving it can see inside it. On one of my recent projects, I let AI have too much freedom at the start, and it built elaborate machinery I then spent time tearing down. The way out is to think from the big picture before anything gets built: what is this process for, where do we want to observe what is happening inside it, how do we know the output is good, and where are the guardrails? Then design so those checkpoints exist. Left alone, the model can build a giant unmanageable blob, or include a faulty assumption. It is a new kind of engineering, and it is also what makes a hand-off possible. A system with observation points and guardrails is one someone else can run and maintain; a shapeless AI blob is technical debt that nobody else on the team can understand or fix. More on breaking work into inspectable steps in AI delegation: what founders hand off.

Where to Start

• Decide whether AI changes matter to your strategy. In most companies they don't need weekly attention from the CEO, and tool choice and upkeep go with the system to its owner.
• Pick one system you maintain and name its owner. Turn your daily check into their monthly report, and keep the accountability.
• Write down the processes you have been putting off. Documented SOPs and years of content are what the model works from.
• Automate the task your developers hate most, and make the output reviewable by video instead of prose.
• Teach the team weekly. The second-best time to start is today's town hall.
• Start each reluctant person on the one small task they hate, and have them do it themselves.
• Replace the chat window with a form where the role calls for it.
• Put better models in front of the pessimists. Free and old models are producing their evidence.
• Decide sooner about the people who will not make the transition. The team is waiting.
• Design observation points and guardrails before you build, so the system can be handed over.

I launched Executive AI Build during this session. The first cohort starts in January with eight seats: details and a free 20-minute call.

Resources From the Roundtable

• Claude Code — the harness behind the documentation monitor, the per-PR review videos, the ad pipeline, and the page uploads the marketing team now asks for by chat.
• Playwright — screenshots and videos as scripts, regenerated on every documentation build; one founder uses it for scripted browser work and a separate agent-driven browser tool for one-offs.
• Astro — the site framework one company moved its marketing sites to, with Claude writing and uploading pages.
• Wispr Flow — dictation for a sales team that types with two fingers; the CRM documentation that followed now feeds customized follow-up emails.
• Tailscale — how one founder reaches the Mac mini that runs their whole pipeline from wherever they are.
• Remotion — raised as an option for generated video; the founder stays close to plain HTML because Claude works with it better than a third system.