Daniel sent us this one — he's been watching a pattern play out in high-performing people, the ones whose competence becomes the very thing that breaks their teams. They can't let go. They insert themselves into every decision, every process, every review. What their team experiences is delegation without authority — you're assigned the work but you know it'll be overridden, so you stop really committing. And Daniel's asking: what distinguishes the people who fall into this trap from the ones who build their success on being great at delegating? And if you recognize yourself in the first camp, can you actually change? What does that journey look like?
This is one of those questions where the person asking it has probably already done half the work just by noticing the pattern. Most people in this trap don't see it at all. They think they're being thorough, or they think their team just isn't ready, or they've convinced themselves that their personal touch is what makes the output excellent.
The brilliant leader who becomes the bottleneck. It's almost a genre at this point.
It's expensive. There was a piece in Harvard Business Review just this month — June twenty twenty-six — analyzing what they called "delegation debt" across scaling startups, and it came up as the single most cited friction point. Above funding constraints, above market timing, above talent shortages. The thing that was slowing companies down was the founder who couldn't stop being the person who did everything at the ten-person stage.
That's a good phrase. It accumulates like technical debt — every decision you pull upward instead of pushing outward adds interest that compounds.
The timing matters here. Organizations have gotten flatter, remote and hybrid work means you can't just walk over to someone's desk and course-correct in real time, so the cost of centralized decision-making has gone up. When every approval has to route through one person who's in six hours of Zoom calls a day, the latency kills you.
Daniel's question lands at a moment when this isn't just a personal development issue — it's becoming a structural competitive disadvantage for organizations that can't solve it.
What makes it tricky is we're not talking about incompetence. The people who fall into this trap are often the most competent people in the room. That's the paradox. Their track record is real. They have been right more often than wrong, and that history creates a kind of Bayesian prior where they genuinely believe their judgment is more reliable than the people around them.
It's not arrogance in the classic sense. It's a rational update on data that happens to be self-reinforcing and eventually self-defeating.
I want to distinguish this from micromanagement, which is the word people usually reach for. Micromanagement implies a desire to control the process — watching over shoulders, checking every detail. What Daniel's describing is subtler. It's delegation without authority. You hand off the task, you even say all the right things about empowerment, but then you override the output. You rewrite the spec. You change the decision after it's been made. And what that teaches the team is that their work is just a draft for your final pass.
Like giving someone a paintbrush and then grabbing their wrist mid-stroke.
After the third or fourth time that happens, the person stops painting with any conviction. They produce something half-finished because they know it's going to be redone anyway. Which then confirms the leader's belief that they need to intervene. It's a self-fulfilling prophecy.
You end up with learned helplessness dressed as a functional team.
The best people leave first because they have options and they're not interested in being human draft paper. What you're left with is a team of people who are comfortable being overridden, which is not the team you want.
Daniel framed this as a trope, and he's right — you can probably name five examples off the top of your head. But he also pointed out that it's not universal. There are high achievers who are good at this.
That's the encouraging part of the question. If this were just a personality trait — some people are delegators and some aren't — then the answer to "can I change" would be "probably not." But the evidence suggests it's more nuanced. There are specific mechanisms at work, specific patterns you can identify and interrupt. And there are leaders who've made the shift, sometimes dramatically.
We've got two threads to pull on here. One is diagnostic — what's actually happening under the hood when a smart person can't delegate? And the other is practical — if you recognize yourself in this description, what do you actually do about it?
I think the diagnostic piece matters more than people expect, because the surface explanation is usually wrong. People say "oh, they're a control freak" or "they have trust issues," and that might be true in some cases, but it doesn't explain why this shows up in people who are otherwise emotionally intelligent, self-aware, and want their teams to succeed.
The road to bottleneck hell is paved with good intentions.
It really is. And part of what we need to unpack is how organizational structures actually reward this behavior, even when they say they don't. If you look at how most promotion systems work, the star individual contributor gets promoted to manager, and then we evaluate them on... Nobody gets a bonus because their team made great decisions without them.
The system says "build a team" but the incentives say "be the hero.
There's a study from the Journal of Applied Psychology in twenty twenty-three that found sixty-eight percent of first-time managers report serious difficulty transitioning from doing to enabling. That's not a minority — that's the majority experience. And the reason isn't that these people are bad at management. It's that the skills that got them promoted are the opposite of the skills they now need.
We're asking people to unlearn the thing they were just rewarded for.
That's hard enough when you have support and training, which most first-time managers don't. You get the title, maybe a half-day workshop, and then you're expected to figure it out — while also doing your old job, usually. The classic "player-coach" trap. You're supposed to be enabling the team, but you're also still carrying an individual contributor workload, and when the deadline hits, guess which one gets prioritized? You default to doing it yourself because that's what you know works.
We've got a psychological layer, a structural layer, and an incentive layer all pushing in the same direction. It's almost surprising anyone learns to delegate.
Which is why the people who do it well are worth studying. Daniel mentioned the counterexamples — the high achievers who've built their success on being multipliers rather than bottlenecks. And I think the distinction between those two archetypes is the spine of this whole conversation.
Let's set that up properly, then. What actually distinguishes the bottleneck boss from the multiplier?
If you look at the bottleneck archetype — and I think Steve Jobs in his first Apple stint is the canonical example — the defining feature isn't that the person is unpleasant or hostile. It's that their identity has fused with the output. Jobs couldn't separate "a good product" from "a product Steve Jobs personally shaped." And when those two things become synonymous in your head, delegation feels like abdication.
The product is you, and you are the product. Handing off a decision feels like handing off a piece of yourself.
The Elon Musk at Twitter slash X version is a more recent, more extreme case study — sleeping at the office, personally reviewing code, firing people who push back, and then discovering that the organization grinds to a halt when every decision routes through one exhausted person. It's the same pattern at higher velocity.
What's striking about both cases is that these are not dumb people. They just can't decouple their sense of what's excellent from their own fingerprints on the work.
That's where the multiplier archetype becomes interesting, because it's not that Satya Nadella or the Bezos two-pizza-team model represents people who care less about quality. Nadella's whole cultural transformation at Microsoft was built on shifting from "know-it-all" to "learn-it-all." He explicitly rewarded managers for growing their reports, not for being the smartest person in every meeting.
The distinction isn't about standards. It's about where you locate excellence — in yourself or in the system you build around you.
The two-pizza team model is a structural answer to this. Bezos's rule was that no team should be larger than what two pizzas can feed, because beyond that size, communication overhead kills autonomy. But the unspoken corollary is that a two-pizza team only works if the leader actually lets the team make decisions. Otherwise it's just a small group waiting for one person's approval, which is worse than a large group waiting — at least the large group can parallelize the waiting.
The bottleneck boss creates a system where the organization's throughput is capped at their personal bandwidth. The multiplier designs a system where throughput scales with the number of capable teams.
Here's the structural layer Daniel was hinting at — it's not purely a personality difference. The bottleneck boss often emerges in organizations that reward individual heroics. The multiplier emerges where the incentives are aligned with team outcomes. You can take the same person and put them in two different environments and get completely different delegation behavior.
We're saying this is partly ego, partly identity fusion with the work, and partly the structure and incentives around the person. But there's also the cognitive piece — the actual mental model of what the leader's job is.
That might be the most important layer. If you believe your job is to make decisions, then every decision you don't make feels like you're not doing your job. But if you believe your job is to create the conditions under which good decisions get made by the right people, then delegation isn't a concession — it's the actual work.
That reframe alone probably does more heavy lifting than any twelve-step management framework.
It's hard to internalize because it's invisible. When you make a great decision yourself, everyone sees it. When you build a system where someone else makes a great decision, nobody sees your contribution. It's like being a playwright instead of the lead actor — you're offstage while the applause happens.
Which explains why so many high performers resist it. They're not just giving up control — they're giving up visibility and recognition. That's a lot to ask of someone whose entire career has been built on being recognized for being excellent.
That recognition piece connects directly to the psychology. There's a cognitive pattern I think of as impostor syndrome's evil twin. With impostor syndrome, you discount your successes — you think you got lucky, or fooled everyone. This is the inverse. Your track record of being right, repeatedly, in high-stakes situations, creates a prior so strong that you believe your judgment is uniquely reliable.
Instead of "I'm not as good as they think," it's "they're not as good as I am.
The scary part is it's not delusional. These people often are the best in the room at what they do. That's how they got there. The Bayesian update is correct on the data they have. What they're missing is the second-order data — that their intervention is degrading the very thing they're trying to protect.
They're optimizing for the decision in front of them and ignoring the capability they're destroying one override at a time.
There was a twenty twenty-five Re:Work case study that captured this almost perfectly. A senior VP at a FAANG company — anonymized — rated exceeds expectations for five straight years. Stellar performance reviews. But her team had a forty percent turnover rate over that same period. The company's average was twelve percent.
She was a five-star individual performer running a revolving door.
Nobody connected those dots for years because the performance review system only measured her output, not her team's health. She was crushing her goals while her best engineers were quietly updating their LinkedIn profiles.
That disconnect is almost too perfect. The system told her she was doing great, so why would she change?
That's where the structural layer gets vicious. Most promotion systems are built on what's visible — deals closed, features shipped, crises averted. If you avert a crisis by personally jumping in at two in the morning, that shows up as heroism. If you avert a crisis by having built a team that handles it without you, nothing shows up at all.
The system rewards the bottleneck and ignores the multiplier.
Then there's the compounding effect. McKinsey published a report in twenty twenty-four looking at decision-making velocity across organizations, and they found that companies with centralized decision-making suffer forty percent longer cycle times on any project that requires cross-functional input. That's not marginal.
Every decision you pull upward doesn't just add its own latency. It creates a dependency web where the next five decisions are now waiting on the same person.
That's the critical path dependency problem Daniel was describing. Imagine a product manager who assigns a feature to an engineer, the engineer builds it over a sprint, and then at the review the PM rewrites the spec. What happens next sprint? The engineer doesn't commit fully — they produce something safe, provisional, waiting to be corrected. Which the PM then does correct, confirming their belief that they needed to intervene.
The engineer learns that effort is wasted because the output will be replaced. The PM learns that the engineer can't be trusted because the output is always half-baked. Both are drawing rational conclusions from the data they're seeing, and both are wrong about the cause.
It's a textbook vicious cycle. And it spreads. The engineer mentions it to their colleague over lunch. The colleague starts sandbagging too. Within six months the entire team is operating at sixty percent initiative because everyone's waiting for the override.
The PM is exhausted, working nights and weekends, convinced they're the only thing holding the product together. Which, at that point, they are — but they built that reality themselves.
The tradeoff between speed and scale isn't even a real tradeoff. The bottleneck boss thinks they're choosing speed by cutting out the deliberation and just making the call. But they're actually choosing a fast decision today at the cost of every decision being slow tomorrow, because the team stops deciding anything. Every choice escalates upward. The leader becomes the single point of failure — not just for quality, but for basic forward motion. If that person takes a vacation, the organization effectively pauses.
Which is when you discover that what looked like a high-functioning operation was really just one person's nervous system keeping everything alive.
The sixty-eight percent of first-time managers who struggle with the doing-to-enabling transition — they're not struggling because they're bad people or bad managers. They're struggling because nobody taught them that their job description just fundamentally changed. They were promoted for being the best doer, and now they need to be the best enabler, and those are different skillsets entirely.
It's like promoting your best violinist to conductor and then wondering why the orchestra sounds thin when they keep putting down the baton to play their own part.
We've seen the bottleneck pattern up close. But the encouraging thing — and this gets to the second half of Daniel's question — is that the alternative isn't theoretical. There are leaders who've built their success on being multipliers, and their mechanisms are surprisingly concrete.
I think that's the right word — mechanisms. Not personality traits. Not "some people are just good at this." There's an actual architecture to effective delegation.
Let me give you the counterexample that makes the architecture visible. When Satya Nadella took over Microsoft, the company was infamous for internal competition — stack ranking, know-it-all culture, people hoarding information. Nadella shifted the entire incentive structure toward what he called "learn-it-all." He explicitly rewarded managers for growing their reports. And the Microsoft Work Trend Index in twenty twenty-four found that seventy-three percent of employees under managers who operated this way reported higher innovation output.
Seventy-three percent is not subtle. That's a different organization.
The mechanism underneath it isn't "be nice to people." It's what I'd call decision-making scaffolds. Nadella didn't just hand off decisions and walk away — that's delegation with abandonment, which is its own failure mode. He created delegation with guardrails. Clear domains of authority. Explicit criteria for when something needs escalation. A shared framework for what good looks like, so the team can evaluate their own work against it.
It's not a binary between "I decide everything" and "good luck, you're on your own.
The abandonment version is a real trap. Some leaders, when they finally realize they're bottlenecking, overcorrect. They dump decisions on people without context, without criteria, without support. Then when things go wrong they say "see, delegation doesn't work" and snap back to control.
The pendulum swing. "I tried delegating once and it was a disaster.
Which is like saying "I tried exercising once and it hurt, so I'll never do it again." Delegation is a skill that has to be built, on both sides. The leader has to learn to scaffold, and the team has to learn to operate within the scaffolds.
There are knock-on effect when you get this wrong that go beyond just slow decisions. One of them is the bus factor — the number of people who'd have to get hit by a bus before the organization collapses. In a bottleneck boss setup, that number is one.
And it's not just about the person leaving — it's about what happens when they take a two-week vacation and suddenly nothing moves. I've seen teams where the entire decision-making apparatus is just one person's mental model, and nobody else has enough context to fill in.
Another knock-on effect is innovation stagnation. If every idea has to pass through one person's filter, you're not getting diversity of thought. You're getting variations on a theme.
Which leads to what I think of as the clone trap. The bottleneck boss tends to hire people who think like them, because those are the people whose judgment they trust. And then they wonder why nobody brings fresh perspectives.
Hiring your own echo chamber and then being disappointed it doesn't generate new ideas.
The multiplier avoids this because they're not looking for people who replicate their thinking — they're looking for people who complement it. The whole point of delegation with guardrails is that the guardrails provide the alignment, and within those guardrails, you want as much cognitive diversity as you can get.
The architecture matters, the knock-on effect are real, and we've established that the bottleneck boss isn't doomed by personality. Which brings us to the most practical part of Daniel's question — if someone recognizes themselves in this, what does change actually look like?
This is where the coaching literature is useful, because there's a fairly well-established arc. I want to walk through what a typical twelve-week executive coaching engagement looks like for exactly this issue.
That's specific.
It's the standard window where measurable behavioral change starts to show up. Weeks one and two are diagnostic. You log every decision you make for a week — and I mean every decision, from "which vendor do we use" to "what time should the standup be." Then you categorize each one: had to be me, could have been someone else with guidance, or should have been someone else entirely.
Most people are going to be surprised by that third category.
The typical finding is that forty to sixty percent of decisions fall into "should have been someone else entirely." The leader is spending more than half their decision-making energy on things that don't require their expertise or authority. They're just... in the habit.
Step one is just seeing the pattern. And it's often humbling.
Weeks three through six are what coaches call decision journaling and delegation experiments. You start with low-stakes, reversible decisions — the kind where the cost of being wrong is small. You hand one off with clear guardrails: here's the desired outcome, here are the constraints, here's the budget, come back in forty-eight hours with your recommendation.
The forty-eight hours matters because it forces you not to hover.
The commitment is not to touch it. You don't check in. You don't ask for a preview. You let the person do the work and you see what comes back. And the debrief afterward is where the real learning happens — for both sides.
What does that debrief look like?
The leader asks three questions. What did you decide and why? What information did you use? What would you do differently next time? Notice what's not in there — "here's what I would have done." The point is to understand the decision-making process, not to grade the outcome against your own hypothetical.
You're coaching the capability, not auditing the result.
That distinction is everything. Weeks seven through ten are about building feedback loops and learning to tolerate "good enough." This is the hardest phase, because the leader has to sit with the discomfort of an outcome that's eighty-five percent as good as what they would have produced — and recognize that the fifteen percent gap is an investment in the team's growth, not a failure.
The delegation learning curve. You accept short-term quality loss for long-term capability gain.
By weeks eleven and twelve, the goal is to scale the practice. The leader has a tiered decision framework — only certain categories of decision require their sign-off — and they've trained the team to operate within it. The CTO case study from twenty twenty-five is instructive here. Series B startup, CTO reviewing every pull request and personally blocking deployments. After eight weeks of coaching, she implemented a tiered review system where only architectural changes required her approval. Code quality metrics stayed flat, but her review load dropped seventy percent.
Seventy percent fewer reviews, same quality. That's not a tradeoff — that's just eliminating waste.
She got back something like fifteen hours a week. But more importantly, her senior engineers started making architectural decisions themselves because they'd been practicing on smaller ones for weeks. The capability compounded.
The coaching journey isn't mysterious. It's diagnostic, then experiments, then feedback loops, then scaling. But it does require the one thing that's hardest for the bottleneck boss — admitting that the current system has a cost.
That's the threshold question Daniel was really asking. Is this coachable? The evidence says yes, but only if the person can see the cost. The FAANG VP with forty percent turnover — she didn't change until someone showed her the attrition numbers next to her performance reviews. The data broke through the narrative.
If someone's listening and recognizing the pattern, the starting point is simpler than most people expect. For one week, log every decision you make. Not the big strategic ones — everything. What meeting time, which vendor, who staffs what, whether to push back on a client request. Then sort each one into three buckets. Bucket one: had to be me. Bucket two: could have been someone else with some guidance. Bucket three: should have been someone else entirely.
I'd bet most people are terrified of what bucket three looks like.
The typical finding is forty to sixty percent of decisions land in that third bucket. The leader is spending more than half their decision-making energy on things that don't need their authority or expertise. They've just accumulated them over time like barnacles.
The audit itself is the intervention. You can't unsee it once you've logged it.
The second piece is a framework that Amazon formalized but that predates them — the reversible versus irreversible distinction. If a decision is reversible, delegate it even if you disagree. If you can walk it back without catastrophic cost, the learning value of letting someone else make the call outweighs the risk of a suboptimal outcome.
Disagree and commit. But applied downward, not just upward.
Reserve your veto for truly irreversible calls — the ones where the cost of being wrong is existential. Everything else is a training opportunity dressed as a decision.
What does someone actually do this week? If they're listening and thinking "alright, I'm in this trap, what's step one?
Pick one task you normally do yourself. Something concrete — a report you always write, a client communication you always handle, a review you always conduct personally. Give it to a team member with clear guardrails. Not a blank check — here's the outcome we need, here are the constraints, here's when I need it back. Then commit to not touching it for forty-eight hours.
The forty-eight hours is the hard part.
It's the whole point. If you check in after six hours, you haven't delegated — you've assigned homework with a pop quiz. After forty-eight hours, you debrief. What did they decide and why? What information did they use? What would they do differently? You're not grading the outcome against your hypothetical. You're understanding their process.
If the result is eighty percent as good as what you'd have done?
You say thank you, you give one piece of feedback, and you hand them the next one. The gap closes faster than you think.
That brings us to the question Daniel was really driving at. Is this a skill you can learn, or is it a personality trait that resists change?
Because if it's the latter, a lot of people are stuck.
The evidence points toward coachable, but with a pretty significant caveat. The coaching only works if the person first recognizes the cost of their current behavior. And that recognition step — actually seeing that your competence is creating a tax on everyone around you — that's the hardest part of the whole journey.
It requires sitting with the possibility that your greatest strength has become your team's greatest liability. That's not a comfortable mirror.
Most organizations make it easy to avoid that mirror. If your performance reviews only measure your output, if nobody tells you about the attrition, if the system keeps telling you you're exceeding expectations — why would you look?
The bottleneck boss isn't just a personal failure pattern. It's a failure pattern that organizations are structurally complicit in creating and sustaining.
Which is why I think the next decade is going to force this conversation in a way the last decade didn't. AI tools are getting better at automating individual contributor work — writing code, generating reports, analyzing data. The thing that won't be automated is the ability to scale through other humans.
Delegation stops being a nice-to-have management skill and becomes the defining competency. If you can't multiply through people, and the machines can do what you used to do as an individual contributor, what exactly is your value?
That's the question a lot of leaders are going to have to answer. And the ones who've built the delegation muscle will have an answer. The ones who haven't — they'll just be slower, more expensive versions of the AI.
A grim thought to end on, but also a clarifying one.
I think it's actually hopeful. If delegation is coachable — and the twelve-week arcs, the decision audits, the tiered review systems all suggest it is — then this is something people can build. It's not a gift you're born with or without. It's a practice.
And now: Hilbert's daily fun fact.
Hilbert: In the nineteen forties, researchers in Equatorial Guinea documented a species of orb-weaver spider whose dragline silk, by weight, has a tensile strength exceeding that of steel — and individual strands measured under fifty nanometers in diameter, making it one of the thinnest load-bearing biological fibers ever recorded.
...right.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you want more episodes, you can find us at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back with another one soon.
