I hired someone. Why is the problem still on my desk?

Because you delegated the task, not the problem underneath it. At 10–20 people, most of the functions a founder hates — sales, hiring, ops, finance — still don't have a stable playbook. A new hire can execute inside a system. On day one, in a vacuum, they usually can't invent that system themselves. Until someone has actually answered what good looks like and which calls are theirs to make, the job you thought you'd removed just relocates. Usually back to you.

The hire needed a system. You gave them a title.

"Own marketing" sounds like a task. At this size it usually means: figure out positioning, the customer, the channel, the message, the budget, the operating rhythm — company-building decisions, not marketing execution. A hire can help you find those answers. They can't manufacture them alone in their first quarter, because nobody has made them yet. Ask what "own it" is actually supposed to mean before you post the role, and you'll usually find the job description is describing a decision nobody in the company has made, dressed up as a hire.

You're the missing ingredient, not the missing hours

The salesperson needs your credibility on the calls that actually close. The recruiter needs you to sell the candidate on why this company, not just the role. The ops hire needs you to make the tradeoff nobody delegated to them. You hired expecting the function to leave your calendar. Its first real requirement is usually more of you, not less — someone has to hand over the judgment and context that made the function work when only you were doing it.

A hire removes labor, not accountability

Hiring a recruiter means someone else sources, screens, and builds process. It does not mean you've stopped needing to know what a good candidate looks like. Hiring a VP of Sales doesn't mean you've stopped needing to understand your own customer and revenue engine. What moved off your desk was the doing. What's supposed to survive the doing — your judgment about what good looks like, and the standard you hold the work to — is still yours, whether or not you enjoy it.

You can't judge what you never learned to see

There's a second cost to hating a function: you underinvest in learning how to run it. Then you can't tell "this hire is bad" from "our approach was bad," can't give feedback sharp enough to correct either one, and can't recognize genuinely good work when it shows up. The function you most want off your plate is usually the one you're worst equipped to manage — exactly backwards from what the hire actually needs from you.

Three Notion pages, not a system

At 500 people, a new Head of X inherits data, precedent, budget, and peers who've solved adjacent problems before. At 15 people, they inherit three Notion pages and whatever you happen to believe this quarter. You think you hired an operator. You actually hired a co-designer of the company, on day one, whether either of you named it that way.

The rule

You can hire away the task. If you haven't solved the problem underneath it, it reappears on your table — usually within two quarters, wearing a different name. One founder I worked with handed the exact thing he was avoiding to a friend within a week of naming the pattern himself. The compensation mechanism changed. What he was avoiding didn't.

So before the next hire: do the job yourself long enough to know what good looks like, write it down, and hire into that — staying accountable for the outcome while you hand over the doing. Ask one question before you post the role: what does this person need to be true within 90 days, and what's still yours if it isn't? An answer you can say in one sentence means you're ready to delegate the function. No answer means you've been delegating the symptom, and it's about to come back — this time with someone else's salary attached. If it's already come back twice, that's not a hiring problem to solve with another req. That's the pattern a Founder Bottleneck Diagnostic is built to find in one session.