the secret to successful adoption

Across nearly every conversation we've had on The Adoption Curve about rolling out new tools, new processes, new programs, one pattern keeps surfacing.

When adoption works, frontline managers were involved early, intentionally, and with clear expectations.

When adoption fails, frontline managers were either looped in too late or treated as a passive audience expected to "reinforce later."

This is rarely a strategic choice. Most enablement and L&D teams are already juggling timelines, content development, stakeholder alignment, and launch pressure. Managers tend to get folded into the broad bucket of "learners," assumed to be allies by default, and then handed a deck the week before go-live with a cheerful note about cascading the message to their teams.

But the conversations tell a different story.

Frontline managers aren't just another audience. They are the validation layer, the reinforcement engine, and the social proof employees look to when deciding whether a change is real—or optional.

And when adoption stalls, it's almost always because this layer was never designed for in the first place.

 

managers are the reality layer of adoption

This isn't a philosophical statement. It's an operational one.

Employees experience change through their manager. Managers decide what gets airtime in team meetings. They decide whether learning time is protected or quietly deprioritized when a deadline looms. They model whether new behaviors are safe to try—or quietly discouraged. The tool may be the same. The training may be the same. The launch email may be the same. But the manager filter is what determines whether any of it actually translates into changed behavior on the ground.

And one of the biggest drivers of that filter is something most teams never explicitly align on—what success actually looks like:

That same misalignment exists between enablement teams and frontline managers, and it's even more consequential. Enablement defines success as launch-day completion rates. Managers define success as their team hitting their numbers this quarter. When those two definitions aren't reconciled before launch, the manager makes the rational choice every time. They protect short-term performance, deprioritize the change, and the rollout decays — not because anyone resisted, but because no one ever agreed on what "done" meant.

That's why adoption rarely fails uniformly. Two teams can receive the same training, the same tools, and the same messaging and end up with wildly different outcomes six months later. The difference isn't motivation. It's managerial reinforcement.

When a manager believes in the change, employees feel permission to struggle, experiment, and adapt through the awkward early period. When a manager is unsure, skeptical, or simply overwhelmed, employees sense that hesitation immediately—and hedge their behavior accordingly.

 

Why Managers Are So Often Left Out (and Why That Backfires)

One of the most common breakdowns across adoption stories is timing.

Enablement teams are often brought in late. Managers are brought in even later — sometimes as little as a few days before their teams are expected to start using the new tool.

Managers feel that same hesitation. They're being asked to put their credibility behind something they haven't pressure-tested, often with no clarity on whether they're being positioned as champions or being graded on team compliance. That ambiguity is enough to make most managers hedge.

When managers are introduced to a change at the same time as their teams—or after—they're forced into a reactive posture. They're expected to reinforce behaviors they haven't had time to understand, pressure-test, or internalize themselves. They haven't found the edge cases. They haven't worked through the "wait, how does this handle X?" questions that will come up in the first team meeting. They're flying blind, in front of an audience watching them closely for signal.

In those moments, managers default to protecting performance. They allow old workflows to persist "just for now." They avoid pushing too hard because they're genuinely unsure what success actually looks like. And without intending to, they signal to their teams that the change is optional.

This is how adoption quietly decays—not through open resistance, but through ambiguity.

And when that structure doesn't exist, the cost isn't theoretical:

It compounds across every part of the rollout — from how content gets created in the first place, to how long it takes to update when something changes, to how confident anyone in the chain feels about what they're rolling out.

That gap is where most adoption programs stall. Both sides are operating in good faith. Neither side is talking to the other. And the version of the rollout that actually gets institutionalized is whatever the managers improvised to keep their teams functional — not the version enablement designed. 

 

Managers Don't Need More Content — They Need Confidence

A manager who has to spend two hours preparing for every team meeting on the new tool is going to stop talking about the tool. A manager who has a five-minute prep ritual will keep going. The math is that simple, and most adoption programs ignore it entirely.

 

Managers are rarely afraid of learning. What they're afraid of is being exposed—answering questions they can't yet handle, or endorsing a change that might backfire operationally. The downside of vocally backing a change that fails is real and personal. The upside of vocally backing a change that succeeds is diffuse and shared across the org. Given that asymmetry, the rational manager move is to wait and see.

When managers lack confidence, they don't sabotage adoption outright. They simply avoid it. They stop mentioning the tool. They defer questions. They wait for "things to settle."

From the outside, this looks like disengagement. In reality, it's self-preservation.

The strongest adoption programs design explicitly for manager confidence, not just manager completion. They give managers private time with the tool before broad rollout — not as a training assignment, but as exploration. They surface the messy questions early, in low-stakes settings where managers can ask "wait, what happens if…" without losing face in front of their team. They give managers language for the moments they don't have answers, so a manager can say "great question, let me track that down and get back to you Friday" instead of getting caught flat-footed.

High-performing adoption programs don't treat managers as "just another learner group."

The teams that succeed create a manager runway before broad rollout. Not more content—better sequencing.

Managers get:

• Early visibility into what's changing and why
• Time to experience the workflow themselves
• Clear expectations about what matters most in the first 30–60 days

This shifts managers from compliance enforcers to guides—people who can normalize friction, answer first-order questions, and reinforce progress rather than perfection. The difference between a manager who walks into the rollout meeting as a guide and one who walks in as a hostage is almost entirely a function of what happened in the two weeks before launch.

In most teams, that structure is missing—and the breakdown starts earlier than people expect. The friction often shows up in the intake process itself, long before the manager ever enters the picture:

 

If the front-end intake is already taking weeks, the manager runway gets compressed to nothing by the time the rollout actually arrives. Managers end up onboarded the same week as their teams — sometimes the same day. The runway never existed because the upstream process consumed all the slack.

Fixing manager enablement starts further back than most people realize. It starts with making the intake fast enough that there's actually time left to give managers a real head start.

 

Reinforcement Lives in the Manager–Employee Loop

Adoption doesn't stick because people know what to do. It sticks because someone notices whether they do it.

In many cases, the real risk isn't lack of training—it's where the knowledge actually lives:

 

Managers are the natural owners of that loop. They see where workarounds emerge. They hear objections before they escalate. They know which parts of a change feel realistic—and which feel brittle. They have visibility into the lived reality of the rollout that no central enablement team can ever fully see from headquarters.

But only if they're invited into that role.

When managers aren't positioned as feedback partners, issues stay local and invisible. The manager learns where the friction is, develops their own workaround, teaches it to their team, and the workaround becomes the institutional version of the rollout — never documented, never surfaced, never fixed. Central teams assume adoption is progressing because training is complete, while managers quietly adapt the change to survive day-to-day realities.

That gap is where most adoption programs stall. Both sides are operating in good faith. Neither side is talking to the other. And the version of the rollout that actually gets institutionalized is whatever the managers improvised to keep their teams functional — not the version enablement designed.