I've had a version of the same conversation dozens of times in the last year. It goes like this.
An enablement leader smart, experienced, genuinely committed to the function explains why their last enablement programme didn't land. The reps didn't complete the training. The content library went unused. The role plays happened once and then stopped. And the conclusion they've landed on, after everything, is: we need a stronger mandate from leadership. If the CRO would just enforce this, it would work.
And I want to be honest about what I hear when I hear that.
I hear a decade of optimising for behaviour - and then, when behaviour doesn't change, concluding that the answer is more pressure on the behaviour.
That is not a learning. That is the loop.
What the CRO Actually Cares About
Here is the thing enablement leaders have always known but rarely said plainly: the CRO does not care whether rep behaviour changed.
The CRO does capacity planning. They care about one thing did the number move? Did ramp time shrink? Did win rate improve? Did the pipeline hold? Behaviour is not the metric. Behaviour is the hypothesis about how you get to the metric. And hypotheses can be wrong.
For a decade, the enabling hypothesis was: if we change how reps behave train them better, give them better content, run better role plays the numbers will follow. So enablement optimised for behaviour. Completion rates. Certification passes. Content opens. The assumption being that behaviour change was the path to revenue outcomes.
The CRO never shared that assumption. They just didn't say so - until budget season, when enablement got cut.
The CRO had a different model entirely. They knew behaviour change was slow, fragile, and dependent on rep motivation. So they had a backup plan. They tied things to comp.
If you don't update the CRM, you lose 10% of your commission. If you don't complete the certification you don't get on the President's Club trip. If you don't follow the sales process -we'll put you on a PIP.
And this worked. Compliance went up. Reps did the thing.
But here is what nobody named: that was failure-based design. The CRO wasn't asking reps to want to update the CRM. They were making not updating the CRM more painful than updating it. They were engineering around the failure mode - not trying to eliminate it through training and motivation.
The Mandate Was Always Failure-Based Design
Every time an enablement leader says 'we need a mandate' they are asking the CRO to do failure-based design on their behalf.
They are saying: our programme didn't change behaviour through intrinsic motivation, so please change behaviour through extrinsic pressure. Please make the wrong action painful enough that reps do the right thing instead.
And when the CRO agrees when they do enforce the mandate it works. Not because behaviour changed. Because the consequence architecture changed. The rep is still not intrinsically motivated to update the CRM. They just don't want to lose the commission.
This is an important distinction because it tells you exactly what enablement has been getting wrong.
Enablement has been trying to change the want. The CRO has been changing the consequence. They've been doing failure-based design at the process level - comp, quota, PIP while enablement tried to do behaviour-based design at the content level. And when enablement's approach didn't work, the fix was to borrow the CRO's approach mandate, enforcement, consequence.
Nobody asked the more interesting question: what if we did failure-based design at the system level instead of the process level?
System-Level Failure-Based Design
Here is what failure-based design looks like when you apply it to the technology rather than the comp plan.
The rep won't visit the content library. So instead of training them to visit it, mandating that they visit it, or tying visiting it to their comp - you remove the visit requirement. The content comes to them. In the CRM. In the calendar. In the email thread. At the moment they need it.
The rep won't watch the call recording. So instead of requiring them to watch it, building better recordings, or coaching managers to follow up - you extract the signal from the recording automatically. The coaching insight goes to the manager without the rep having to do anything.
The rep uses the old deck because it's on their desktop and they know where it is. So instead of asking them to always use the latest version, you make sharing the old version architecturally impossible. The wrong action becomes structurally unavailable.
This is failure-based design at the system level. And the crucial difference between this and the comp plan version is: it doesn't cost you rep morale. The rep doesn't feel punished. They just experience a system that makes the right action easier than the wrong one.
The outcome is the same - the number moves. But the mechanism is different. Not pressure. Infrastructure.
Why Enablement Didn't See It This Way
I think the honest answer is that enablement was sold a different story about what its job was.
The story was: your job is to change how people think and behave. Train them. Coach them. Create the conditions for behaviour change. Build a learning culture. Get manager buy-in.
And there is truth in all of that. Behaviour does matter. Managers do matter. Culture does matter.
But the invisible assumption underneath that story was that behaviour change was achievable at scale through intrinsic motivation - through great content, great training, great coaching - without structural enforcement.
That assumption was wrong. Not because enablement leaders were bad at their jobs. Because humans are not assembly lines. You cannot change 200 reps' habits through curriculum the way you can change one person's habit through personal accountability. The scale problem is real. The motivation problem is real. The forgetting curve is real.
Failure-based design doesn't deny any of this. It accepts it. It says: here is how humans actually behave under pressure, with limited time, managing seventeen concurrent deals. And then it builds from that reality, not from the ideal version.
The systems that hold are the ones that start where things will break - not where things should work.
What Changes When You Accept This
The practical implication is significant.
If enablement accepts that its job is not to change behaviour through motivation but to make right behaviour structurally easier than wrong behaviour the entire design brief changes.
You stop asking: how do we get reps to visit the content library? You start asking: how do we make the content library irrelevant by delivering the right content at the moment of need?
You stop asking: how do we get reps to do better call prep? You start asking: how do we make bad call prep structurally impossible by surfacing everything they need before they join?
You stop asking: how do we get managers to coach more consistently? You start asking: how do we deliver coaching signals to managers automatically so consistent coaching doesn't depend on manager discretion?
And you stop asking: how do we prove enablement's ROI? You start building attribution into the system architecture so the proof accumulates automatically not because someone built a better dashboard, but because the connection between enablement activity and revenue outcome is part of how the system works.
The CRO will care about that. Not because enablement finally learned to speak their language. But because the system speaks it for them.
Where AI Changes the Equation
This is where AI changes everything not because it makes reps more productive, but because it makes system-level failure-based design viable at scale for the first time.
Before AI, you could surface the right content at the right moment for one rep with careful configuration and a lot of manual maintenance. Now you can do it for two hundred simultaneously. You can extract coaching signals from every call automatically.
You can enforce content governance architecturally across an entire team without a compliance programme. The agentic sales rep is not a better-behaving rep. They are a rep whose failure modes have been engineered around by a system that owns the work around the conversation so the human can own the conversation itself.
That is not productivity. That is capacity. And it is the first version of enablement technology that the CRO was always going to care about.
The Mandate You Actually Need
There is still a mandate that matters. It is not 'reps must complete the training.' It is 'the system must be designed around where reps will fail, not where they should succeed.'
That is a mandate for vendors. For product teams. For the people building the tools enablement buys.
For ten years, enablement technology was built for how reps should behave. The content library assumed the rep would visit. The training module assumed the rep would complete it. The coaching framework assumed the manager would use it consistently. Every system was built for the ideal rep, not the real one.
Revenue Activation is built for the real one. Not because it has low expectations but because it has accurate ones.
The rep is busy. The rep is under pressure. The rep has seventeen deals and a pipeline review in an hour. They are not going to stop what they are doing and go find the right content. But they will use the content that appears in the tool they are already in, at the moment they need it.
Design for that rep. The number will move.
The CRO was always going to care about that more than they cared about whether behaviour changed.
Karthi Ratnam is CMO & Category Designer at GTM Buddy, where she is building the Revenue Activation category. She is also a DBA candidate researching the future of the enablement function in the agentic era.
.png)
.png)