Growing Your Ops Team Is Usually a Failure

Every job is two things wearing one paycheck: labor and judgment. Labor is following a rule someone already worked out: when a lead comes in, log it; when the invoice clears, file it. Judgment is deciding what the rule should be, and what to do when reality doesn't fit it. Most roles are a mix, and for most of history that mix didn't matter, because the only way to buy labor was to hire a human who came with judgment attached. You needed work done, you hired a person, you got both. Fine.

Software broke the bundle. You can buy labor on its own now. A script runs at 3am and never fat-fingers a number, and nobody has to manage it. Judgment you still can't buy; you hire for it. So the old equation, need work done = hire someone, quietly went wrong somewhere in the last fifteen years, and almost nobody updated their instincts.

Hiring a person to be a runtime

The bill comes due as people. You write a job description for an "operations coordinator," and most of the bullets are labor: pull the report, update the CRM, chase the status, reconcile the sheet. A few are judgment: notice when a client's going quiet, decide which fire burns first. You hire one person for all of it. They spend 80% of the week being a runtime for rules a computer should run, and 20% on the thing you actually hired them for.

Then they get bored, because sharp people hate being a slow CPU, and they leave. You reopen the same JD and do it again.

When the work grows, you hire a second coordinator, then a third, and everyone calls it growth. "We're scaling the ops team." It's not growth. It's the same unbundling mistake in triplicate — three salaries buying the same thin slice of judgment, now buried under three times the labor.

A founder I know did exactly this, with someone I'll call Jan. Leads from the website into the CRM, then into Slack because the CRM pinged nobody, then into the billing sheet when they closed. Glue between four tools that wouldn't talk. Sharp person, wasted. The work didn't need Jan, or any particular human. It needed about a day of plumbing nobody got around to, because hiring felt like progress and building felt like a project.

Sort every line into deciding or doing

So before you post a role, run the split. Take the job description and put every line in one of two columns: deciding, or doing. Be honest. "Manage the pipeline" is usually doing in a manager's coat. The doing column isn't a job. It's a build list, and most lines on it are an afternoon of work, not a hire. What's left under deciding is the actual role. If that column is thin, you don't have a job to post. You have a system to build, and maybe nobody to hire at all.

When automation bites back

It cuts the other way too, and plenty of teams face-plant there. Not all labor is safe to hand a machine. Some rules have fuzzy edges. The input is messy, the exceptions are the whole point, and a script will confidently do the wrong thing forever while you wish you'd kept the human who'd have caught it. I've watched teams build automations that saved three hours a week and cost four to babysit. The move isn't "automate the doing column."

It's knowing which column each thing is actually in, because the expensive mistakes happen when you mistake labor for judgment, or judgment for labor.

Most teams will keep hearing "we're at capacity" as "we need to hire," because that reflex is older than software and it feels like winning. A growing headcount looks like a growing company. Sometimes it is. A lot of the time it's a company paying salaries to run code it never wrote, and calling the bill growth.