Delegate The Goal, Not The Steps

The best way to reduce how much babysitting a piece of work needs is to stop specifying the steps and start specifying the outcome. I've watched this play out again and again lately, most visibly with the new generation of AI coding tools, but the pattern is older than any of them. Tell a capable agent exactly what to do, in what order, and you've bought yourself a brittle plan that breaks the moment reality diverges from it, plus the ongoing job of noticing when that happens. Tell it what "done" looks like and let it work out the route, and you get something that can actually absorb the mess along the way.

I noticed this properly while watching engineers use the newer breed of AI coding agents. Give one a numbered list of steps and it will follow the list even after the third step turns out to be wrong, because the list is what it was told to trust. Give the same agent a goal, a bit of context, and the constraints that matter, and it starts behaving less like a script executor and more like a junior engineer who can tell when something isn't working and adjust. The interesting part isn't that the AI got smarter. It's that removing the step-by-step instructions removed the thing that was forcing it to keep executing a plan past its use-by date.

That's not really an AI story. It's a delegation story, and it's one I think we've half-forgotten in software teams because ticket systems reward the opposite habit. A ticket with five acceptance criteria and an implied sequence feels thorough. It feels like you've done the manager's job of thinking it through so the person doing the work doesn't have to. But specificity at that level is a trade, not a gift. You're trading the executor's judgement for your own certainty about a path you worked out before anyone touched the code, back when you understood the problem the least. Every time the real system disagrees with your plan, the person doing the work faces a choice nobody wants: follow the ticket and ship something that's technically compliant and practically wrong, or quietly go off-script and hope nobody minds that the delivered thing doesn't match what was written down.

I've made this mistake plenty of times myself, usually with the best intentions. A junior developer joins a stream of work, and the instinct is to protect them by writing very precise instructions, because precise instructions feel like care. What actually helps more, in my experience, is being precise about the destination and the guardrails, and vague about the route. What outcome are we actually trying to produce. What would make this wrong even if it technically works. Where are the edges I don't want you anywhere near. Everything else is theirs to solve, and the ones who are good at the job will usually solve it in a way I wouldn't have thought of, because they're looking at the actual system while I was looking at a mental model of it from a day earlier.

The reason goal-based delegation needs less handholding isn't magic, and it isn't really about trust in the warm, fuzzy sense either. It's that a stated goal gives the person or system doing the work a test they can run against their own output at every step, not just at the end. A list of instructions only tells you whether you followed the list. A goal tells you whether what you built actually does the thing. That self-check is what reduces the need for someone else to intervene, because the executor can catch their own drift instead of waiting for a reviewer to catch it for them. The oversight doesn't disappear. It moves from "did you follow the steps" to "does this achieve the goal," which is a cheaper question to keep asking and a much better one to be asked.

None of this means throwing away structure. Constraints still matter enormously, arguably more than they do in a step-by-step brief, because constraints are exactly the information a goal alone won't communicate. Don't touch the billing table. This has to keep working offline. The response time budget is fixed. Those aren't steps, they're the shape of the box the solution has to fit inside, and a good goal-based brief spends its words there rather than on sequencing. The mistake isn't writing detailed instructions. It's writing detailed instructions about the wrong thing — the order of operations instead of the boundaries of acceptable outcomes.

There's a commercial angle to this too, which is easy to miss when the conversation stays theoretical. Step-by-step instructions cost the instruction-writer time up front and cost everyone downstream time whenever reality doesn't match the plan, because someone then has to notice the mismatch, escalate it, and wait for a revised instruction. Goal-based delegation costs a bit more thinking at the start, about what genuinely matters and what doesn't, and then buys back all of that downstream friction. For a team already stretched thin, that trade is close to free money. It's also, not coincidentally, the same reason experienced managers write shorter briefs than nervous ones. They've learned that clarity about the destination is worth more than certainty about the path, and that the people and systems capable of finding a good path are usually the ones you least need to walk beside.

The test I use now, whether I'm writing a ticket, briefing a contractor, or prompting an AI agent, is simple. If I can state the goal and the constraints in a few sentences and feel comfortable walking away, I've probably delegated well. If I find myself writing out the sequence of steps instead, it's usually because I don't yet trust the goal to be clear enough on its own, and that's worth fixing before the instructions go out, not after the work comes back wrong.