No preamble and nothing held back to make you book a call. If an answer here settles the question for you, that is a good outcome.
Because the task was delegated and the judgement that makes the task good was not.
The client history you remember, the standard you recognise instinctively, the commercial judgement that tells you when the obvious answer is wrong — those usually live with you and were never written down. Capable people then have no reliable way to use them, so the work returns for your correction or approval.
The fix is not more delegation or better documentation. It is identifying which judgement the work actually depends on, and building it into how the work is done.
Ask what the role is being hired to absorb. If the answer is mostly judgement that has never been written down, a hire moves the bottleneck rather than removing it — and it now costs a salary.
That is not an argument against hiring. It is an argument for knowing, before the role is filled, exactly what it is meant to take off you. Firms that do that work first usually hire a smaller role, or a different one, and the person they hire is effective in weeks rather than months.
Do not try. A complete manual is unfinishable, and nobody opens it.
Pick three recurring jobs that keep coming back to you. For each one, capture only what a capable person is actually missing: the context they cannot see, the standard they cannot recognise yet, the decision they are not sure they are allowed to make.
That is usually a page per job, not a chapter. The test is not whether it is comprehensive. It is whether the work goes through without you.
Because being good at the work and being able to finish it without you are different things.
The team handles the normal cases. Then something slightly unusual happens — a client throws a curveball, a decision does not quite fit the rules, a proposal needs judgement rather than formatting. Nobody is quite comfortable calling it finished until you have looked.
That is not a capability problem. It is a decision-rights and context problem, and it is solvable.
AI use is individuals working faster. AI capacity is the organisation becoming more capable.
A business can give everyone ChatGPT, Claude or Copilot and still have exactly the same organisational problem, only faster. The output looks competent, and then someone senior corrects the assumptions, adds the missing context and decides whether it is actually right.
The honest test is one question: did the organisation become more capable, or did one person simply get faster?
Because tools change how work is done, not what the work depends on.
If a task needed your context before the tool arrived, it still needs your context. The draft appears faster and then waits for you. Volume goes up, your checking goes up with it, and the constraint has not moved.
What changes it is redesigning the work itself: what context it carries, what standard applies, who owns the decision, and what genuinely needs to escalate. The AI then has a defined role inside work that has been designed. It is not the design.
By what the work depends on, not by what is technically possible.
Repetitive work with a clear standard and a low cost of error is a good candidate. Work that depends on reading a person, holding a relationship, or making a judgement the business would not want defended by a machine is not — and putting AI there converts an asset into a risk.
The useful question is not "can this be automated". It is "what would have to be true for this to run without me, and do I want that to be true".
Three recurring jobs become firm-owned in four weeks.
Each job moves through four stages. Capture: the hidden context, examples, standards and judgement, out of the founder's head and into usable form. Design: ownership, decision rights, AI's role, human checks and what genuinely needs escalation. Test: run it on real work, find what breaks, fix it, test again. Transfer: ownership where it belongs, with a 30-day review that tells you it held.
The founder and one senior team member take part. Six firms maximum per cohort.
No, though it uses process work.
A process map describes the steps. It rarely captures why a step is done a particular way, what a good outcome looks like, who is allowed to decide, or what should stop the work entirely. Those are the parts that keep routing back to the founder, and they are usually absent from the map.
The work is transferring the judgement, not drawing the sequence.
Fifteen practical questions, about five minutes, covering how judgement, decisions, cross-functional work, operating systems and AI capacity move through your business.
You get your Capacity Pattern, what I would investigate first, and one practical place to start. The result is immediate and no email address is required to see it.
It is not a 47-page report. It is a clearer view of where to look.
In Formula 1 the driver is the visible performer. The race engineer reads what is happening across the car, the conditions, the strategy and the wider team, then helps turn those signals into better decisions and a better setup.
They do not take the wheel. They help the whole system perform around the person driving it.
That is the useful part of the metaphor for a founder-led business.
Early-stage businesses without an existing team — there is nothing to transfer judgement to yet.
Firms looking for a software recommendation. The tool is the last decision, not the first.
And any business where the founder does not actually want the work to move. That is a legitimate choice, but nothing here will help, and I would rather say so at the start than three months in.
Diagnose identifies where capability is getting stuck. Build transfers specific recurring work into firm ownership. Implement redesigns and builds more complex workflows, with the AI underneath the redesign rather than over it. Embed addresses broader leadership, decision-making and operating-system constraints through an initial 90-day cycle.
They are four depths of intervention, not four products. You do not have to choose one before we speak — working out which the problem actually needs is part of the job.
By starting with the work and the constraint underneath it, rather than with a product or a technology.
Most of the time the presenting problem is not the constraint. A slow proposal process is rarely a proposal-writing problem; it is usually a standards problem, or a decision-rights problem, or one person being the only reliable source of context. The depth of intervention follows from what is actually in the way, which is why I would rather look first than quote first.
An initial 90-day organisational-engineering cycle with the founder and leadership team, focused on one to three connected operating constraints.
It is for when the problem extends across decision rights, accountability, operating rhythm and execution rather than sitting inside one workflow. I read the signals, identify where performance is being lost, and work on the system while the business continues to run. At day 90: stop, narrow, or agree another cycle.
It is not a fractional COO. The point is not to become a permanent dependency — ownership stays inside the business.
If what you are dealing with is not on this page, describe it and I will tell you whether it is something I work on.