ChatGPT
Perplexity
Claude
Grok
Crossing The Enterprise Adoption Chasm
Almost every organization has a graveyard of well-chosen tools. The software was evaluated carefully, demoed convincingly, and approved with genuine enthusiasm. A pilot group loved it. And then, somewhere on the way from "the pilot group loved it" to "everyone uses it," momentum quietly died. The tool didn't fail because it was bad. Instead, it failed because it never crossed the gap between the people who were eager to use it and the far larger group who were not. That gap has a name. Additionally, understanding it is one of the most useful things an L&D or change practitioner can do.
The Curve Nobody Warns You About
More than 50 years ago, the sociologist Everett Rogers described how new ideas and technologies spread through a population. Adoption, he observed, doesn't happen all at once. Instead, it moves through predictable groups: a small band of innovators, then early adopters, then the early and late majorities, and finally the laggards. Later, the technologist Geoffrey Moore added a crucial refinement for the business world. He noted that between the early adopters and the early majority sits a "chasm." This is a point where many promising technologies simply stall and never recover.
Most of us think about this curve in the context of products spreading through a market. But the same dynamic plays out inside a single organization every time a new system is rolled out. It's arguably more brutal internally, because there's no marketing budget to push through it. There's just a workforce being asked to change how it works. If you want to understand why a rollout stalls, mapping it onto the internal version of the enterprise technology adoption curve is the sharpest diagnostic there is.
Here's the pattern. Your innovators and early adopters—the naturally curious, the technically confident, the people who volunteered for the pilot—adopt quickly and enthusiastically. Their success creates a dangerous illusion. Leadership sees high usage in this group and concludes the rollout is working. But these people were always going to adopt. They are not representative of the organization. In fact, they're the easy 15%.
The real test comes next, when the tool has to reach the early and late majority—the people who didn't volunteer, who are busy, who have a workaround that already works, and who are, quite reasonably, skeptical that this new thing is worth the disruption. This is the internal chasm. Moreover, it is where most enterprise technology quietly goes to die.
Why The Majority Resists And Why They're Not Wrong
It's tempting to frame the majority's reluctance as stubbornness or "resistance to change," as if the problem were a character flaw to be overcome with a sternly worded email from leadership. That framing is both unfair and useless. The majority resists for reasons that are, from their point of view, entirely rational.
They have less tolerance for friction than the early adopters did. An innovator will happily wrestle with a clunky interface because the novelty is its own reward. But a busy manager in the majority will abandon the same tool the moment it costs them more time than their old method saved. As eLearning Industry's own analysis of the friction that blocks it makes clear, poor integration and unintuitive navigation aren't minor annoyances—they're decisive. The majority doesn't need to be sold on the vision. Instead, they need the new way to be demonstrably easier than the old one, at the exact moment they're doing the work.
They also carry a heavier switching cost. The majority has muscle memory in the old system, informal shortcuts, and a network of colleagues who do it the same way. Adopting the new tool means giving all of that up for a period of feeling slow and incompetent. This is a genuinely unpleasant experience that training decks rarely acknowledge.
And they've been burned before. Most employees have lived through rollouts that were announced with fanfare and then abandoned six months later. Their skepticism isn't irrational; it's pattern recognition. Why invest effort learning something that might not survive the year?
Where L&D Usually Goes Wrong At The Chasm
The default organizational response to a stalling rollout is to do more of what worked for the early adopters—more announcements, more training sessions, more mandates. This almost never works, because it misdiagnoses the problem. The early adopters didn't need much support; they succeeded largely on their own motivation. Additionally, applying that same light-touch model to the majority, then blaming them when it fails, is the central mistake.
A one-time training event is particularly ill-suited to the majority. The event happens, knowledge is transferred, and then the learner returns to their desk and hits the first unfamiliar situation the training didn't cover—with no support in sight. Confidence collapses, the old workaround beckons, and the tool loses another user. The training wasn't wrong; it was simply aimed at the wrong moment. The majority doesn't need to be taught the tool in a room. They need help inside the tool, at the point of real work.
This is why the shift toward learning in the flow of work matters so much for crossing the internal chasm. Contextual, in-the-moment guidance meets the majority exactly where their confidence breaks—on the specific screen, at the specific step, in the specific instant they're stuck. It removes the friction that a classroom session, however well designed, can't reach.
A Playbook For The Chasm
If the majority resists for rational reasons, then crossing the chasm is a matter of removing those reasons rather than overpowering them. A few principles that consistently help:
- Stop reading early-adopter enthusiasm as proof
Build your measurement around the majority from the start. The question isn't "are people using it?"—the innovators always are. The question is "is usage spreading past the enthusiasts, and is it sustaining?" That's the only signal that tells you whether you're crossing the chasm or stuck at its edge. - Make the new way genuinely easier at the moment of work
The majority does a ruthless cost-benefit calculation every time they touch the tool. Win that calculation by putting help in the flow of the task, so the new method feels lighter than the old workaround rather than heavier. If the guidance lives in a separate manual or a training module they took weeks ago, you've already lost. - Treat this as change management, not just enablement
Adoption at scale is a human transition, not a knowledge transfer. That means acknowledging the switching cost openly, giving the majority permission to feel slow for a while, and providing the structured support of real change management rather than a memo and a deadline. People cross the chasm when the transition is made safe, not when it's mandated. - Recruit the majority's own peers
The majority doesn't trust the innovators—those people are different from them. They trust colleagues who look like them and share their skepticism. Identifying respected members of the early majority and equipping them as visible, credible guides does more to move the middle than any executive endorsement. - Build capability before you need it
As eLearning Industry argues, the first step in any digital transformation is upskilling the workforce, because change resistance is often just fear wearing a different mask—fear of being left behind or made redundant by the new system. Reducing that fear in advance makes the chasm narrower before you ever reach it.
The Chasm Is Where L&D Earns Its Seat
There's a reason adoption stalls land so often on L&D's desk, and it isn't bad luck. Crossing the internal chasm is fundamentally a learning-and-behavior challenge. It's about helping a skeptical, busy, previously-burned majority build the confidence and capability to change how they work. It is also about helping them keep working the new way when the initial push fades.
No amount of feature richness solves that. No mandate solves it either. What solves it is deliberate, well-designed support aimed squarely at the majority—support that meets them in the flow of their work, respects the rationality of their hesitation, and makes the new way the genuinely easier way.
Get that right, and the tool crosses the chasm. Get it wrong, and it joins the graveyard of good software nobody used—not because it couldn't do the job, but because the organization never helped its people cross the gap.
