Open your calendar, messages, task board and recent drafts. Find up to ten moments when work came back to you for a decision, a rewrite, missing context, an introduction or a rescue. Write down the work itself, rather than every message that mentioned your name.
This founder bottleneck audit produces no score. It gives the team one recurring dependency to confirm, correct or disprove.
Start with last week's work
Use the last five normal working days, starting with the most recent return and stopping at ten. If the week contains fewer, use what is there instead of extending into an unusual period to hit a number. A launch, a key absence or a customer incident can flood the record with exceptions, so choose a more representative week if the latest one was unusual.
- 01
The moment
Write down the actual decision, draft, exception, handoff or rescue that came back. Use a short description such as 'pricing exception before proposal' rather than a department such as 'sales'.
- 02
The closest owner
Name the person already responsible for the outcome or closest to the evidence. If the answer is 'the team', the ownership is still too vague for the audit.
- 03
What only you supplied
Record the specific input: decision, context, quality standard, relationship access, authority or hands-on rescue. Avoid writing 'experience' unless you can say which judgement your experience changed.
- 04
What the wait changed
Capture elapsed delay, reopened work, a meeting that moved, a customer reply that waited or the founder priority that was displaced. Keep active answer time separate from waiting time.
- 05
Whether it repeats
Mark the moment as isolated, tied to a temporary event or recognisably recurring. Add a second example when you have one. A single frustrating request is weak evidence of a system problem.
Include a planned review when work routinely cannot proceed without it. Leave out a conversation where the owner gathered your view and still made the call. If you already completed the two-week Founder Dependency Trace, use ten representative rows from that record instead of collecting the same evidence again.
Three piles are enough
Put each row into one of three piles. Deliberate founder work includes strategy, material commitments and decisions whose downside is hard to reverse. Keep those checkpoints visible and planned. Amazon's one-way and two-way door distinction is a useful prompt here. In this audit, treat a contained, reversible decision as a lower-risk place for a new owner to learn.
Temporary exceptions have a credible end condition: a vacancy is being covered, a new manager is calibrating, a launch is unusually sensitive or an incident needs senior coordination. Write down what ends the exception and when you will check. Otherwise a temporary rescue can quietly become the normal route.
Routine dependency is the pile to examine first. The work is ordinary, the pattern has happened before, somebody is already close to the evidence, and progress still waits for your permission, memory or intervention. If this pile is hard to distinguish, keep collecting work evidence before changing the route.
Name the input the work was missing
The missing input tells you more than the department. A pricing exception may be waiting for authority. A client update may be waiting because the commercial promise still lives in your memory. Name that gap instead of labelling the whole sales or delivery function a problem.
Ask the closest owner two questions: 'What outcome do you own?' and 'What can you decide without me?' The HSE standard on role clarity stresses clear responsibilities and requirements. GitLab's DRI practice shows one way to let a named owner gather input while retaining the final call. The useful test is simple: can your closest owner decide, or can they only prepare work for you?
The CIPD evidence review on knowledge work pairs autonomy and devolved decisions with information, skills and practical support. Record what the owner was missing before you call the problem a lack of initiative.
Read the pattern without inventing a score
This audit does not use a validated threshold, so seven returns should not be labelled healthy and eight critical. A total would also hide the difference between a frequent, reversible approval and one rare decision with serious consequences.
Read for recurrence. Look for the same kind of work returning from different people, a five-minute answer creating hours of waiting, or a named owner who still lacks the normal call. Your rewrites may expose a quality standard that nobody could see before the work was done. Those patterns are stronger evidence than a broad self-rating.
Check where the work goes when it stops reaching you. It may have pooled inside a reliable manager who now catches every exception and connects every team. Use the overloaded-manager diagnostic to inspect whether the decision boundary changed or the queue simply moved.
Change one route next week
Choose one row from the routine-dependency pile. A good first test repeats, can be reversed and already has a plausible owner close to the evidence. The dependency causing the most pain may be a poor starting point if a mistake would be hard to contain.
Before the next occurrence, agree the owner, the normal boundary and the exception that brings you back in. Put the missing context or standard beside the work. Set one review date. Unless that exception occurs, let the owner move the work and review the evidence afterwards.
If the missing piece is decision authority, use the founder decision map to separate what the team decides, what needs a heads-up and what still needs approval. Keep the first test narrower than a whole function. A customer update route or one bounded pricing exception gives you a contained place to learn.
At the review, compare founder touches, elapsed wait, rework and the commitment you were protecting. When the work comes back, add the condition your record exposed and tighten the scope before deciding the transfer failed. If it met the agreed boundary and you reclaimed it because you preferred a different method, use the manager delegation diagnostic to inspect the habit of taking work back.
Pick one routine row now. Write down who owns it, the normal boundary, the exception that brings you back in and the date you will review it. That is enough for the first test.