Why 'Just Hire an OBM' Doesn't Fix a Broken Business
You Don't Need an OBM. You Need an Architecture.
This is the third time in two years you've posted this exact job description. Different platform, slightly better salary range, same bullet points. And somewhere in the back of your mind, a quiet little voice insists this one will be different.
It won't be. Not because you're bad at hiring. Because you keep solving an architecture problem by buying a person.
Why the Same Role Keeps "Not Working Out"
Ask most founders why their last OBM didn't work out and you'll get some version of the same two sentences.
"She just wasn't proactive enough."
"I think I needed someone more senior this time."
Both explanations put the failure inside the person. It's rarely the person. It's the role. A position with no documented scope, no defined authority, and nothing real to plug into isn't a job — it's a placeholder with a title, and every person you put there is set up to fail before their first Monday. She shows up ready to run operations. What she finds is a business where every real decision, gray area, and pricing exception still quietly routes back to you, because nobody ever built the structure that would let it route anywhere else.
Three hires, same outcome, and at some point that stops being a hiring problem and becomes data. It's also worth doing the actual math on it: three OBM hires, even at a modest salary, is real money spent confirming the same diagnosis three separate times — and the fourth hire, made under identical conditions, will cost you the same thing the first three did. Not the salary. The eighteen months of onboarding, trust-building, and slow disappointment that come standard with hiring into a gap nobody named out loud.
The Bandage Over the Foundation
"Just hire an OBM" is the operations equivalent of putting a bandage over a crack in a foundation. It works, briefly — the bleeding stops, the crack disappears from view, everyone exhales.
Then the next load-bearing stress hits — a busy season, a new client tier, a hire who leaves — and the crack reopens three feet to the left of where it was, because the bandage never touched the foundation. It just covered the part you could see. So you patch that spot too. And the one after that. Congratulations: you now have a very expensive collection of bandages and a foundation nobody has actually looked at.
Picture a contractor called out for a hairline crack in a basement wall, who shows up, skims a bit of filler over it, and leaves — without ever checking what's happening underneath the slab. The wall looks fine for a season. Then the ground shifts the way ground does, and the crack comes back six inches over, because the thing that caused it was never the visible line, it was the foundation settling underneath the whole structure. Patch enough of those and you've spent more on filler than the actual repair would have cost the first time.
The role isn't the crack. It's the fourth bandage.
What This Looks Like From the Inside
She takes the job with real enthusiasm. Genuinely sharp, organized, exactly the kind of hire you'd want running point on delivery.
Eighteen months in, she's still looped into every client exception, every pricing question, every "quick check" that was supposed to have stopped needing a founder's sign-off by now. Not because she can't handle it. Because nobody ever documented what she's authorized to decide, what she escalates with a recommendation attached, and what actually, specifically requires you. So she does what any rational person does inside a structure that gives her no other option: she brings you everything, every time — and you start interviewing for someone "more senior," when the person you already have is exactly who you need, just standing inside a structure that was never built to let her do the job.
This shows up earlier than most founders expect. At a team of four or five, it's easy to miss, because everything still moves fast enough that the routing feels like collaboration. At a team of eight or ten with an OBM already in the seat, it stops being subtle: she's copied on client emails "just in case," she pings you before every decision that isn't explicitly covered in a doc, and the org chart says you hired leadership while the day-to-day says you hired a very well-paid assistant.
SOPs Are Not the Same Thing as Permission
This is usually where "but we have SOPs" comes up, and it's worth being precise about why that doesn't settle it.
An SOP tells your team what the process is. It does not tell them they're allowed to run that process without checking with you first — and until that second thing exists somewhere, in writing, with real boundaries attached, the SOP is decoration. A document that describes the normal case in detail is still silent on the one question that actually determines whether your OBM can operate without you: where does her judgment start, and where is she required to stop and ask.
You can see the gap most clearly in refund or discount requests. The SOP says "escalate anything outside standard policy." Nobody ever defined what "outside standard" actually means in dollars, in circumstances, in precedent — so every request that isn't a carbon copy of the last one gets escalated, because "use your judgment" isn't a real instruction when judgment was never given a boundary to operate inside. That's not her being overly cautious. That's her correctly reading that the actual authority was never transferred, no matter what the document says.
What Actually Has to Exist Before the Hire
None of this means don't hire an OBM. It means the architecture comes first, or the hire just becomes the next person managing around gaps nobody named out loud.
That looks like: decision rights distributed clearly enough that she's making real calls, not routing them; escalation criteria specific enough that "gray area" has an actual edge instead of defaulting to you; and a documented standard detailed enough that she can hold your quality bar without you at every checkpoint. None of that is a personality trait you hire for. It's infrastructure you either have or don't before the offer letter goes out — which is also why the fourth candidate rarely performs any differently than the first three did, no matter how much sharper her resume looks on paper.
Build that once, and the hire you make — this one or the next one — walks into a role that was designed to be run, instead of one she has to reverse-engineer from your Slack replies over the following eighteen months.
A bandage doesn't set a broken bone, no matter how many new ones you apply. At some point the foundation has to actually get looked at — and that's a different project than another job posting.
If you want to know exactly where your business's architecture is missing before you spend another hire finding out the hard way, The Dependency Audit is built for precisely this question.