AI at Scale: The Bottleneck Isn't the Technology, It's Organizational Readiness

Thu, 30 Jul 2026 00:00:00 +0000

Every AI transformation deck starts the same way: a roadmap, a stack, a list of use cases. Model selection, data pipelines, agent orchestration, evaluation frameworks. All real work, all necessary. But it’s not where most transformations actually die.

The numbers are very consistent across every major research house. BCG’s 2025 study of over 1,250 companies found that only about 5% get real value from AI at scale, while 60% see no material value despite real spending (BCG, “The Widening AI Value Gap”). McKinsey’s November 2025 survey of nearly 2,000 organizations found that 88% use AI in at least one function, yet fewer than 40% report any EBIT impact at all, and only about 1% describe their deployment as mature (McKinsey State of AI 2025). RAND puts the outright failure rate of AI projects above 80%, roughly double that of ordinary IT projects. MIT’s NANDA initiative found that only about 5% of generative AI pilots ever produce measurable business impact.

These are not small-sample outliers. This is the normal outcome. And when you read the root-cause analyses behind them (RAND’s five failure modes, McKinsey’s 25-attribute study, BCG’s own diagnostics), the pattern is clear: the technology mostly works. What fails is the organization around it.

The technical part is real, but it’s not the bottleneck

I don’t want to wave away the technical layer, because it’s genuinely hard and I spend most of my working time in it: target architectures, agent orchestration, evaluation pipelines, deployment topology. Getting this right is a precondition. But it’s also the part every vendor, consultancy, and blog post already covers a lot, and it’s the part that’s most solvable. You can hire for it, buy it, or automate it.

What the research keeps showing instead is a second, harder layer. McKinsey found that workflow redesign (actually changing how work gets done, not just adding AI on top of an existing process) had the strongest link to financial impact. High performers were nearly three times more likely to have done it. BCG has gone further and estimated that in successful AI transformations, roughly 70% of the value comes from people-related action rather than technology-related action (BCG, “AI Transformation Is a Workforce Transformation”).

So the honest framing isn’t “technical vs. organizational.” The technical work is necessary but not enough. The organizational work is where the leverage, and the risk, actually sits.

Why AI adoption is a different kind of ask

Change management has always had to deal with resistance. What’s different about AI is the kind of risk it asks people to take on.

Amy Edmondson’s foundational work at Harvard defined psychological safety as the shared belief that it’s safe to take interpersonal risk in a team (to ask a naive question, admit a mistake, flag a problem, try something that might not work). Decades of research tie it to team learning and performance. AI adoption is, almost by definition, a learning challenge: it asks people to publicly experiment with unfamiliar tools, make visible mistakes in front of colleagues, and ask questions that expose gaps in their own expertise. Each of those is an interpersonal risk.

But it’s a specific kind of risk. Ordinary workplace learning risks social embarrassment. For a lot of people, AI adoption feels closer to a risk to their job. The tool they’re asked to try in public is also, possibly, the tool that could replace part of their work. That turns “try it and see” from a low-stakes ask into a high-stakes one, and it changes how people behave. A recent peer-reviewed study of 381 employees, tracked across three survey waves, found that organizational AI adoption measurably lowered psychological safety. That drop in safety, not the AI itself, predicted higher depressive symptoms in employees (Kim, Kim & Lee, 2025, Humanities and Social Sciences Communications). A separate large-scale study of 2,257 employees at a global consulting firm found that psychological safety reliably predicted whether people adopted AI tools in the first place, though it did not predict how often they used the tools once adopted. Safety seems to matter most for getting people through the door, not for turning them into power users (Safety First: Psychological Safety as the Key to AI Transformation).

MIT Technology Review’s own survey work found a related gap: four in five leaders agree that organizations with strong psychological safety are more successful at adopting AI, yet fewer than half of those same leaders rate their own organization’s psychological safety as high. In other words, most leaders already know this matters. They just haven’t built it.

There’s also a perception gap worth naming directly, because it explains a lot of failed rollouts. BCG found that 76% of executives believe their employees are excited about AI, while only 31% of employees actually report feeling that way. Leaders are often planning the change management for the wrong emotional starting point.

What this actually looks like on the ground

The abstract version (“psychological safety matters”) is easy to nod along to and easy to under-invest in. The concrete version is less comfortable. Where psychological safety around AI is low, teams don’t announce it. What happens instead is quieter: fewer questions in meetings, mistakes get smoothed over instead of raised, and adoption concentrates among the people who already had enough standing to fail safely. Everyone else waits it out, fakes competence they don’t have, or quietly opts out.

That last pattern is the dangerous one for a transformation program, because it stays invisible in most of the metrics leaders actually track. License counts and login rates can look healthy while real adoption stays shallow and limited to a small, already-secure slice of the organization. You end up with a rollout that looks good on a dashboard and fails on the value it was supposed to unlock, which is more or less the exact gap BCG and McKinsey describe at the macro level.

Why the standard change management playbook wasn’t built for this

Most enterprise change management still runs, directly or by inheritance, on Kotter’s 8-step model or variants like ADKAR: build urgency, form a coalition, cast a vision, communicate, remove obstacles, generate short-term wins, consolidate, anchor the change in culture. It’s a genuinely useful model, and it isn’t wrong. But it was designed in the mid-1990s for a specific shape of change: episodic, with a clear start and end, driven top-down from a leadership coalition that already knows what the destination looks like.

AI adoption doesn’t have that shape. It’s continuous rather than episodic. The tools, the capabilities, and the right workflow keep shifting, so there’s no stable end state to “refreeze” into (this is the exact step where Lewin’s underlying unfreeze-change-refreeze logic, which Kotter’s model builds on, starts to strain). It’s also less predictable from the top. A manager or an employee experimenting with a workflow often finds the real high-value use case before leadership does. A purely top-down coalition model misses that signal, which is a known blind spot in Kotter’s framework: the change that grows from the bottom up rather than cascading down.

This isn’t a niche critique. Several recent reviews of Kotter’s model point to the same limits in this exact context: it treats change as a one-off event rather than an ongoing condition, it doesn’t explain how to build real change readiness up front, and its top-down orientation limits the bottom-up input that matters a lot for a technology every employee can individually try. Leaders keep applying the discipline of incremental change (Gantt charts, milestones, a fixed finish line) to something that is, by nature, experimental. Then they punish the “failures” that experimentation produces, which teaches people to stop experimenting and start reporting false wins instead.

So what does change management need to become?

Not thrown out. Updated. The clearest summary I’ve seen recently comes from BCG’s seven behavioral-science principles for AI-era change, and it’s worth walking through because it lines up closely with the psychological safety problem above:

Get true agreement, not false alignment. Leadership teams that “agree” AI matters but haven’t settled what it’s actually for (cost, growth, or capability-building) send mixed signals down the org that employees correctly read as instability.
Increase agency, not just involvement. Middle managers, whose coordination work is often what AI compresses first, need real input into redesigning their own workflows, not a survey after the decision is already made.
Expect adoption to be earned, not automatic. Skill gaps, unclear permission to use the tools, and fear of losing professional identity are three separate, fixable barriers, not one vague “resistance to change.”
Measure emotion through feedback, not instinct. The gap between how excited leaders assume employees are and how employees actually feel is large and steady enough that instinct alone will mislead you.
Build rituals, not reactions. Regular, structured checkpoints (what did we learn, what should we stop, where do we need more capacity) replace the ad hoc, milestone-driven pace inherited from project-style change management.
Tell a destiny story, not just a fitness story. “Do the same work, faster” reads as criticism. “This lets you do work that was out of reach before” reads as opportunity, and it changes how people show up to experiment.
Sustain momentum throughout, not just at kickoff. Small, visible wins need to keep showing up well past the launch event, or the program quietly loses the room.

None of these seven principles are really about AI. They’re about what makes any change last when the change itself keeps moving. What’s specific to AI is the weight behind point 3 above (interpersonal risk that feels like a threat to your job) and the reason rituals beat milestones (the target keeps shifting, so a fixed roadmap goes stale within a quarter).

A sober take

I don’t think “change management must change” is a provocation for its own sake. It’s closer to a description of something already happening in the better transformations I’ve seen and read about, and something still missing in most of the rest. The organizations getting real value from AI aren’t the ones with the most sophisticated model stack (several of the top performers in BCG’s data run on off-the-shelf models and deliberately narrow use cases). They’re the ones that treated adoption as an ongoing psychological and organizational condition to actively manage, not a milestone on a Gantt chart to check off after a training session.

That has a practical, slightly uncomfortable implication for anyone leading this work, myself included: the parts of an AI transformation that are hardest to put on a slide (measuring how safe people actually feel to experiment, giving managers real agency over their own redesigned roles, running the plain biweekly ritual of “what did we learn, what should we stop”) are also the parts most tied to the numbers executives actually care about. The architecture diagram is necessary. It was never going to be enough on its own.

Psychological Safety on Zine-eddine's Blog