Buying AI Isn't a Strategy

There's a moment happening in boardrooms and budget reviews right now that most engineering leaders will recognize. AI is on every agenda. Executives who couldn't explain a language model to save their lives are asking pointed questions about adoption. And the fastest way to make that pressure go away is to point to a line item: the licenses are purchased, the tools are deployed, the box is checked. We use AI.

It's understandable. The pressure is real, and procurement is the easiest part of the transition to execute. But buying AI tools is not an AI strategy — and for many organizations, the gap between those two things is where significant money, time, and competitive advantage are quietly disappearing.

The Trap Most Organizations Are Already In

The tools get purchased. They get announced. A handful of developers start using them enthusiastically. And then — without any real infrastructure around adoption, measurement, or culture change — usage plateaus. The enthusiasts keep getting faster. The skeptics keep waiting for permission or proof. Leadership sees the spend on the books and assumes progress is happening somewhere.

This is the trap. And it isn't rare — at Lever10, it's one of the most common situations we encounter when we start working with a new client. The investment has been made. The results haven't materialized. And because no one established a measurement framework at the start, there's no clear picture of why.

Worse, in some cases the tools are actively creating problems. Developers who don't understand how to use AI output critically can introduce errors with greater confidence and speed than they ever could manually. Buying the tools without investing in how to use them well isn't neutral — it can move you backwards.

If You're Not Measuring, You're Guessing

Any meaningful technology transition can only be validated with metrics and data. This sounds obvious. It is almost universally ignored in the early stages of AI adoption.

Some organizations will build a measurement framework before they deploy. Most will attempt it later — after significant time and money have already been spent — which leaves leadership flying blind during exactly the period when course corrections are cheapest to make. By the time the data catches up, the organization has already committed to an approach that may not be working.

The framework doesn't have to be complex. It has to be intentional. What does productivity look like on your team today — in cycle times, in defect rates, in deployment frequency, in developer satisfaction? Establish those baselines before or immediately after you deploy AI tools, not six months later. Then monitor them consistently. The numbers will tell you where adoption is actually happening, where it isn't, and what the real effect on output quality is. Without them, every conversation about AI effectiveness is just opinion.

The Stakes Are Not Modest

It's worth being direct about what's at play here. AI will have as significant an impact on how software is built as the internet had on how business is conducted. That's not hype — it's the emerging consensus of people who have been watching this closely for years, and what we're seeing in the organizations already operating at full AI fluency confirms it.

The organizations that adopt and transition the fastest will build structural advantages that are very difficult to close later. They will ship faster, operate leaner, and attract the developers who want to work at the edge of what's possible. The laggards — the organizations that checked the procurement box and called it done — will find themselves competing at a permanent disadvantage, often without fully understanding why.

Time matters here in a way it doesn't with most technology transitions. The window for getting ahead of this is open. It will not stay open indefinitely.

What Actually Moves the Needle

Buying tools doesn't drive adoption. Buying training alone doesn't either. What works is building a culture and environment where learning and experimentation are genuinely supported — where developers feel safe trying things, measuring results, and adjusting without fear of judgment for the failures along the way.

That culture doesn't happen by announcement. It's built through consistent leadership behavior: asking about what developers are learning, celebrating experiments that didn't work as much as the ones that did, and making it clear that the goal is progress rather than performance.

The most practical advice we give to leaders at this stage is straightforward: don't do it alone. Find peers who are working through the same challenges and are willing to be honest about what they're encountering. Seek out experts who are ahead of you in this transition — not to copy their approach, but to learn from their experience before you make the same expensive mistakes. There are no extra points for figuring this out independently, and the cost of going it alone — in time, in missteps, in opportunity — is higher than most leaders expect.