The ‘key person’ risk: hiring fractional RevOps without a system you can’t run

When people hesitate to hire a fractional RevOps lead, they usually point at the rate. What they should worry about is the space station.

Someone senior comes in, builds something intricate and clever, and hands you the keys on the way out. Now you own a system only they understood, and the dependency you were trying to avoid is worse than it was before they arrived.

The fear is fair, and it plays out often enough. It is also avoidable, as long as the person you hire is building to leave from day one.

Documentation isn't the last step - it's built with the system

There's an easy way to tell. Ask when the documentation gets written. If the answer is “at the end, as a handover,” walk away, because it won't be, or it'll get reconstructed from memory once the details have gone fuzzy. Good operators document as they build, since the doc is the design, and the note explaining a workflow is part of writing the workflow. Data governance that nobody wrote down is just one person's habit.

A real fractional lead builds to hand over, not to be needed

There's an incentive problem baked into this work: complexity creates dependency, and dependency extends the contract. The operators worth hiring push the other way, aiming for the plainest system that does the job and documenting it well enough that your internal team can run it without them. A system nobody but its builder can operate is a liability dressed up as an asset, a hostage situation with a Gantt chart.

The anatomy of a playbook your team can keep

When I hand back, what stays behind is an operating playbook rather than a diagram: what each object and field means and why, who owns what, the weekly hygiene checks that keep the data clean, and the “if this breaks, do this” runbook for the few things most likely to break. It's modular, so your team can change one part without having to understand all of it. That's the RevOps model we run, built to be handed back.

Handover is a design constraint, not an event

“Can they run it without me?” is a constraint you design under the whole way through, not a box you tick once the engagement is ending. Working under it changes what you build, pushing you toward something plainer and better documented. Most of the gap between senior help and senior risk comes down to whether anyone bothered.

Hire the architect who's already planning their exit. Planning to leave well is what commitment looks like in this work, and the best version of it leaves you with a system that runs fine once they're gone.