Skip to content

AI adoption is staff work, not a tool you buy

The tool is the cheapest decision you'll make. The discipline around it is the whole game - and it looks a lot like the boring engineering discipline it always did.

AI adoption is staff work, not a tool you buy

Ran writes Founder Mode from the trench, and this week, he goes after the most expensive mistake in enterprise AI: treating adoption as a shopping problem. Buy the best model, hand out the seats, watch the usage line climb - and then wonder why nothing in the business actually moved. His argument is that the tool was always the cheap part. The discipline around it - who owns it, what you measure, the groundwork nobody wants to do - is the whole game, and it looks a lot like the boring engineering discipline it always did. Read it before your next rollout meeting. — Muximus


The hardest part of putting AI to work inside a company was never picking the model. It is everything around the model - the training, the ownership, the measurement, the groundwork - and almost everyone skips straight past it to the tool-selection screen.

That skip is why the rollout stalls.

Leadership treats it as a shopping trip: pick the best assistant, buy the seats, watch the usage line climb. Meanwhile, the people who are supposed to use the thing feel the opposite of momentum. They feel a train pulling out of the station while someone yells at them to learn every new tool before it is gone. That fear is the tell. It is not fear of losing the job. It is the pressure to master everything at once that freezes people solid, from the most junior person on the floor to the most senior in the room.

I have watched this movie before. In 1997, every company wanted the internet, and half of them thought that meant buying the right software. "Make me an internet" was the ask. It failed for the same reason "make me an AI" fails now: the technology was never the hard part. The organization was.

So here is the actual work. Ten moves that decide whether adoption takes or dies. None of them is about the model.

1. Pick one tool and stop shopping

Pick a tool. Claude, ChatGPT, Gemini, Copilot, whatever. It genuinely does not matter which one. The company that spends three months benchmarking models to crown the best has already lost the three months, and it has taught everyone below that the tool is a hard decision, so they freeze, waiting for a verdict, scared of committing to the wrong thing.

The perfect model is a moving target. This quarter's best is next quarter's second-best, and the gap between the leaders keeps closing. A team that actually uses a good-enough tool will lap the team still comparing spec sheets. Choose one capable thing and commit. The commitment is worth more than the choice.

2. Make training a process, not a checkbox

Train people - but not the way most companies mean it. A one-hour webinar so someone can tick a box is not training. It is theater with a completion certificate.

Real training is a process, and it has to be about their work: their actual tasks, their actual workflow, not "here is what a large language model is." Abstract training evaporates by Friday. If what you teach does not map onto what someone actually does at 10am on a Tuesday, they will nod, close the tab, and never touch it again. Teach the job with the tool inside it, over time, not the tool in the abstract, once.

3. Measure outcomes, not tokens

Most AI dashboards measure the wrong thing on purpose, because the wrong thing is easy. They count tokens burned, seats activated, messages sent - and when the line goes up, they call it adoption.

It is activity theater. Usage is motion, not results. A team can torch a fortune in tokens and move nothing that matters, and another can use AI sparingly on exactly the right three tasks and change the shape of its week. Counting tokens tells you people are typing. It tells you nothing about whether the business got better.

The point of this was never "use AI." It was improve the business. So measure the thing you actually wanted - cycle time, error rate, output per person - and measure it over time, because this is a process, not a launch. If your dashboard cannot tell you what got better in the business, it is not a dashboard. It is a screensaver.

4. Build a community of champions

You already have the people who love this stuff. Every company does. Find them and give them a place to be out front.

A bottom-up community of champions - people who use AI hard, trade what works, and pull everyone else along - does more for adoption than any top-down mandate. The keyword is bottom-up. Build it from the ground, from genuine enthusiasm, and it becomes the engine of the whole thing. Build it as a committee with a charter and a slide deck, and it dies in its first meeting. This is the hardest of the ten to do well, and the most valuable when it works.

5. Don't leave management behind

The layer that is most stuck is usually the top one. Leaders are trapped: they tell everyone to use AI while quietly not knowing how to use it themselves, and they are too embarrassed to say so. A mandate handed down by someone who cannot run the tool is a mandate nobody believes.

Fix it directly and privately. Separate training for the management layer, and real one-on-one time afterward, so the people setting the expectation can actually meet it. You are not going to shame a VP into learning this in a room full of their reports. Give them a door they can walk through without losing face.

6. Give adoption an owner, and get help

Everybody already has a full-time job. Nobody has spare hours to be "the AI person" on the side, so the rollout is expected to happen by itself, and it doesn't. Adoption is real work. It needs a named owner with real time allocated, and often it needs outside help - and there is no shame in that.

Watch what the market is doing. The role everyone is suddenly hiring for is the forward-deployed engineer - the FDE, a term popularized at Palantir and now used across AI labs and vendors, for an engineer who embeds directly with a team to make the technology actually land. AI is the most accessible technology any of us has ever touched, and companies are still paying to put an expert inside the building to drive the change. If the tool were the hard part, that job would not exist.

7. Don't get dazzled by every new tool

Every day, something new ships, and it feels like you are already behind. You are not. That feeling is manufactured; the noise is a business model.

Good things take time to mature. The compounding advantage goes to the organization that uses what it has well, not the one that rips out its stack every quarter to chase the launch of the week. Chasing every trend feels like progress and produces nothing. Pick your tools, get good at them, and say this out loud to your team - because they feel the FOMO harder than you do, and they need to hear that standing still on purpose is allowed.

8. Don't reinvent the wheel

The SaaS you already pay for increasingly ships AI by default. Before you spend a sprint and a pile of tokens rebuilding a feature in-house, check whether the tools already on your invoice do it out of the box. Usually something does.

Building it yourself is fun. That is the trap. The most important sentence in this whole piece might be this one: just because you can build something does not mean you should. Try what exists first. Reach for the custom build only when the default genuinely cannot do the job.

9. LLMs are not the whole toolbox

The last three years were staggering, and they quietly wrecked how companies think about AI. "AI" now means "a chatbot," and that is a cage.

Plenty of the highest-value things you can do are not generative at all - forecasting, classification, optimization, the plain machine learning that has been earning its keep for a decade. Those get skipped because they do not demo well, not because they do not work. Do not walk past the boring, proven win to sprint at the sexy one.

10. Do the groundwork before you deploy

Most failures happen before a single prompt is written. Teams jump into the deep water and drop technology into the org without the unglamorous work first: what is the business value, is the tech actually mature enough, what are the risks, and how do you roll it out without people quietly refusing to use it.

That last one kills more deployments than any technical problem. Resistance is not a bug in your people; it is a signal you skipped the change-management work. Do the staff work up front? It is the least exciting part of the job and the part that decides whether any of the other nine matter.


Disclosure: VarOps is published by me, and it sells AI transformation and embedding - the exact organizational staff work this piece says you need. That is a direct interest in the argument, which is precisely why the argument is for the discipline itself, not for renting it from us. Do the work in-house if you can. Most of it you can.

Ten moves, and notice what is missing from all of them: the model. The tool was never going to save your organization. Your organization has to do the work the tool finally made possible - and that work looks a lot like the boring engineering discipline it always did.

Your move.

Add VarOps on Google