How to Avoid Hero Dependency in a Scaling Team
Every scaling company has two or three people it cannot function without. They know the system nobody else understands, they hold the customer relationship nobody else has, they are the only person who can ship the thing when it matters. You are grateful for them and quietly anxious about them, and you have probably never done anything about it, because doing something about it looks like reducing the contribution of your best people. This page is about why the structure creates heroes, why the heroes cannot solve it themselves, and what the fix actually costs.
What’s inside
Heroes are created by structure and rewarded by accident
The four kinds of hero dependency
Why the hero cannot fix it
The four fixes
What you are asking the hero to give up
The incentive problem
Where Blomma fits
Heroes are created by structure and rewarded by accident
Nobody sets out to build a company with single points of failure. It happens through a sequence of individually sensible decisions.
Something urgent needs doing and one person is fastest at it, so they do it. Being fastest, they do it again next time. Because they do it repeatedly, they accumulate context nobody else has, which makes them faster still, which makes assigning it to them more obviously correct. Within a year the work has a name attached and no documentation, and the alternative — having someone slower do it while learning — costs more than any individual instance justifies.
The reinforcement is the part founders miss. Heroes get visible appreciation, interesting work, and the reputation of being indispensable, all of which are genuine rewards. Meanwhile the person who documented their work so that someone else could do it gets nothing in particular, and has arguably made themselves less visibly necessary. You have created an incentive to accumulate dependency, without intending to and usually without noticing.
So this is a structural and incentive problem, not a matter of anyone hoarding. Framing it as hoarding is both inaccurate and the fastest way to lose the person.
The four kinds of hero dependency
Four distinct versions, with different fixes.
Knowledge dependency.They know how something works and nobody else does — a legacy system, a data pipeline, the reasoning behind a critical design decision. The most common and the most tractable.
Relationship dependency.They personally hold a customer, partner, or candidate pipeline. The most business-critical, because the risk is revenue rather than velocity, and the least discussed.
Judgment dependency.They are the only person whose call on a certain class of problem the organisation trusts — often an architecture, pricing, or quality decision. Harder, because judgment does not transfer by documentation.
Execution dependency.When something must ship, they are the one who ships it. The most flattering to the hero and the most dangerous, because it usually means the team’s normal process does not work and one person is compensating for that continuously.
Most companies have all four spread across two or three people. Knowledge and relationship dependencies are usually where to start, because they are the most fixable and the most catastrophic if the person leaves suddenly.
Why the hero cannot fix it
A point worth being clear about, because the standard approach is to ask them to.
Asking your hero to document their knowledge, hand over the relationship, or bring someone else up to speed puts the burden on the person with the least available time and the least incentive. They are the busiest person you have, precisely because everything routes through them. Whatever spare capacity they have is consumed by the next urgent thing that only they can do.
And the request is genuinely costly to them. Documenting takes time they do not have, produces nothing visible this quarter, and reduces the thing that has been rewarded. Even a completely generous person, wanting to help, will deprioritise it under pressure — not from self-interest, but because the urgent work is real and the documentation deadline is soft.
So the standard intervention — asking nicely, repeatedly, and being mildly frustrated when it does not happen — fails predictably. If you want the dependency reduced, you have to change the structure and the incentives, and the cost has to be borne visibly by the company rather than by the individual in their spare time.
The four fixes
For knowledge dependency: pair, then rotate.Documentation alone rarely works, because the tacit part does not write down. Assign a second person to work alongside the hero on the relevant area for a defined period, then have the second person do it while the hero reviews. Slower for a quarter and it transfers what a document cannot. Protect the time explicitly — it will not happen in the margins.
For relationship dependency: introduce a second owner now.Not a handover — a second point of contact, immediately, on every relationship that matters. Frame it to the customer as additional service rather than a transition. This is the cheapest fix on the list and the one with the largest downside if you skip it.
For judgment dependency: make the reasoning visible, not just the decision.Have the hero write up why on the calls they make, and run a forum where they walk others through their reasoning on live problems. Judgment transfers through exposure to reasoning, which means the hero needs to think out loud rather than simply decide.
For execution dependency: fix the process the hero is compensating for.This is the important one. If one person is the reason things ship, your normal delivery process does not work, and the hero has been hiding that. Ask what specifically they do in a crunch that the process does not, and address that. Removing the hero without fixing the process just removes the ability to ship.
Across all four: give the transfer a named owner, a defined period, and protected time. Anything that depends on the hero finding spare capacity does not happen.
What you are asking the hero to give up
Worth acknowledging, because if you handle this part badly you will fix the dependency and lose the person.
Being indispensable is a genuine source of status, security, and interesting work. When you distribute their knowledge or introduce a second owner to their relationship, you are removing something they value, whether or not either of you would put it that way. Some heroes experience this as a demotion, and a few will read it as the company preparing to not need them.
So say the opposite explicitly and early. The message is that they are being freed from being the only option, not being replaced — and it is only credible if it comes with something. Give them the harder problem, the thing they have wanted to work on, the scope they could not take because they were pinned. A hero who is relieved of the pinning and handed something more interesting will help you dismantle the dependency. A hero who is asked to document their value and given nothing will resist, reasonably.
And be honest that this is partly about company risk. Most senior people understand key-person risk perfectly well and would rather be treated as an adult about it than managed around.
The incentive problem
The deeper fix is changing what gets rewarded, and it is the part almost nobody does.
Right now the person who makes themselves necessary gets recognition, and the person who makes themselves replaceable gets nothing measurable. Until that changes, you will keep generating heroes as fast as you dismantle them.
A few concrete moves. Make knowledge transfer an explicit part of senior expectations — written into the level definitions, assessed in reviews, and referenced in promotion decisions. Recognise it publicly when it happens, in the same register you recognise a heroic delivery. And notice what you praise: if your instinct is to celebrate the weekend rescue and say nothing about the quiet pairing that prevented next quarter’s rescue, your team is learning which one matters.
One test of whether you have changed anything: can someone name a promotion that happened partly because the person made themselves less individually necessary? If not, the incentive is unchanged regardless of what the level definitions say.
Where Blomma fits
The hard part here is not the diagnosis. It is the conversation with someone valuable, whose contribution is real, about reducing the thing that has made them feel valued — and doing it without them concluding that the company is preparing to need them less.
Blomma is an always-on AI career coach with no stake in your team. Use it to work out which of the four dependencies you actually have and where the real risk sits — usually relationships, which founders address last. Use it to prepare the conversation with the hero, including what you are going to offer in exchange, which is the part that determines whether they help or resist. And use it to check whether your own praise patterns are generating the problem you are trying to solve.
There is a second application. The people you are asking to absorb a hero’s knowledge are being stretched into unfamiliar work, and the hero is being asked to develop someone, which is often a skill they have never built. Coaching for both sides of a transfer is what makes it stick rather than stall..
Hero dependency is not a people problem and it is not disloyalty. It is a structure that made one person the fastest path, and an incentive system that quietly rewarded them for staying that way.