Most early-stage founders, when they finally have budget for one more person, reach for a second engineer or a marketer. Both feel productive. One writes code, the other fills the pipeline. But three months later you're still the bottleneck for everything that isn't code or content — vendor contracts, onboarding docs, renewal reminders, the password to that analytics account no one remembers setting up.
The role that actually clears that bottleneck is the one nobody writes breathless LinkedIn posts about: the person who owns repeatability.
Forget the title. Call it operations, chief of staff, business ops — whatever fits your recruiting budget. The job description is simple: turn things the founder does once into things anyone can do forever.
That means documentation. Vendor management. Process handoff. The unsexy work of writing down how the demo environment gets reset, which card is on which subscription, and what happens when a customer files a support ticket at 11 PM.
At five people, nobody has time to build process. At fifteen, nobody can function without it. The gap between those two numbers is where founders either build a machine or build a mess.
Here's the math that matters. If you spend six hours a week on tasks someone else could handle — reconciling invoices, chasing a vendor for an updated contract, re-explaining how the staging environment works to a new contractor — that's six hours not spent on product decisions, customer conversations, or hiring.
Six hours a week is roughly 300 hours a year. Nearly eight full working weeks. Hiring an ops person at a reasonable salary to reclaim those weeks isn't an expense. It's a capacity trade with asymmetric upside, because a founder's time compounds in ways an ops task does not.
The question isn't "can we afford this hire?" It's "can we afford for the founder to keep doing this work?"
This is where most teams go wrong. They hire someone with "ops" in the title and dump every unowned task onto them — IT support, office snacks, event logistics, customer escalations, and somehow also financial modeling. The role collapses under its own breadth within six months.
Three boundaries that keep the job viable:
Define the domain. Pick two or three areas where the founder is currently the single point of failure. Vendor relationships, internal documentation, and customer onboarding logistics are a common starting trio. Everything outside those areas stays off the plate until the person has built real systems in the core areas.
Measure throughput, not activity. The metric isn't "number of tasks completed." It's "number of processes that now run without founder involvement." If after 90 days the ops hire has turned five founder-dependent workflows into self-serve processes, they've already paid for themselves.
Give them authority to say no. An ops person without the standing to push back on ad hoc requests becomes an assistant, not a systems builder. Make it explicit: their job is to build repeatable process, not to be available for everything no one else wants to do.
A well-scoped ops hire, three months in, produces a few visible changes:
None of this is dramatic. That's the point. Ops work compounds quietly. The absence of chaos is hard to measure, but founders who've experienced it never want to go back.
When founders think about hiring, they default to "what function am I missing?" That framing leads to headcount-driven decisions — fill the role, check the box. The better question: "what is limiting how much work our current team can finish?"
Often the limiting factor isn't talent or hours. It's the absence of written process, the overhead of context-switching, the friction of nobody owning the connective tissue between functions. An ops hire attacks the constraint directly.
You're not adding a person to do more work. You're adding a person to make the work everyone already does actually stick.
If you recognize three or more of these, you're already late:
Later never comes. Hire the person who makes later into now.
Be the first to comment.
0 comments
Loading comments...