$5M ARR is a milestone worth celebrating. There's an enablement function. Reps are ramping. Content exists. Training happens on a cadence. That foundation is real — most companies at this stage don't even have it.

It's also exactly the moment where enablement gets to evolve into something bigger. The questions from leadership start getting more strategic. The GTM motion gets more complex. The opportunity in front of enablement shifts from supporting sales to designing how the entire revenue engine operates.

Here's what I've learned watching teams hit this moment: the unlock isn't about where enablement sits on the org chart. It's about what enablement is actually doing when it's there.

Let me say this plainly: the question of whether sales enablement reports to the CRO or VP of Sales is less important than the capability question not being asked. Structural authority — the kind where other functions actually defer to enablement on GTM process decisions — doesn't come from a reporting line. It comes from demonstrated capability.

90% of organizations recognize that cross-functional collaboration drives revenue. Only 37% execute on it. That gap isn't about org chart placement. That's about what enablement is built to do from the beginning.

The constraint is this: most enablement teams are still operating as trainers when their business needs architects. I wrote about why that director-level hire matters — and it's this exact capability gap that makes the difference. Most teams don't realize that's a choice they're making.

Here's the diagnostic that actually matters. Let's think about enablement work across two dimensions:

The first dimension is Proactive versus Reactive. Reactive work responds to problems as they surface — the fire drill, the urgent ask, the thing that landed on someone's desk this morning. Every team does it. But reactive work, by definition, means someone else is setting the agenda.

Proactive means the team looked at the data, saw where friction was building, and designed something before it became a crisis. It's the onboarding redesign that happened because ramp times were creeping up — not because a manager complained. It's the qualification framework that got aligned with marketing before pipeline reviews turned into finger-pointing. Proactive work is where enablement stops being a service desk and starts being a strategic function. It requires space, and it requires choosing to protect that space even when the urgent stuff is screaming.

The second dimension is what the work is actually about: Behavior Change versus System Design. Behavior change is training, coaching, skill development — the human capability angle. System design is process architecture, workflow optimization, cross-functional coordination. It's the structural backbone that makes behavior change stick.

Put these two axes together and four zones emerge:

The Firefighter Zone (reactive behavior) — emergency onboarding requests, last-minute campaign briefs, competitor response drills. Essential, chaotic, and it will consume every hour a team lets it.

The Trainer Zone (proactive behavior) — curriculum, certification programs, structured onboarding. What most enablement teams consider "the real work." Respectable and measurable, but largely invisible to revenue impact when the foundation beneath it is unstable.

The Fixer Zone (reactive system) — patching broken processes, creating CRM workarounds, manually syncing disconnected tools. Putting out fires that never should have started.

The Architect Zone (proactive system) — designing GTM workflows from first principles. Examining every process a rep touches and asking: How should this work? Where are the friction points? What feedback loops are missing? This is the work that makes everyone in the other three zones dramatically more effective.

Most organizations at $5M are operating 80% in the Firefighter and Trainer zones. Maybe 15% Fixer. Almost nobody in the Architect zone.

And it's not because people don't want to be there. It's because the Firefighter and Trainer zones are rewarded. Respond to an urgent training request, someone says thank you. Launch a certification program, leadership can point to it in a slide deck. Architect work — redesigning qualification frameworks, auditing data governance, building cross-functional workflows — takes months to show results and nobody's asking for it by name. The incentive structure actively pulls enablement away from the zone that matters most.

Revenue enablement requires flipping that ratio. The goal is 40% or more of the team's time in the Architect zone, designing the systems that make everything else possible. And here's the thing: structural authority follows time spent in the Architect zone. The more an enablement team demonstrates it can design systems that work, the more other functions trust it to lead.

At $3M ARR, organizations can outrun bad systems with exceptional people. The founder knows every rep. Coordination happens through informal relationships and quick huddles.

At $5M, those leverage points break. Fifteen reps instead of eight. Marketing doesn't talk to sales organically anymore. Most organizations throw headcount at the problem — another AE, another SDR — because the assumption is that the constraint is capacity. But the real constraint is process clarity and cross-functional architecture.

Enablement's scope is expanding whether we're ready or not — by 2026, 60% of enablement functions will be tasked with enabling all customer-facing roles. The function needs system designers who can see across the entire GTM motion, not just the sales floor.

System redesign unlocks what training alone can't. When an organization analyzes where deals are actually getting stuck — not where leadership thinks they're getting stuck — and redesigns the process around that data, the results compound. Gong published a case study showing exactly this at Andela: a 33% sales cycle reduction that came from analyzing call recordings, identifying friction points in discovery, redesigning the questions, and then retraining reps against that new architecture. Training enabled the change. System redesign drove it.

62% of sales leaders report different lead qualification definitions between sales and marketing. Two teams that depend on each other for revenue aren't using the same language about what counts as qualified. That's not a training problem. That's a system design problem. An architect would design a qualification framework that both teams build, test, and own together.

Here's a less obvious one: tool governance.
Most organizations at $5M have a conversation intelligence platform where anyone with access can create custom trackers, filters, and alerts.
Over time, the backend fills up with dead trackers nobody maintains, duplicate configurations from people who didn't know one already existed, and zombie automations consuming license capacity.
Nobody designed the governance layer because it wasn't urgent when there were three people using the tool.
At fifteen, it's technical debt that slows down every operational decision that depends on clean data. An architect would have built the access framework and naming conventions at tracker number five.

Nobody wants to acknowledge this: it's hard to do system design work and respond to every training request that comes in.
There's a choice to make. Most organizations keep choosing the training requests because they're urgent and loud and feel productive in the moment. That choice is why they plateau.
How to protect system design time without abandoning the team is a tension worth its own conversation — but recognizing it exists is the first step.

Here's something worth doing this week. Audit the team's time allocation using the Behavior/System Split. For one week, track what the enablement function actually does — not what anyone wishes it did.

Most teams land between 5% and 20%. Below 30% means the function isn't ready for the revenue enablement transition.

Then the harder exercise: name three GTM processes that enablement should be designing — or at minimum co-owning. Here are three worth starting with:

Now ask: Why doesn't the team own these? Is it capability? Is it time? Is it permission?

That answer tells us what the real constraint actually is.

Here's what I know about most teams at this stage: the people are capable. They care. What's often missing is structural authority — the organizational trust that lets enablement lead on GTM process decisions, not just support them.

Structural authority rarely gets negotiated into place. It gets built. Redesign one process the way it should work. Show the results. Design the next one with input from marketing and product. When leadership sees enablement is where GTM strategy becomes executable reality, the scope expands. Capability must precede structural change — if the team has been hearing "no" from leadership, this is often why. They're pitching training when leadership needs architecture.

Start there.

Know someone at this exact inflection point? Forward them this issue. They’ll thank you in 3 months.

So here's my question:

When we run the Behavior/System Split on our own teams — or on our own calendars for the teams of one — what quadrant eats most of the hours?

And more importantly, what's the one system design project we all know would change things if there was bandwidth to build it?

Hit reply and tell me. I read every one.

Until next time my friends… ❤️, Enablement

The Behavior/System Split:
The Behavior/System Split is a 2x2 diagnostic matrix developed by Ryan Parker in Love, Enablement that distinguishes enablement work by how proactive it is (reactive vs. proactive) and what it focuses on (behavior change vs. system design).

It consists of four quadrants: Firefighter Zone (reactive behavior), Trainer Zone (proactive behavior), Fixer Zone (reactive system), and Architect Zone (proactive system).
The framework solves the core problem that most organizations misdiagnose their enablement constraints—they assume placement issues when they're actually operating in the wrong quadrant of enablement work.

Key Data Points

Related Articles:

Common Questions

What if the organization isn't ready for system design work?
Start small. Pick one process that frustrates the GTM function and redesign it with cross-functional input. Document the before/after impact. This builds credibility and permission quietly, without requiring a structural reorganization first.

How to tell the difference between Architect zone and Fixer work?
Fixer work reacts to problems that exist. Architect work prevents entire categories of problems from forming. Redesigning qualification frameworks before they break, or building feedback loops before data quality issues emerge — that's architecting. Always responding to crises is fixing.

How does enablement gain structural authority?
Structural authority follows demonstrated capability. Build in the Architect zone first — redesign one process, show the results, then design the next with cross-functional input. Leadership grants authority to functions that have already proven they can execute. Capability must precede structural change.