How do you delegate as a founder for the first time?

Delegation fails when founders hand off tasks before they've defined what good output looks like. The fix isn't learning to let go—it's learning to specify clearly, check early, and build trust incrementally. Start with one task, one person, and one feedback loop before you try to systematize anything.

Why founders struggle to delegate (and it's not what you think)

Most founders believe they struggle to delegate because they're control freaks or perfectionists. The real problem is usually that they've never articulated their own standards clearly enough to hand them to someone else. You know what good looks like when you see it, but you haven't translated that into something a new hire or contractor can act on without reading your mind.

There's also a timing trap. Early-stage companies are fragile in ways that aren't obvious from the outside. Paul Graham's observation about early startups is that almost everyone—investors, reporters, even founders themselves—misjudges them by the standards of established companies. The same distortion applies internally: you can't delegate by handing someone a process built for a 50-person company. The handoff has to match the actual state of the business, not the business you're trying to become.

The practical implication: before you delegate anything, write down the three things that would make the output genuinely good, the one thing that would make it a failure, and the decision the person should escalate to you rather than make alone. If you can't write those down in under five minutes, you're not ready to delegate that task yet.

What to delegate first (and what to protect)

The best first delegations are tasks where the cost of a mistake is recoverable and the feedback loop is short. Think: scheduling, research synthesis, first-draft copy, data pulls, customer support replies under a defined template. These are high-frequency, low-stakes tasks where you'll get fast signal on whether the person understands your standards—and where a miss doesn't set the company back.

What you should not delegate yet: anything that directly shapes how customers experience your product. Paul Graham's point about doing things that don't scale isn't just tactical advice—it's a diagnostic tool. If you're handing off direct user contact because it feels inefficient, you're optimizing the wrong variable. The unscalable personal attention you give early users is how you learn what actually matters to them. That learning can't be outsourced until you've extracted it into explicit standards.

Protect any decision that's hard to reverse and anything that defines the product's core character. Delegate execution on tasks where the spec is clear, the timeline is short, and you can review the output before it ships or sends.

How to hand off a task without micromanaging

The structure that works is: state the goal, not the method. Tell the person what done looks like, why it matters, and what constraints exist (deadline, tone, budget, audience). Then step back. The moment you start describing every step of how to do it, you've switched from delegating to narrating—and the person learns to wait for instructions rather than think.

Garry Tan's engineering principle of stating your approach before executing on complex operations translates directly to founder delegation: before handing off anything non-trivial, briefly align on the approach together. This surfaces misunderstandings when they're cheap to fix, not after hours of work in the wrong direction. A five-minute sync before a ten-hour task is almost always worth it.

Set a specific check-in point—not 'let me know if you have questions,' but 'show me where you are by Thursday at noon.' This gives the person room to work independently while giving you an early correction point. The goal is one feedback loop before the final deliverable, not zero oversight and not constant oversight.

Building trust fast without abdicating judgment

Trust in a delegation relationship is built through small, completed loops—not through grand declarations of confidence. Give someone a task, review the output honestly, give specific feedback, and repeat. After three or four successful cycles, you'll have real evidence about their judgment, not just hope.

Be direct about quality. If the output isn't good enough, say exactly why—not 'this needs work' but 'the summary buries the key finding in paragraph three; it should lead with the number.' Vague feedback creates vague future outputs. Specific feedback teaches people your actual standards faster than any onboarding document.

The failure mode to avoid: delegating a task, getting a mediocre result, saying nothing to avoid a difficult conversation, and then quietly taking the task back. This is the delegation death spiral. The person learns nothing, you learn nothing, and you've now confirmed to yourself that delegation doesn't work—when the actual problem was the feedback you didn't give.

When you know delegation is working

Delegation is working when someone brings you a finished thing that meets your standards without you having touched it mid-flight. It's not working when you find yourself rewriting their work, making their decisions for them, or dreading the review because you already know it won't be right.

The metric that matters at early stage isn't how much you've delegated—it's whether the people you've delegated to are making decisions you would have made. If their judgment is consistently off, the problem is either the hire, the clarity of your standards, or both. Fix the root cause rather than adding more process.

As you delegate more, document the decisions you keep making the same way. Those patterns become the standards you can teach. Over time, the goal isn't to remove yourself from judgment calls—it's to multiply your judgment by teaching it to others explicitly, rather than hoping they absorb it by proximity.

“Almost all startups are fragile initially. They're like someone looking at a newborn baby and concluding there's no way this could accomplish anything.”

— Paul Graham, source

The one thing to do

Before delegating any task, write down what good output looks like, what failure looks like, and what decision requires your sign-off—if you can't do that in five minutes, you're not ready to hand it off.

Frequently asked questions

Should I delegate to my first hire or a contractor first?

Start with a contractor for a bounded, well-defined task. It reduces the stakes of a mismatch and gives you a low-risk environment to practice specifying and reviewing work before you're doing it with a full-time employee whose onboarding experience you're also shaping.

How do I know if I'm delegating too much too soon?

You're delegating too much too soon if you're handing off work you don't yet understand well enough to review. If you can't tell whether the output is good or bad within ten minutes of looking at it, you need more firsthand experience with that task before it can leave your hands.

What if the person I delegate to keeps making the same mistakes?

Give feedback once with specifics, watch whether it changes the next output, and make a decision by the third repetition. Repeated identical mistakes after clear feedback are a hiring signal, not a coaching opportunity. Don't loop indefinitely.

Is there anything I should never delegate as an early-stage founder?

Direct user relationships in the very early stage, the final call on product direction, and anything that sets precedents you'll live with for years (pricing structure, key partnerships, early culture norms). These require your firsthand judgment until the company has enough institutional knowledge to distribute that judgment safely.

Sources

More playbook answers · Growth Prophet home