The First Ops Hire You Might Not Need

Every growing small company hits the same wall and reaches for the same ladder. The founder is drowning — support answers at midnight, onboarding chaos, invoices going out late, the same questions answered forty times — and somewhere around the third consecutive lost evening, the fix crystallizes: we need an ops person. A JD gets drafted. It lists everything currently on fire. And that JD, read honestly, is a confession: it describes not a role but a pile — part genuine judgment work, part pure repetition, stapled together and priced at $60–80k a year plus benefits, plus the management attention that every first ops hire consumes and no one budgets.

This isn't an argument against the hire. Sometimes the hire is exactly right. It's an argument about sequence — because headcount is the most expensive and least reversible way to buy order, and buying it first means paying a person, forever, to perform work a system should have absorbed — while the judgment work you actually needed a human for gets whatever attention is left over.

Sort the pile: judgment or repetition?

Take the drowning list — the honest one, the everything-on-fire draft of that JD — and put every item through the sorting question from the admin-time audit: does this require judgment and relationship, or is it retrieval and repetition? Be strict, because the pile hides its structure. "Handle support" sorts into: answering the same twelve questions (repetition), triaging what's urgent (repetition with rules), and de-escalating the furious edge case (judgment). "Run onboarding" sorts into: sending the sequence of documents and reminders (repetition), and noticing that this particular new client is confused and needs a call (judgment). Run the whole list and a pattern emerges that surprises founders every time: the majority of the drowning is repetition — which is precisely why it drowns you; repetition scales with volume and judgment mostly doesn't. The midnight feeling says "I need a person." The sorted list usually says "I need a system, and maybe eventually a person for a much smaller, much better job."

Why the order matters more than the choice

Suppose you hire first anyway. A capable person arrives and inherits the pile as-is — and capable people cope: they absorb the repetition manually, build private spreadsheets, become the human integration layer between your tools. Eighteen months later the repetition is now load-bearing on a salary, the processes live in one head (you've reinvented tribal knowledge at $70k a year), and when they resign, the pile returns to you — undocumented and bigger. Systematizing after a hire almost never happens, because the pain that funds systematization projects is gone; a person is quietly eating it.

Now run the other order. Spend one quarter systematizing the repetition column: the recurring answers become a knowledge base and an AI front line, the onboarding sequence becomes a workflow that runs itself, the reminders and the chasing become automation, the recurring reports become dashboards. The tooling for this — the whole thesis of the modern SMB stack — costs a few hundred dollars a month, not a few thousand a week. Then look at what's left. Sometimes what's left is genuinely a job: relationship-heavy, judgment-dense, worth a great hire — and that JD is now attractive, because it describes work a talented person wants, not a pile they'll be coping with. And sometimes what's left is four hours a week of judgment calls that you, or someone already on the team, can carry comfortably now that the repetition stopped arriving. That second outcome is the hire you didn't need — discovered for the price of a quarter's discipline instead of a year's salary.

The JD test

Here's the compact version of the whole framework, usable in one sitting. Write the ops JD you're tempted to post. Then strike through every line a system could do — every "respond to," "send," "track," "compile," "follow up on," "keep updated." What survives the strikethrough is the actual role. If the survivors fill a page — vendor negotiation, client escalation, process design, the judgment layer of a real operation — hire, confidently, and hand them systems instead of chaos on day one. If the survivors fit on a sticky note, you were about to pay a salary for software's job. The struck-through lines aren't nothing, of course — they're your systematization backlog, in priority order, pre-written by your own pain.

The honest counterweights

Three cases where the hire-first instinct is right, so this doesn't curdle into dogma. If the drowning is already costing revenue this month — churn from missed onboarding, deals lost to slow follow-up — a contractor or fractional ops person now buys the runway to systematize properly; triage beats sequence. If the repetition is genuinely weird — regulated, physical, or so entangled that systematizing it is a six-month project — a person may honestly be the cheaper system. And if you've simply hit founder capacity as the bottleneck on judgment work itself, no automation fixes that; only delegation does. The framework isn't "never hire." It's "know which job you're hiring for, and don't pay judgment prices for repetition."

The bottom line

"We need an ops person" is how a drowning founder pronounces "our repetition has outgrown our systems." Sometimes both are true. But the order of operations decides what the salary buys: systematize first and the eventual hire steps into a real role with systems under it; hire first and a good person becomes the system — expensive, opaque, and temporary. Sort the pile, run the JD test, spend the quarter, and then decide. The best first ops hire is one whose job description contains nothing a $200-a-month stack could have done — and the way you get that JD is by building the stack first.

— Tom