Delegate, then automate. Never the other way
If you're over 45 and serious about putting Claude to work, start with one rule: never automate anything you couldn't hand to a sharp junior with a one-page brief. Delegation is what exposes the real job. Automation just repeats whatever job you've defined, right or wrong, and does it faster than you can correct it.
I learned this the expensive way. A couple of years ago I tried to automate my proposal drafts before I'd ever written down how I actually wrote one. Three weeks and about $200 in API credits later, my "system" produced drafts I rewrote from scratch every time. The automation wasn't broken. The job was undefined. I'd skipped the step where you find out what the work actually is.
Why does automating first backfire so reliably?
Because automation freezes assumptions you haven't surfaced yet, and you only surface them when someone follows your instructions and hands back something that makes you wince. Claude is ruthless this way. It behaves like a fast, literal, slightly over-confident new hire who does exactly what you wrote, not what you meant. The gap between those two is your real process, and you can't see it from the inside.
Watch an experienced consultant hand off "summarize this client call" for the first time. The summary comes back technically accurate and practically useless. No flag on the budget comment that was the whole point of the meeting. No note that the CFO went quiet when timelines came up. The consultant knew those mattered. They never said so, because they're running on twenty years of pattern recognition firing automatically. That tacit layer is the asset. Delegation is the only reliable way to pull it into words. Automation is just what you do once the words exist.
This is where deep experience turns into an unfair advantage. A 28-year-old analyst can wire up Zapier faster than you ever will. What they can't do yet is look at a client email and see the three sentences that matter for risk, politics, and scope. You can. Your moat isn't speed, it's that you know what "acceptable" means in your field, and where a small error becomes litigation or a lost relationship. Delegation forces you to write that standard down.
The four-step sequence to safe automation
Here's the order I wish I'd followed from the start. The whole discipline is doing the steps in sequence and not skipping to the fun one.
- 1. Delegate to a human-equivalent. Hand the task to a person, or to Claude as if it were a person, with a written brief. Not a vibe, not "you know what I mean," but a concrete instruction. If you can't get it onto one page, you're not ready to automate. You may not be ready to delegate.
- 2. Watch it fail, and capture every fix. The first three or four runs will be wrong in ways that sting. Don't silently patch them in your head. Turn each correction into a rule: "always flag anything that touches scope," "never use the client's internal codename in external copy," "put risks, decisions, and open questions in separate sections." Those rules are your real spec.
- 3. Stabilize against reality. Run it another five to ten times, tightening rules until the output is something you'd send after a light edit. When you're nodding more than rewriting, the process is stable enough to encode.
- 4. Automate the boring slice, not the whole task. Move the stable core into a Claude Project with custom instructions, a saved prompt, or a scripted step. Keep the high-judgment bits explicitly human. The goal isn't "no human touches this." It's "no human repeats the same low-level work twice."
Most people do step 4 first and wonder why the machine keeps embarrassing them. You're not building a robot. You're writing down what you know, and the robot is a side effect.
The one-page brief test
Before I let myself automate anything, I run one test: could I write a one-page brief a competent stranger could follow to do this task at a B+ level, on time, with their name on it? If yes, it's a candidate: I delegate to Claude, treat the first five to ten runs as training to refine the brief, then automate the stable piece. If no, the task isn't ready, and one real handoff to Claude becomes the mirror that shows me the missing rules. This test has pulled me out of at least a dozen automation rabbit holes before I fell in.
What this looks like with Claude, in practice
Say you're a fractional CFO in your fifties, and you spend two hours a week turning messy bookkeeping exports into a one-page cash position summary for each client. Tedious, repeatable, high-stakes. The temptation is to wire up an automated pipeline on day one. Don't. Open Claude and treat it as a junior hire you trust but don't know yet. Paste last month's sanitized export and brief it the way you'd brief a real analyst: "Produce a one-page cash summary in memo form. Show current cash, runway in months, and the top expense categories as a percent of monthly burn. Flag anything where runway drops below four months. Call out any single expense over 15% of burn. Don't speculate on causes. End with three to five questions I should ask the client."
The first output misses things. Maybe it buries a receivables problem. You correct it in writing: "Also flag receivables aged past 60 days, and list the top five debtors." That correction goes into the Project instructions. By the fourth or fifth client, you've written, almost by accident, a complete specification of a job that used to live only in your head. The recurring two-hour task now runs in fifteen minutes, and it runs correctly, because you delegated long enough to learn what correct meant.
| Task readiness | Delegate first (to a person or Claude) | Safe to automate now |
|---|---|---|
| Can you write a one-page brief? | No; you'll discover the rules by correcting outputs | Yes; the rules are explicit and stable |
| How many edge cases surprise you? | Still finding new ones each run | Corrections have stopped being new |
| Cost of a silent error? | High: client trust, legal, money | Low, or fully caught by a review step |
| Examples | A sensitive client email; a first-pass strategy memo | Reformatting exports; meeting-notes cleanup; a first-draft FAQ |
Isn't this just "document your processes" with extra steps?
No, and the difference matters a lot. Process documentation is something you sit down to write in the abstract, usually badly, and never update. Delegation produces the same document as a byproduct of getting real work done. You don't write the spec and then test it; you generate the spec by running the task and capturing every correction. The result is battle-tested because it was forged on actual outputs, not imagined at a whiteboard. One is a chore you avoid. The other is just careful handoff.
There's a second payoff: delegation tells you what not to automate. Some tasks resist every attempt to write them down. After five rounds of correction you're still rewriting half the output, and that's the work telling you it's judgment-dense and belongs in your hands. That's not a failure. Knowing which 20% of your work must stay manual is worth more than automating the other 80% badly.
So the next time you feel the itch to build a system, resist it for one week. Hand the task to Claude as if it were a new hire who's smart but takes you literally, and correct it in writing every single time. By Friday you'll have one of two things: a clean specification ready to automate, or proof the task belongs to you. Both are wins. Building the machine first only ever gives you a faster way to be wrong.