How to Stop Being the Bottleneck in Your Business

Why 'being the bottleneck' is actually six different problems

Founders often describe feeling like 'everything goes through me' as a single, vague problem, but in practice it's usually one or two specific, nameable chokepoints rather than a general condition. Treating it as vague makes it feel unsolvable; naming the specific bottleneck makes it something you can actually fix within weeks rather than months.

There are six common types worth checking against your own business: decision bottlenecks (nothing moves without your sign-off), money bottlenecks (only you can approve or make payments), knowledge bottlenecks (only you know how something works), customer-relationship bottlenecks (clients will only deal with you), systems bottlenecks (nothing is written down so nothing runs without you present), and absence bottlenecks (the business genuinely cannot function if you're away).

Most small businesses have two or three of these active at once, usually connected — a knowledge bottleneck often causes a decision bottleneck, because nobody else has enough information to decide confidently. Untangling which is the root cause and which is the symptom is the first real step.

Diagnosing which bottleneck is actually hurting you most

Before fixing anything, spend a week noticing every time something waits on you specifically. Keep a simple running note: what was waiting, how long it waited, and which of the six types it falls into. After a week you will usually see a clear pattern rather than a diffuse feeling of being stretched thin.

• Decisions: how often do people ask 'is it okay if...' for things within their role?
• Money: how many payments or approvals under a sensible small threshold still route to you?
• Knowledge: how many times a week does someone ask you how something works rather than checking a document?
• Customer relationships: would a client accept being handled by someone else on your team today?
• Systems: if a task has to happen and you're not there, does it actually happen correctly?
• Absence: what genuinely breaks if you take a fortnight fully offline?

Whichever bottleneck caused the longest single delay in your week-long log is usually the one worth fixing first, not the one that annoys you most day to day.

Moving a decision bottleneck

Decision bottlenecks are usually the easiest to move and a good place to start if you have several. The fix is a written decision-rights map: for the recurring categories of decision in your business, state explicitly who can decide alone, who needs to consult you first, and what must always come to you regardless of who's involved.

Write this as a short table rather than a long policy — category of decision, who decides, any limit or condition. Share it with the team and, critically, hold to it yourself: if someone makes a decision correctly under the authority you gave them, resist the urge to second-guess it publicly even if you'd have chosen slightly differently, or the decision-rights map will stop being trusted within a month.

Moving a money bottleneck

If every payment, refund or purchase requires your personal approval, you have built a system where cash flow literally cannot move without you being available. The fix is a written spending policy with a no-approval threshold for routine, low-value items, an approval band that a nominated second person can sign off, and a founder-only band for anything above that.

Set the thresholds based on what would genuinely worry you if it went wrong, not on a vague sense of caution — a no-approval limit of £20 to £50 for routine purchases is common in small teams and rarely causes real problems, while it removes a large volume of small interruptions from your day.

1. Decide your no-approval threshold for routine spending
2. Decide your approval band and who else can sign off within it
3. Set the founder-only band for anything above that
4. Require evidence (receipt, invoice) at every level, not just the largest one
5. Write down what happens when someone leaves — access removed the same day, not 'soon'

Moving a knowledge bottleneck

If you're the only person who understands how a key process actually works, that knowledge needs to move into a written procedure before anything else changes, because delegating authority for a task nobody else understands just moves the risk rather than removing it. This connects directly to building an operations manual: document the process, have someone else follow it exactly as written, and fix whatever gaps that test reveals.

Knowledge bottlenecks are often the hidden cause behind decision and absence bottlenecks, so if you're only able to fix one thing, this is frequently the highest-leverage place to start, even though it feels less urgent day to day than a queue of decisions waiting on you.

Moving a customer-relationship bottleneck

This is usually the slowest bottleneck to move and the one founders are most reluctant to touch, because client relationships often feel personal and hard-won. Rushing it — suddenly handing a long-standing client to someone else with no warning — often backfires and can genuinely damage the relationship, so this needs a longer, more deliberate lead time than the others.

Start by including a team member in calls or meetings as a genuine participant, not a silent observer, so the client gets used to a second face over several interactions. Gradually shift smaller, lower-stakes parts of the relationship — routine updates, small requests — to that person while you remain visible and available for anything larger, then step back further only once the client has clearly built trust in the new contact.

Moving a systems bottleneck

A systems bottleneck exists when work only happens correctly because you're physically present to catch errors or fill gaps, rather than because a reliable process exists independent of you. This overlaps heavily with the knowledge bottleneck but is broader — it includes access to tools, consistent formats, and checklists, not just documented know-how.

The practical fix is the same discipline as building an operations manual: identify the recurring processes, write them down in a consistent format, and test them with someone who doesn't already know how the task works. The test is the part most founders skip, and it's the part that actually proves the system works without you.

Moving an absence bottleneck

This bottleneck only becomes visible when you try to genuinely step away, which is exactly why it's worth testing deliberately rather than discovering it during an actual emergency or holiday. Plan a real, planned absence — even a few days — and beforehand, map every responsibility that currently sits with you to a named cover person, a spending or decision limit for that person, and an escalation route for anything genuinely urgent.

Treat the first planned absence as a test, not a real handover: stay reachable for true emergencies, but resist checking in otherwise, and debrief afterwards on what actually came up and how it was handled. Each successful test makes the next absence easier and reveals the next gap to close.

• List every responsibility that currently sits only with you
• Assign a named cover person to each one, with a clear limit on their authority
• Set an escalation route for anything that exceeds that limit
• Check the cover arrangement against your bank's and insurer's requirements where money or contracts are involved
• Debrief after the absence and fix whatever gap actually surfaced

What to expect after you move a bottleneck

Immediately after moving any bottleneck, expect a short dip — slightly slower decisions, a payment that takes an extra day, a client email that isn't answered in quite your usual style. This is a normal adjustment period, not evidence the change was a mistake, and reversing it at the first sign of friction teaches everyone that the old way was actually the real one.

Give any change at least a few full cycles — a few weeks for daily processes, a couple of months for slower-moving relationships — before judging whether it's working. Track it against the same log you used to diagnose the bottleneck in the first place, so the comparison is based on evidence rather than a general feeling of unease.