Zašto sve još uvijek završava kod osnivača
Delegiranje ne uspijeva jer su ljudi nesposobni, već zato što sustav ionako sve vraća osnivaču.
I keep hearing the same complaint from founders who’ve tried to step back from the day-to-day: “I delegated, but everything still comes back to me.”
They hired people. They assigned responsibilities. They told their team to “own it.” And yet, every decision, every exception, every question somehow lands on the founder’s desk.
The common explanation is that the team isn’t ready. They lack experience, initiative, or confidence. Give them time.
But time rarely fixes this. Because the problem isn’t the people. It’s the system.
The Invisible Routing
Delegation fails when the structure still points at the founder.
Think about how decisions actually move through a small business. Someone encounters a situation that doesn’t fit the normal pattern. They need guidance. Where do they go?
If the answer is “ask the founder,” then you haven’t delegated anything. You’ve just added a step. The work gets done by someone else, but every exception—every judgment call—still routes to the same bottleneck.
This isn’t a training problem. It’s an architecture problem. The system is designed (or more often, evolved) to route everything through one person. That person is the founder because the founder built the system, mostly by accident, mostly by being the answer to every question for years.
What Creates the Routing
Three things usually cause founder dependency:
Unclear boundaries. People don’t know what they’re allowed to decide. The scope of their authority was never defined—or it was defined vaguely. “Use your judgment” isn’t a boundary. It’s a permission that feels like a trap.
When boundaries are unclear, the safe choice is to escalate. Ask the founder. Get approval. Cover yourself. This isn’t timidity; it’s rational behavior in an ambiguous system.
Missing defaults. What happens when no one knows the answer? In most small businesses, the default is: ask the founder. There’s no documentation to check, no precedent to follow, no designated decision-maker for that category of question.
Every business has these gaps. The question is whether they’re covered by something—or someone. When they’re covered by the founder, every gap becomes an interruption.
Rewarded dependency. Founders often create their own bottleneck by being too available, too responsive, too helpful. If I can get an instant answer by asking the founder, why would I spend twenty minutes figuring it out myself?
This isn’t malicious. It’s efficient—in the short term. But it trains the organization to route through the founder. It makes dependency the path of least resistance.
Why It Persists
Founder dependency is self-reinforcing.
The more decisions flow through the founder, the more context the founder accumulates. The more context they have, the better their decisions. The better their decisions, the more rational it is to ask them. The cycle tightens.
Meanwhile, the team never develops their own context or judgment. They’re not allowed to make enough decisions to learn. The founder stays indispensable because the system keeps them that way.
This is why “just step back” doesn’t work. If you step back without changing the structure, the structure pulls you back in. The routing is still pointing at you. The gaps are still uncovered. The boundaries are still unclear.
What Would Need to Change
Breaking founder dependency requires changing the system, not just the behavior:
Define decision boundaries explicitly. Write down what each role can decide without asking. Not vaguely—specifically. “You can approve expenses under $500” is a boundary. “Use your best judgment on spending” is not.
Install defaults. For the questions that currently route to the founder, create a default answer. “If you’re not sure, do X.” This won’t cover every situation, but it covers most of them. The exceptions become the exceptions, not the rule.
Make escalation expensive. Not punitive—just inconvenient enough that people try to solve things themselves first. Maybe escalations require a written summary. Maybe they’re batched instead of handled instantly. Maybe the answer is “what do you think we should do?” before giving the actual answer.
Accept worse decisions temporarily. This is the hard one. When you stop being the router, some decisions will be worse than if you’d made them. That’s the cost of building capacity. The team learns by deciding, including deciding wrong.
The Real Delegation
Real delegation isn’t telling someone to handle something. It’s building a structure that doesn’t need you.
That means boundaries clear enough that people know their authority. Defaults documented enough that gaps don’t become interruptions. Incentives aligned so that solving it yourself is easier than escalating.
Founder dependency is a system design problem. The founders who escape it are the ones who treat it that way.
Related
Founder dependency often persists because founders feel they need to be constantly available to their team. This creates its own costs—both personal and organizational. See: The Cost of Always Being Available.