You Didn't Buy Change. You Built a Deliverable.

There is a moment every new CRO knows intimately. You are three weeks into the seat. The board wants signals. Your CEO wants conviction. Your team is watching to see whether you are the real thing or just another leader who talks process and disappears into meetings.

So you move. You audit the sales GTM motion, identify the gaps, and make the call that has probably been overdue for years: the sales process is broken, the stages are unclear, the handoffs are leaking, and nobody owns any of it.

This time, you do not call a consulting firm. You have been here before. You know how that ends. So you call people you trust. People who have run this play with you before. You loop in enablement to support the rollout. You build the thing the right way.

That confidence is not wrong. It is just aimed at the wrong problem.

Twelve months later, the CROs who made this move are landing in one of two very different places. A few are standing in front of their boards pointing to more accurate and predictable forecasts, faster deal cycles, larger deals, improved conversion rates, and a team that is firing on all cylinders.

The majority are explaining why the new process, which is technically live in the CRM, is not producing the results they promised. The stages are there. The fields are mapped. The dashboards exist. Enablement ran the training. And yet the reps are working around the system the same way they worked around the last one.

The real difference

It is not the quality of the process. Not the experience of the people who built it. Not whether enablement showed up.

It is whether anyone built the managers' ability to own it after the launch was over.

Here is the distinction that most revenue leaders never examine closely enough: executing a process and building other people's ability to sustain it are completely different skills. And the people who are best at one are rarely naturals at the other.

The operators you trust are trusted for a reason. They know how to scope the work, sequence the rollout, configure the systems, and hold the timeline. That track record is real, and it is why you called them. But knowing what good looks like is not the same as being able to develop it in someone else. Your trusted people were hired, implicitly, to execute. So they executed. And then the project ended, because that is what projects do.

Enablement ran their part too. Sessions were scheduled, content was built, completion was tracked. But here is what most enablement functions were never really designed to do: develop managers.

That is the gap nobody talks about clearly enough. Enablement is generally very good at training reps on a process; the stages, the CRM fields, the expected behaviors at each step. What it is far less equipped to do is build the manager's ability to coach to that process, inspect for it in the field, diagnose when it is breaking down, and hold their team accountable to it week after week without someone standing over their shoulder.

Those are not training problems. They are development problems. And they require a fundamentally different approach than a launch session or a playbook.

The manager is where process change lives or dies. Not in the CRM. Not in the methodology deck. In the one-on-ones, the deal reviews, the pipeline calls; the moments where a manager either reinforces the new motion or, through silence, shortcuts, or old habits, signals that it does not really matter.

If your managers cannot coach to the new process from first principles, the process does not exist. It is documentation. And documentation does not close deals.

Most CROs know this intellectually. What they underestimate is how much deliberate work it takes to build that coaching capability in a manager population that was hired, developed, and promoted under a completely different set of expectations. You cannot train your way there in a workshop. You cannot get there by giving managers a coaching guide and hoping they use it. It requires sustained development over time, with someone who understands both the process and the specific skills a manager needs to make it real in the field.

That is not what enablement was asked to do. In most organizations, it is not even what enablement knows how to do.

The uncomfortable question

After the last initiative, what changed about how your managers run a deal review? What is different about the questions they ask, the gaps they catch, the behaviors they reinforce?

If the answer is unclear, you have your diagnosis. The process was implemented. The managers were not developed. And without developed managers, adoption will always be slower than the system suggests, because the system measures inputs, not behavior.

This is not an indictment of your operators or your enablement team. They did what they were hired and built to do. The gap is in how the initiative was designed — specifically, whether manager development was treated as a distinct workstream with its own owners, methods, and timeline, or whether it was assumed to be a byproduct of a good rollout.

It almost never is.

The pressure you feel in those first ninety days is real. Bringing in people you trust is not the mistake. Involving enablement is not the mistake. The mistake is assuming that a well-executed process build, supported by solid training, will produce managers who can carry it forward.

Getting it built and getting it owned are two different jobs. The first one ends when the project does. The second one, the one that runs through your manager population, one coaching conversation at a time, is the only one that compounds.

If you are not asking who is responsible for that second job, you already know why you are having the conversation you are having twelve months later.