They Hired an Operations Manager to Fix a Missing System

This is a representative example illustrating the method below. It is a composite scenario, not a specific named client engagement.

The constraint

A growing consultancy had reached the point where the founder could no longer personally hold every operational thread. The obvious answer, borrowed from every "how to scale" post ever written, was to hire an operations manager. They wrote a job description that was mostly a list of aspirations, hired a strong candidate, and watched him fail over the following nine months.

He did not fail because he was the wrong person. He failed because there was no system for him to run. He inherited chaos with a title on it.

What was actually happening

The founder had confused two very different problems: "I do too much operational work" and "the business needs an operations manager." The first is a problem of undefined ownership. The second is a role that only makes sense once ownership can be transferred.

When the manager started, he was handed a job that was, in effect, "figure out what needs doing and do it." That is not a job. That is a rescue mission. Every decision he made was second-guessed, because there was no standard against which to judge it. Every process he tried to build got interrupted by a fire, because the fires were themselves undefined. Within six months he was doing the same reactive, unbounded work the founder had been doing, at a lower level of authority.

The decision

Stop hiring. Define the system first. Only then define the role that runs it.

This does not mean "wait until the company is bigger." It means: for each category of operational work you intend to transfer, decide what the workflow is, who owns each step, what the standard of done looks like, and how success is measured. Do that on paper. Then hire someone to run it. Never hire someone to invent it while running it.

What got built

Before rehiring, the founder ran a two-week clarification pass. She listed every recurring operational responsibility — client operations, internal cadence, finance rhythm, HR admin, tooling, reporting — and for each, made three decisions: what is the workflow, what is the standard of done, what does the weekly review look like. Where any of those three answers was "I don't know," the answer became: this is not ready to hand off.

Then, and only then, was the operations role rewritten. It became narrow, defined, and measurable — run these seven workflows to these standards, report on these five numbers weekly. The new hire onboarded in three weeks and was fully independent by month two. Same seniority level as the previous hire. Different job.

The ready-to-hire checklist

Before opening the requisition for an operations manager (or head of ops, or COO, or operating partner), all six of the following must be true. If any one of them is false, you are not ready — you are hiring chaos with a salary.

• The workflows this role will own are named. Not "operations." Specific workflows: client onboarding, weekly leadership cadence, monthly finance close, quarterly planning, incident response, tool administration, capacity planning. If you cannot list them, you do not know what you are hiring for.
• Each of those workflows has a documented standard. Not a full SOP for each — at minimum, a one-paragraph description of what "done well" looks like. Without a standard, the new hire cannot succeed or fail; they can only be judged on vibes.
• The decision-rights within each workflow are explicit. Which decisions does this role own? Which do they escalate? Above what threshold? See The Founder Bottleneck — the same decision-rights work applies.
• The success metrics are defined. Three to five numbers that will tell you, without asking anyone how it's going, whether the role is working. These are not vanity numbers; they are outputs of the workflows this role owns.
• The founder has agreed, in writing, to stop doing the transferred work. Not "help less." Stop. If you cannot commit to that, you are not hiring an operations manager, you are hiring an assistant who will be undermined weekly.
• The role has one boss. If the operations manager reports to the founder and dotted-lines to the head of delivery and coordinates with the head of sales, they have three bosses, which is zero.

What changed

The rewritten role was filled at the same salary band as the failed hire. Time-to-productivity dropped from an implicit six-plus months to a demonstrated eight weeks. The founder recovered roughly ten hours a week of reclaimed capacity — not because the new hire was better, but because the work had been defined before it was transferred. Turnover in the role, historically a concern, stopped being a concern; when the role is definable, so is success in it.

Is this you?

Symptoms: you have a job description that reads like a wish list. You have hired for an operations role once and it did not work. You describe the role using phrases like "someone who just gets it" or "a jack of all trades." Any two of those are true, and the fix is not a better candidate. The fix is a defined system to hire into. If you want a fuller treatment of what this role looks like when it is defined well, read the fractional COO guide — which is, in most cases, the cheapest way to build that definition before committing to a permanent hire.

Related reading

If your current problem is that the tribal knowledge required to run those workflows lives in a few people's heads, do that documentation work first: Tribal Knowledge Is Not a System.