What the model looks like
Enforcer is characterised by process authority — RevOps owns the standards, cadences, and approvals that the functions must follow. Examples: RevOps owns deal desk approval for non-standard terms, owns territory and quota assignment, owns compensation plan structure, owns forecasting cadence and discipline.
The model gives the function substantial control over the operating system. Capabilities present: rapid process standardisation, centralised governance, consistent enforcement of standards.
When it's appropriate
Three contexts make Enforcer the right model. Post-merger integration — when two operating systems must be unified rapidly and the legacy functions resist. Turnaround situations — when previous operational discipline has degraded and needs to be restored. Strategic mandate — when a CRO has explicitly authorised RevOps to drive structural change that the functions will resist if left to negotiate.
In these contexts, the friction the model produces is acceptable because the alternative (continued functional drift) is worse.
Risks and limits
Using Enforcer as a default model creates predictable problems. Functional leaders resist process imposition that does not feel negotiated. The friction accumulates and eventually undermines the function's legitimacy. Compliance is achieved but commitment is not, producing standards-on-paper without standards-in-practice.
Enforcer is also rarely sustainable long-term. Even when it is the right initial posture, the function should plan to evolve toward Strategic Partner once the structural change is achieved. Deploying Enforcer as a permanent steady-state typically produces a high-control, low-trust function that struggles to drive system-level outcomes.