Estimated reading time: 8 minutes
Key Takeaways
- Many founders feel they’re bottlenecks because they default to involvement and their teams default to escalation.
- This loop happens due to inherited scripts that worked in earlier stages but now constrain decision-making.
- Founders often misdiagnose the problem as needing better delegation or systems, missing the underlying scripts.
- Making the loop visible allows both parties to choose not to run it, unlocking better decision-making dynamics.
- To stop being the bottleneck, founders must examine and rewrite the scripts that no longer serve the current business model.
Why founders are the bottleneck
There’s a conversation that’s been going on in founder circles since September 2024.
Paul Graham wrote an essay called Founder Mode, drawing on a YC talk by Brian Chesky. The argument: the standard advice to hire good people and give them room to do their jobs is what makes founders fail. Stay involved. Stay in the detail. The alternative is professional fakers running your company into the ground.
The essay became a meme, then a movement, then a script.
Founder Mode named a real problem with the standard advice. Hire good people, get out of their way – it doesn’t always work, and pretending otherwise has cost founders real businesses.
But it gave you a new behaviour to perform, not a way to see what’s actually putting you in the loop. Stay involved. Don’t stay involved. Either way, you’re still answering the question at the level of behaviour, when the thing producing the behaviour is sitting one layer underneath.
I work with founders at the point where they’ve started to suspect that’s true. Where being more involved isn’t fixing it, being less involved isn’t fixing it, and the same pattern keeps reasserting itself no matter which prescription they try.
“I’m the bottleneck”
They say it before I do. It comes up in the first 20 minutes of almost every conversation.
“Everything routes through me.”
“I’m the bottleneck on hiring.”
“I tried to delegate it but I just ended up redoing it.”
“It’s faster if I just do it myself.”
The diagnosis is correct. The standard advice that follows it – delegate better, build systems, document decisions, hire a real number two – is mostly wrong. Not because those things don’t matter. They do. But because they treat the bottleneck as an operational problem when the bottleneck is something else.
The bottleneck is a loop.
The loop nobody names
Most leadership coaches blame the founder for not letting go. Some blame the team for not stepping up. Both miss what’s actually happening.
The founder defaults to involvement. The team defaults to escalation. Neither side chose this. Both sides are running scripts that were correct at an earlier stage of the business and have quietly become the constraint.
Here’s what I mean.
When the company was 15 people, the founder did need to be in every decision. There weren’t enough senior people to delegate to. Speed mattered more than process. The founder’s pattern-matching was the company’s biggest asset. The team learned, correctly, that the right move was to check in. Get the founder’s view. Loop them in before committing.
Now the company is 80 people. The founder still defaults to involvement, because that’s the script that built the business. The team still defaults to escalation, because that’s the script that worked when the business was being built.
And here’s the bit that makes it so hard to see: both sides experience the loop as the other side’s fault.
The founder thinks: “If I had a real exec team, I wouldn’t have to be in this meeting.” The exec team thinks: “If the founder would actually let us run this, we wouldn’t be in this meeting.” Both are correct. Both are missing that the loop is running them, not the other way around.
No blame. Just a system that worked once and has outlived the conditions it was built for.
The scripts on the founder’s side
A script is an inherited belief that produces behaviour without you having to think about it. The clue you’re running one is that it feels less like a choice and more like just how things are.
Some of the scripts I hear most often from founders:
“Faster to just do it myself.” True at 15 people. Still true for a small subset of decisions at 80. But the script has stopped distinguishing. It now applies itself to decisions that aren’t actually faster, just more familiar. The founder confuses speed-of-execution with speed-of-business-decision-making.
“I tried to delegate it but I just ended up redoing it.” The founder hands over a task but withholds the unspoken assumptions behind it. The team produces something that meets the brief and misses the intent. The founder redoes it. The lesson the founder takes: can’t delegate this. The lesson actually available: I delegated the task and kept the context. That’s not delegation. That’s setting someone up to fail and then confirming a prior belief.
“If I’m not in the room, the wrong decision gets made.” Sometimes accurate. Often a guess that’s never been tested. The founder has rarely run the experiment of not being in the room and seeing what happens. Even more rarely have they noticed when the decision made without them was actually fine.
“I need a real number two.” This is the structural fix that doesn’t land. The founder hires the COO, the new COO does good work, and within six months the same dynamic has reformed around them. Because the constraint wasn’t the absence of a senior person. It was the script that says decisions need to route through the founder.
The scripts on the team’s side
This is where the conversation usually stops. It shouldn’t.
The team is running scripts too. Most of them were trained into the team by the founder, intentionally or otherwise, during an earlier stage when those scripts were correct.
“Better check with [founder] first.” Right at 15 people. The founder did have context nobody else had. The team that adopted this approach was faster and made fewer mistakes. The team that didn’t was slower and got things wrong. So the script got reinforced.
“Let’s get [founder] in the room.” A risk-management move. If the founder is in the room, the decision can’t be wrong. Or at least, can’t be blamed on the person who made it.
“[Founder’s] already thought about this.” Often true. The founder thinks about most things. So the script becomes: assume the founder has a view, find out what it is, defer to it.
None of these are signs of a bad team. They’re signs of a team that’s adapted intelligently to the system it was given. The team that didn’t adapt this way got pushed out, fired, or quit. What’s left is the team that learned to escalate, and they’re now experiencing the cost of having learned that lesson too well.
What examining the loop changes
The intervention isn’t “let go” and it isn’t “delegate better.”
It’s making the loop visible to both sides.
The founder starts noticing the specific scripts running in specific decisions. Not all of them, in all places, all the time. The ones that show up most. “Faster to just do it myself” – is that true here, or is it the script firing? “I need to be in this meeting” – do I actually, or is presence-as-protection the assumption I never examined?
The team starts noticing where they’re escalating by default. The ask that gets sent to the founder when it doesn’t need to. The decision that gets held until the founder weighs in.
The shift doesn’t happen because anyone tries harder. It happens because the loop becomes visible enough that both sides can choose, in specific moments, not to run it.
That’s the work I do with founders and leadership teams. Not letting go. Not better systems. Examining the scripts that produced the loop in the first place, deciding which ones still serve the business as it is now, and rewriting the ones that don’t.
If you keep finding yourself in the middle of a decision you know shouldn’t need you, it’s worth asking which script is putting you there.
The bottleneck is almost always a loop, not a single point of failure. Founders default to involvement and teams default to escalation because both behaviours were correct at an earlier stage of the business. Neither side has consciously updated the operating script for the stage the business is in now.
Not by delegating more, building better systems, or hiring a number two on their own. The constraint isn’t structural – it’s the inherited scripts running on both sides of the loop. The work is making those scripts visible, deciding which ones still serve the business, and rewriting the ones that don’t.
A pattern where every meaningful decision routes through the founder, even after the business has grown beyond what one person can hold. It looks like a delegation problem. It’s actually a script problem – on the founder’s side and on the team’s side.
Founder Mode named a real problem with the prevailing “hire good people and get out of their way” advice. But it’s a behavioural prescription, not an examination of why founders keep ending up in the loop in the first place. The more useful question is which assumption is making you involved in this specific decision, and whether that assumption was ever consciously chosen.
