How to Become Unnecessary (and Not Go Crazy in the Process)

There's a moment every founder hits where the job fundamentally changes.

You've been the one doing the work. Building the product. Running the sales calls. Making the decisions. And then one day you realize that if you keep being that person, the company can't grow. You have to stop being the person who does the thing and become the person who builds the team that does the thing.

Everyone talks about this transition like it's a mindset shift. "Learn to delegate." "Empower your team." "Work on the business, not in it."

That advice is fine. It's also useless.

Because knowing you need to let go and actually letting go are two completely different things. And most of the advice out there skips the messy, uncomfortable middle part where you're trying to hand off work to people who aren't as good at it as you are, while your brain is screaming that you could just do it yourself in half the time.

I inherited a product team once that had never worked in product before. Three people, none of whom had any product or tech background. For months, I was building every process, driving every meeting, making every call. That was the only way forward.

But at some point, I had to stop being the product person and start being the person who builds product people. And that transition looked a lot like teaching a kid to ride a bike.

You know those videos where a parent is holding the back of the seat, running alongside, and then at some point they let go without the kid noticing? It was like that.

I started by having a PM lead meetings while I was still in the room. I'd participate actively at first. Then less. Then barely at all. The goal was for them to prove it to themselves. Once they believed they could handle it, we were good.

But here's what nobody tells you: sitting in that room, watching someone fumble through something you could handle in thirty seconds, is physically uncomfortable. Every instinct says jump in. Fix it. Take over.

You have to fight that instinct. Because you learned by making mistakes. They need to learn the same way.

A lot of companies love to say "don't be afraid to fail." And that's true, to a point.

But you have to understand the stakes.

If the stakes are low, let them fail. That's how they learn. Pissing off a handful of users because you're testing a new onboarding flow? That's recoverable. Let them make the call, even if it's the wrong one.

But if the stakes are high, you step in. To provide guidance, to steer them back on the path. Bringing down Marriott's online reservation system? That's a different conversation. Some mistakes teach lessons. Others just leave craters.

I was in a meeting once where a PM I was coaching was getting grilled by an assertive stakeholder. Nothing wrong with the stakeholder; they just asked a lot of questions. And the PM was trying to answer everything on the fly, which is a natural instinct when you're being barraged. The problem was, they were making stuff up. Guessing. Answering with confidence they had no data to back up.

So I stepped in. I told the stakeholder we'd get back to them with the specifics. Gave the PM an exit ramp before they committed to something that had no basis in fact.

That's the balance. You're keeping them from crashing while they learn to stay upright.

Here's the part that's harder to admit.

Sometimes you're the one causing the crash.

I was coaching a new PM once. He'd never worked in product before, but he'd been at the company for years and had deep institutional knowledge about the product. We were in a meeting where stakeholders were grilling him, and I thought I was totally on top of the situation. I was wrong. This was one of fifty things I was juggling. For him, it was one of three or four. He knew the content better than I did.

But I stepped in anyway. Challenged something he said. Derailed him in front of the room.

After the meeting, he told me straight: "I had it. That was exactly what we cleared with the customer." He was right. I was the one who knocked the train off the tracks.

When you're holding on to too many things, you have to be an expert on too many things. And if you refuse to let go of the reins, you're the one putting the work at risk.

Readiness is two things: competence and confidence. Most people focus on competence. Can they do the job? Do they know the product? Do they understand the audience?

But confidence is the thing that actually unlocks the handoff. Someone can have all the skills and still be paralyzed by the fear of screwing up.

Early in my career, I came into the office one morning and found our QA person sitting alone in a conference room, crying. She'd come in early, before anyone else. She was upset because she'd missed a bug during testing, and it was going to delay our launch by a few days.

It was a real bug. But it was also completely recoverable. A few days, not a catastrophe.

I told her: "You didn't miss the bug. You found the bug."

She looked at me like I was crazy. But it was true. The bug didn't make it to production. She caught it. The system worked. She did her job.

After that conversation, something shifted. She stopped worrying about screwing up and started confidently doing her job. The fear wasn't gone, but it stopped running the show.

Founders face this moment constantly with early hires. The person who thinks a small mistake is catastrophic. How you respond determines whether they become someone who can operate without you.

The clearest signal that someone is ready? When they make a minor decision on their own, don't ask you first, and tell you about it afterward. And it's the right call.

That tells you two things. One: they have the instincts. They understand the product, the goals, the audience. Two: they have the confidence to trust their own judgment, knowing that if they're wrong, it's survivable.

When that happens, you know you can let go of the bike.

Here's the thing nobody wants to hear: they're never going to do it exactly the way you would.

And that has to be okay.

Think about a recipe that's been passed down through your family. Your grandmother made it one way. Your mom made it a little different. You make it different still. If your grandmother tasted your version today, she'd recognize it. She'd know it came from her. But you've made it your own.

That's how things grow.

You can't be every instrument in the orchestra. And sometimes the way someone else does it is simply better. I'm a lousy salesperson. In a founder environment, I have to be the salesperson, and I struggle in that role. But when I bring in someone who approaches it completely differently than I would, we sell more stuff. Because that person is actually good at sales.

The goal is to build a team that can do things you can't.

The hardest part of this transition is the identity piece.

You built this thing by being good at the work. Being the expert felt good. Being indispensable felt safe. And now you're supposed to step back and let other people, people who are less experienced and less skilled, do the thing you're known for?

Yeah. That's exactly what you're supposed to do.

Because your job now is to build experts. To hold the back of the bike until they don't need you, and then to let go without them noticing.

The company can't scale if you're still the one doing the work. And the people you're trying to develop can't grow if you won't get out of the way.

Let go of the bike.