How to Stop Being the Bottleneck in Your Own Company

Somewhere between fifteen and forty people, most founders discover they have become the slowest part of their own company. Nothing ships without a nod. Slack is a queue with your name on it. You spend the day being helpful and go home having built nothing.

"Everyone asks me everything. I cannot take a day off without three things stalling."

The standard advice is to delegate more and trust your team. That advice is not wrong, it is just not actionable, and founders who try it usually find the questions come straight back within a month.

Why it is you, and why that is not a character flaw

People ask you because you are the cheapest source of a correct answer. You know the history, you know the client, you know why the obvious option was ruled out in March. Asking you takes forty seconds. Finding out any other way takes twenty minutes and might still be wrong.

Given those two options, a sensible employee asks you every time. They are not being lazy or dependent. They are optimising exactly as you would. So the fix is not to tell them to stop asking. The fix is to make the other route cheaper than asking you.

This reframing matters because it changes what you work on. You stop working on your own willingness to delegate, which was never the problem, and start working on what makes you the fastest route.

The two week count

Keep a note open. Every time you answer a question, write one line: the question, who asked, and whether you have answered it before. Two weeks is enough. One week undercounts because it misses the monthly rhythms.

Most founders who do this are surprised by two things. The volume is higher than they thought, because the forty second answers do not register as work. And the repeat rate is far higher than they thought. The same eight or ten questions come back, from different people, in slightly different words.

That repeat list is your whole project. It is usually short enough to fit on one page, which is the good news.

Sort what you find into four buckets

Bucket	Sounds like	What to do
Facts	"What is our refund window?"	Write it once, where people look
State	"Where did we land with Acme?"	Make the current state readable without you
Permission	"Can I approve this refund?"	Set a limit and a named owner
Judgement	"Do we take this client at all?"	Keep it. This is your job.

Permission questions are the quickest win and the one founders most often miss. "Can I spend 400 euros on this" is not a question, it is a missing threshold. Write the threshold down and the question disappears for good. Do this for refunds, discounts, small hires, tool purchases, and client scope changes, and a surprising share of your inbox goes quiet.

Hand over the reasoning, not the rule

Here is where most delegation fails. You tell someone they own pricing decisions under 5,000 euros. Three weeks later they make a call you would not have made, you correct it, and they quietly start checking with you again. Now you have the same bottleneck plus a demoralised colleague.

The gap is that you handed over the authority without the reasoning. What they needed was not the rule, it was the half dozen judgement calls you have already made in this area and why. Why you walked away from the discount the reseller wanted. Why the education pricing exists. Why you say yes to annual and no to multi year.

Write those down as short decision records: what was decided, what the alternative was, and why the alternative lost. The reason the obvious option was ruled out is the single most valuable thing you can hand over, and it is the thing that lives nowhere except your head. There is a template in the decision log template, and the case for keeping them in why decisions keep getting revisited.

What should still reach you

The facts bucket can be written down. The permission bucket can be replaced with thresholds. The judgement bucket is your actual job and should stay.

The state bucket is the awkward one. "Where did we land with Acme" cannot be written in a policy because it changes every week, and it is usually the largest slice after facts. So it keeps coming to you, and it keeps coming to you on Saturday.

This is the gap StandIn is built for. At the end of the day you spend about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. When you are off, your StandIn answers questions from that brief, in your words, with a source under every answer. It never guesses, and when the answer is not in the brief it says so and names who to ask. The facts and state questions stop reaching you. The judgement calls still do, which is the point. See how StandIn works.

Common Questions

How long before this actually reduces my load?

The permission thresholds work within days, because they remove whole categories of question at once. The written facts take two to three weeks, because people have to learn to look. The decision records are slower and they are what stops the questions coming back in a different form.

What if my team makes worse decisions than me?

They will make different ones, and some will be worse. The question is whether the average cost of those is higher than the cost of every decision waiting on your calendar. For reversible decisions it almost never is. For irreversible ones, keep them. We separate the two in reversible and irreversible decisions.

Is hiring a chief of staff the answer?

It works if the role owns real decisions. It fails if the role is a filter in front of you, because then you have paid for a second bottleneck and added a step. The test is whether anything gets decided without reaching you afterwards.

I have tried writing things down and nobody reads it.

Usually because the written version is slower to use than asking you. People read what is one click from where the question occurs to them, and ignore what is three clicks away in a document tree. Put the answer where the question gets asked.