Enablement and Rep Productivity

Enablement asked me a question that sounds trivial and turned out not to be: how many reps are tracking to goal, and how long does it take a new hire to make a first sale. I opened Salesforce to pull it and found the org had no hire date. Not a wrong one, not one buried on a custom object. None. Across all 255 user fields there was no start date, no ramp field, nothing that told me when a rep began carrying quota. The closest proxy was the day the user record was created, which reads 2015 for a rep who joined last spring and got reactivated, and reads correct only for someone hired net-new and never touched since.

That is the whole chapter in one gap. You cannot raise a productivity number you cannot measure, and productivity is not a vibe. It is the ninth revenue breakpoint in Revenue Architecture, the wall a scaling company hits somewhere past velocity and cost, and the instinct at that wall is always to hire. The data says the opposite. Chapter 29 gave you the deployment method: think big, act small, move fast, roll out a model change in 10% sprints. This chapter is the engine that method feeds, the one that keeps output climbing after the rollout ends. It is where enablement stops being a content library and becomes an operations discipline.

Your team is three teams

The most useful thing Revenue Architecture does with productivity is refuse to treat the sales team as one population with an average. It splits into three cohorts, and the split holds across almost every team I have measured.

The Normal cohort, about 32% of reps, runs the proven process, and it produces roughly 1.53x what the rest do on the same opportunity type and volume. That multiple is not a motivational number. It came out of a 2023 study of around 50,000 opportunities over six months, and it is the clearest evidence in the book that process adherence, not talent, is the lever. The Swing cohort, about 40%, is the largest group and the one with the most upside, because it is close enough to the process to adopt it with coaching. The Bottom cohort, about 28%, trails on both skill and discipline. Add the swing and bottom together and roughly 68% of the team is not executing the process that the top third has already proven works. That number should reframe how you think about the job. Enablement is not about the average rep. It is about which cohort a given intervention actually moves.

Four levers, and only four

There are exactly four ways to raise the output of a sales team, and every enablement program is some combination of them whether or not anyone names them. Naming them lets you tell a real lever from a busy one.

The metrics in the third column are not new. They are the volume, conversion, and time spine you instrumented in Module 2, read one rep at a time. Δt is the ramp. CR3 and CR4 are discovery-call conversion and win rate, the same CR3 × CR4 performance matrix you use to diagnose a pipeline, now used to diagnose a person. Right-sizing shows up in the cost-to-serve percentage from the go-to-market model. Enablement that cannot point at a column here is not raising productivity. It is producing content.

The fourth lever is the one leadership resists, so it is worth stating plainly. Revenue Architecture’s worked example takes a team from 509 reps down to 286 while production per rep rises to about $243K. Fewer people, more output per person, lower cost per dollar of ARR. That is the move a company reaches for last and should often reach for first, because hiring into a productivity gap does not close the gap. It buries it under a bigger denominator.

The ramp is a clock, and someone has to start it

Shortening the ramp is the first lever because it is the one with the shortest feedback loop, and it is where the hire-date gap bites. When I finally built the ramping analysis, speed-to-first-sale for new hires came in around a median of 86 days, with a mean badly inflated by a handful of tenured reps whose “hire date” was really an account-record artifact from years earlier. Strip those out and the mean collapses back onto the median, which is the tell that the data problem, not the reps, was creating the scary number. Twelve reps had made no net-new sale at all. Those are not twelve coaching cases. Some are ramp-clock problems, some are territory problems, and you cannot tell which until the clock is real.

Two rules made the number trustworthy, and both are transferable. First, “ramping” has to be an observable state, not an opinion: we defined it as hired within the last 90 days on a rolling TODAY()-90 window, so the cohort self-updates instead of drifting. Second, per-rep productivity needs a real source of truth. Ours turned out to be the Quota__c object, populated per rep per quarter, which the org had been sitting on unused because an earlier project confused it with an empty field of the same name. The productivity data you need is often already there, mislabeled, one query away.

Coaching sprints move the middle

Once the ramp clock is honest and the cohorts are visible, on-task performance is the lever with the most room, and Revenue Architecture is specific about how to pull it. Not an offsite, not a new playbook binder. Short, focused coaching sprints, borrowed straight from the deployment method’s move-fast phase, run against one metric at a time.

This is where enablement and the operating cadence fuse. The GTM council reviews the Bowtie, spots the metric that is off, and the sprint is the mechanism that fixes it before the next review. Tie each sprint to one of the Moments That Matter from the deployment chapter, target a 10% lift on that moment’s conversion, and the arithmetic from Chapter 29 does the rest: roughly 10% across seven throughput points compounds toward doubling output. Productivity is not one big program. It is many small, measured moves against a team you have finally stopped treating as an average.

What this leaves for the org

Ramp, cohorts, four levers, sprints: that is the productivity engine. It raises the output of the reps you have, which is the highest-leverage thing an operator can do before the expensive thing, which is adding more of them. But an engine needs an owner. Who runs the sprints, who guards the ramp clock, who keeps the productivity data honest, and where does enablement sit relative to the reps it serves? Those are org questions, and answering them is the phase shift from a people-centric team, where output rides on who you hired, to a process-centric one, where output rides on the system. That shift, and the shape of the ops function that runs it, is the RevOps org design we take up next.