What does it mean that delegate outcomes not methods?

Specify the result you want, not the exact steps to get there. This preserves autonomy and invites better solutions.

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.

Try this: 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.