Delegate, automate, or delete: the triage

Every task eating founder time has three exits: delete it, automate it, or delegate it — and the order matters. Delete what does not need doing, automate what follows rules, delegate only what genuinely needs human judgement. Most founders run the triage backwards: they hire first, buying a salary for work that software should do and half of which should not be done at all.

Why is the order delete, automate, delegate?

Because each gate is cheaper than the next. Deletion costs nothing and pays forever. Automation costs a build once and pennies to run. Delegation costs a salary every month, plus management, plus the risk the person leaves. Running the gates in cost order means the expensive option only catches what the cheap options could not.

The backwards version is common because delegation feels like leadership and deletion feels like admitting the work was pointless. But a founder who delegates an unnecessary report has not saved time — they have institutionalised waste and added payroll to it. This is the trap at the heart of The Founder-as-Bottleneck Report: owner-dependence is not solved by moving work around; it is solved by redesigning what work exists and what runs it.

One precondition. You can only triage work you can see, which means the process has to be written down first — the extraction method is in Documenting the sales process you already have. A task list built from memory misses exactly the habitual work that most deserves deletion.

What qualifies a task for deletion?

Anything whose absence nobody would notice within a month. Reliable candidates: reports nobody reads or acts on, meetings that exist because they recur, approvals where you have not said no in a year, manual data entry duplicating what another tool already holds, and "keeping an eye on" dashboards with no decision attached. The test is blunt: what decision changes because this task happened? No decision, no task.

Founders typically find this gate removes a meaningful slice of their week — commonly the work they were about to hire for. Delete before you price up the alternatives, or you will automate and delegate waste.

What makes a task automatable?

Rules. If you can write the task as when-X-then-Y statements with no gaps, software can run it. When a form is submitted, then the lead is created in the CRM and a booking link goes out. When a proposal has had no reply for three days, then follow-up one is sent. When an invoice hits day thirty, then a reminder goes to the client and a flag goes to you.

Follow-up is the highest-value automation target in most service firms, because it is pure rule-following that humans reliably drop — most firms stop at two touches while deals typically need five or more. A structured system like The 90-Day Follow-Up Framework exists precisely because this category of work should never depend on anyone remembering.

Signals a task belongs here: it happens the same way every time, the inputs are digital, exceptions are rare and definable, and doing it bores you. Boredom is diagnostic — it usually means the judgement content is zero.

What should stay human?

Work where the rules run out: closing complex deals, scoping unusual projects, handling an unhappy client, judgement calls on strategy and hiring. Delegation is the right tool here — but delegate decisions with boundaries, not tasks with scripts. A script-following human is an expensive, error-prone automation; if you find yourself writing one, you are at the wrong gate.

Good delegation hands over a defined outcome, a budget of authority ("discounts up to 10% without asking"), and a number that shows whether it is working. That requires the same documentation as automation does — which is why firms that skip the writing stage end up with neither.

How do you run the triage in practice?

The mechanism, one week end to end:

1. Log everything for five working days. Every task, in the moment, with rough minutes. Memory flatters; the log does not.
2. Mark each entry D1, D2, D3, or K. Delete, automate (D2), delegate (D3), or keep — "keep" is reserved for judgement work only the founder can do.
3. When a task has no decision downstream, then it is D1. Stop doing it this week and watch for complaints. Silence is confirmation.
4. When a task is fully rule-describable, then it is D2. Queue it for a build, highest hours-saved first.
5. When a task needs judgement but not your judgement, then it is D3. Write the outcome, the authority boundary, and the metric before naming a person.
6. Re-run the log quarterly. Deleted work regrows; new rule-work accumulates. For a fuller measure of how much of the business still routes through you, use the owner-dependence diagnostic.

Most founders who run this honestly find the hire they had planned shrinks to a part-time role — or disappears into a build.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.