Most AI transformation programs begin with the wrong assumption.

They assume that once employees have access to AI tools, the organization will naturally discover how to use them effectively. The leaders purchase licenses, launch training programs, and establish adoption targets. When the expected gains fail to materialize, the same leaders conclude that the technology was oversold or that the workforce was resistant to change.

In reality, neither explanation is correct.

The problem is that AI adoption is not primarily a technology challenge. It is a mindset challenge. Leaders cannot mandate the mindset required to use it differently; they can shape the conditions that make that mindset shift far more likely.

I have watched this happen at several organizations, and in the AI transformations we lead at Asperitas, the diagnosis is always the same. The leader tried to order a transformation that cannot be ordered. Leaders can mandate access to AI, but they cannot mandate the shift in how people think about working with it. The shift is behavioral and has to be internalized, one person at a time.

So if you cannot mandate the mindset, the obvious question is: what can a leader actually do? Quite a lot, it turns out, just not the thing they instinctively try first. The answer starts with changing the conditions around the work.

Making a Steel Copy of a Wooden Bridge

The most common AI adoption failure is not a technology failure. It is a failure to change anything except the technology. The pattern repeats with unnerving consistency. An organization enables a coding assistant for a subset of developers. No training is provided. No one asks whether the surrounding process, how work is scoped, written, reviewed, tested, and shipped, needs to change to capture the benefit. The developers bolt a new tool onto an unchanged workflow, and the promised gains never materialize.

At Asperitas, we call this “Making a Steel Copy of a Wooden Bridge.” You have adopted a stronger material, but you have reproduced the old design exactly, every plank, every joint, every limitation, and then you are surprised the bridge is no better. Applying new technology to old processes while expecting to realize its benefits is the central mistake, and it is almost always compounded by a second. None of these organizations established or tracked KPIs. So even where AI did help, leadership had no evidence to point to, no story to tell, and no basis to expand. The initiative died of anecdote.

The Paradox Hiding in the Mandate

Leaders cannot mandate the mindset shift, but they can engineer the conditions that make it nearly inevitable. The mistake is not that leaders try to drive the change. It is that they try to drive the wrong variable. You cannot issue an edict that changes how a skeptical senior engineer thinks. But you control the process they work within, the people they learn from, the metrics they are measured by, the incentives in their performance review, and the story the organization tells about where this is all going.

Set those conditions correctly, and the mindset shift stops being something you demand. It becomes the natural result of the environment you have built. Everything that follows is condition-setting. None of it is an order to think differently. First, the environment has to be consistent. Leaders set the environment, choose the measures, and reinforce the behaviors they want to see.

First, Make the Environment Consistent

AI applied to an inconsistent environment does not fix the inconsistency. It amplifies it. Before you can apply AI effectively, the environment has to be consistent enough for “effectively” to mean something. In a recent engagement, we began with a current-state assessment and found what most organizations already know: every team did things a little differently. Different criteria for green-lighting projects; different requirements and design documents; different coding and code management practices; different testing tools and procedures; different production operations.

If every team's bridge is a different shape, you cannot design one steel replacement. So before and during the first AI experiment, we worked with the client to make those practices consistent across the organization: project green-lighting, requirements and design, coding and code management, testing, and production operations. It is unglamorous work, and it is tempting to skip it in the rush to deploy a shiny tool. Leaders should standardize first, then introduce AI into the standard. The consistency work and the initial proof of concept can run concurrently, but consistency is the foundation on which the rest of the work stands.

Seed the Tipping Point: A Two-Archetype Team

Adoption tips from a small, deliberately composed nucleus, never from a company-wide kickoff email. Technology adoption behaves a little like the diffusion-of-innovations curve Everett Rogers described: it spreads from a small, well-chosen group of early adopters to the majority rather than arriving everywhere at once. The composition of the group is what most organizations get wrong.

A productive POC team needs two distinct kinds of people. The first is the forward-thinking technologists, the people who are good at thinking outside the box and figuring out what is newly possible. The second, and the one organizations routinely forget, is the operationalizer, the people who are excellent at making technology survive contact with how work actually gets done. The technologist discovers the capability; the operationalizer turns it into something repeatable. Put them together, and they lay the foundation for the posture shift, producing something that is both new and durable.

Staff this first team with your leading performers. There is a real objection here: your best people get results precisely because they are exceptional, so their numbers may not generalize to the rest of the team. That objection is correct, and the structure below is how you answer it. The answer is to split the work into two POCs.

Two POCs, Two Different Jobs

The first POC exists to invent a new process. The second exists to prove a normal team can run it. Run the proof of concept in two phases because they perform entirely different jobs. The first phase is invention. Your best people, paired across the two archetypes, figure out how to apply AI to your now-consistent environment, both technically and procedurally. You want your strongest thinkers here precisely because a mid-tier team would reproduce the existing process with a new tool, a steel copy of the wooden bridge.

The second phase is validation. Now you take the process the first team invented and hand it to a broader, more representative group, on the engagement I am describing, one team per business unit. This phase answers the question that the first phase cannot: Does this work when ordinary teams run it, not just the rockstars? The gap between your phase-one and phase-two numbers is the single most honest signal you will get about whether you have a repeatable capability or a highlight reel. Phase two is also where you train the trainers, the people who will carry the change outward. Once you know the process can travel, you can measure what it changes.

Measure Transformation, Not Just a Faster Bridge

A steel copy of a wooden bridge scores beautifully on every efficiency metric, which is exactly why efficiency metrics are not enough. KPIs do three jobs in an AI rollout: they justify the investment, drive corrections between phases, and give leadership the evidence to tell the organization a credible story. Leaders should choose them in two tiers.

The first tier measures optimization, the same work done better: ROI (weighing labor savings against AI costs, delivery time, and downtime), Mean Time to Resolution, Productivity Gain (release velocity, issue-resolution time, security investigation time), Quality (defect reduction), and Risk and Compliance. These metrics matter, and on the engagement above, we saw a 35% increase in productivity and a 20% reduction in defects.

But notice that every one of those metrics rewards doing the old work faster. They cannot see the thing the whole transformation is about. For that, you need a second tier that measures transformation, work that did not exist before. New Capability Creation Rate, the number of genuinely new capabilities introduced, is the metric that proves the bridge was rebuilt rather than merely reinforced; make it your central number. We count something as a new capability only when a team can now deliver an outcome it simply could not before, not the same outcome faster, and we tally each one at the point it first ships to production. Process Elimination, how many processes you retired outright, is evidence of redesign, not just speed. Digital Labor Equivalent and the human-to-AI work ratio round out the picture, though, be honest, those two measure how much work shifted, not whether new value was created. An organization can automate low-value busywork and mistake the motion for transformation.

Expect the ROI J-Curve

Early AI use is inefficient, and the costs spiral before they fall. Plan for the dip, or it will end your initiative. One number on the engagement above was negative for a while: ROI. Early use of AI is inherently inefficient, and AI costs rose rapidly as teams experimented without discipline. If you lived through the early days of cloud computing, this will feel familiar: developers ran up runaway bills with a new paradigm they had not yet learned to manage.

The answer was the same as for cloud: education, monitoring, and deliberate cost management processes. In practice, that meant per-team token budgets, routing routine tasks to smaller models, reserving frontier models for work that justified them, and a weekly cost review until the discipline became second nature. With those in place, the curve turned. Six months in, our clients have seen ROI > 15% and are trending higher. Leaders need to set this expectation before they start, because the natural shape of AI ROI is a J-curve, down before up. An organization that promised immediate returns and panics at the early dip will kill a program that was about to pay off.

he Tip: Getting AI Out of the Lab

A successful POC that stays inside the POC team has failed. The point of the two phases was always to produce something that spreads. The transmission mechanism that has worked best for us is seeding phase-two participants into the broader organization as trainers. On the engagement above, the business-unit team that went through phase two now leads the rollout to the rest of that business unit's IT groups. They have already done it, they are trusted locally, and they train the trainer rather than parachuting in an outside expert.

Pair that with just-in-time training. Any formal training the POC identified as necessary, process, or technology, should be delivered to each new team right before they begin using AI, not months ahead. The closer the training sits to first use, the more of it survives.

Then there is communication, where the failure mode is the platitude. “Communicate consistently” means using an existing organization-wide channel to deliver regular updates, monthly or quarterly, on AI adoption and what is coming. The goal is to build anticipation, so the groups still waiting for their turn want in rather than dreading it. And the detail that determines whether any of these lands: who delivers the message. The higher up the organization the messenger sits, the fewer people tune out.

Finally, the incentives. You do not need a compensation overhaul, but you do need to ensure your existing incentives are not quietly working against the change. A developer still measured on raw output volume is penalized for spending an hour on upfront thinking that prevents three hours of rework. It is concrete and local: managers need to address the AI change directly in individual performance reviews and align those reviews with the new KPIs and processes. Working with HR to identify where different roles and levels should be incented differently is part of the leadership job, not an afterthought.

The Leader's Real Job

The leader's job was never to command the mindset shift. It was to build the conditions and then get out of the way. Every move in this playbook, standardizing the environment, composing the team, running the two phases, choosing transformation metrics, managing the cost curve, seeding the trainers, aligning the incentives, is something a leader genuinely controls. Not one of them is an order to think differently. That is the whole point. The mindset shift you cannot mandate becomes the emergent result of conditions you can.

So the answer to the question in the title is almost the inverse of the instinct. What can leaders actually do about the AI mindset shift? Everything except the one thing they reach for first: the edict. Build the bridge in steel, design it for what steel can do, and the people crossing it will soon enough figure out they are no longer on the wooden one.

Asperitas Consulting helps technology leaders do exactly this: standardize the environment, design the proof of concept, choose metrics that capture real transformation, and seed the change so it spreads on its own. If your AI initiative has stalled at “evaluation,” we can help you identify the reasons and create the conditions to move it forward. Reach out to Asperitas.consulting and start the conversation.

Scott Wheeler is a partner at Asperitas Consulting, where he leads AI transformation engagements for enterprise organizations. Connect with him on LinkedIn.

CONTACT US

Let us help you transition to effective AI adoption.

Message: I would like to discuss AI adoption strategies.

SEND MESSAGE