Out of My Head · Lesson 26 of 33
Delegate outcomes not methods
The video for this lesson is being recorded. The whole lesson is written out below.
Read the lesson0% complete
Hand it over: a team that acts without asking you
Delegate outcomes not methods
Jay WestOut of My Head · 3 min read
By the end: One delegation rewritten as an outcome with constraints, instead of a method to follow.
The idea
Specify the result you want, not the exact steps to get there. This preserves autonomy and invites better solutions.
But there is a second failure mode that clarity alone does not prevent: specifying the wrong layer. You can be extraordinarily precise about every step of a process and still produce a brittle delegation that breaks the moment conditions change, suppresses the delegate's intelligence, and makes you the permanent bottleneck in your own system.
An example
You need a weekly report summarizing project health. You could delegate it by writing a twelve-step procedure: open this spreadsheet, copy these cells, paste into this template, format the header, check the conditional formatting, export to PDF, email to these people by 4 PM Friday. Or you could delegate it by saying: I need a one-page project health summary delivered to the team by end of day Friday, covering schedule status, budget variance, and top three risks. The first version specifies method. The second specifies outcome. The method-based delegation breaks if the spreadsheet changes, if the template moves, if the team switches tools. The outcome-based delegation survives all of those changes because the delegate can adapt their approach while preserving the result. More importantly, the delegate might discover a better method than your twelve steps — an automated dashboard, a Slack summary, a five-minute video walkthrough — because you left the how open.
Where it goes wrong
Specifying outcomes so vaguely that the delegate has no useful guidance. 'Make the report good' is not outcome delegation — it is abdication. Outcome delegation requires precision about the result: what the deliverable contains, who it serves, when it is due, what quality threshold it must meet, and what constraints are non-negotiable. The failure is not in giving too much freedom about method. The failure is in giving too little clarity about the destination. Vague outcomes produce worse results than detailed methods, because at least detailed methods produce predictable outputs. The goal is precise outcomes with open methods — not vague outcomes with no methods.
Make it stick
Take the outcome-based delegation you wrote in the exercise and add one element: a verification checkpoint. Define a specific moment — midpoint, first draft, or initial output — where you will check whether the delegation is tracking toward the specified outcome. Do not check the method. Check the trajectory of the result.
Do this now
Choose one task you currently delegate — to a person, a tool, or an AI agent. Write down how you currently specify that delegation. Separate your specification into two columns: outcome statements (what the result must achieve) and method statements (how to achieve it). Now rewrite the delegation using only the outcome column. Add constraints only where they are genuinely necessary — budget limits, legal requirements, format compatibility, deadlines. Remove every method statement that is actually a preference rather than a requirement. Test the rewritten delegation this week and observe whether the result meets your needs. If it does, the method statements were unnecessary overhead. If it does not, identify which missing constraint caused the failure and add that specific constraint back — as an outcome constraint, not a method prescription.
This step is drawn from one lesson of the full curriculum. Read the full lesson on howtothink.ai (L-0526)
Lesson 26 of 33
Next: lesson 27 →