The most expensive word in delegation is "better"
"Make it better." "Clean this up." "Handle the customer situation." "Write something compelling." "Fix the onboarding flow."
These are not delegations. They are wishes dressed in imperative grammar. Every one of them transfers a task without transferring the information needed to complete it. The delegate — whether a person, a system, or an AI — receives an action without an outcome, effort without direction, authority without criteria.
And then the delegator is surprised when the result is wrong.
This is not a failure of execution. It is a failure of specification. The delegate did exactly what was asked: they interpreted a vague instruction using their own judgment, their own assumptions, their own definition of "better." The problem is that their definition and yours were never the same. They could not have been the same, because you never made yours explicit.
Vague delegation does not save time. It borrows against future time — the rework, the correction, the difficult conversation where both parties feel they did their job correctly and neither is wrong.
What specification actually means
Specification is the act of making the implicit explicit. It is the process of translating what exists in your head — the desired outcome, the constraints, the quality bar — into language precise enough that someone with no access to your thoughts can produce what you need.
This is harder than it sounds, because most people do not realize how much of their intent remains unspoken. Research on the illusion of transparency (Gilovich, Savitsky, and Medvek, 1998) demonstrates that people systematically overestimate how well others understand their internal states. You feel like your intention is obvious. It is not. The clarity lives in your head, and your head is not part of the deliverable.
The field of requirements engineering has studied this problem for decades. A study published in the journal Science of Computer Programming (Femmer et al., 2020) found that natural-language requirements specifications are overwhelmingly susceptible to ambiguity, and that these ambiguities propagate downstream into design, implementation, and testing. Industry analyses have attributed up to 82% of software rework to requirements-level errors — not coding bugs, but specification failures. The developer built what was asked for. What was asked for was not what was needed.
The same dynamic plays out in every delegation context. The problem is never that the delegate cannot execute. The problem is that the delegator has not finished thinking.
Goal specificity: 35 years of evidence
Edwin Locke and Gary Latham's goal-setting theory, developed across 35 years and hundreds of empirical studies, produced one of the most robust findings in organizational psychology: specific, difficult goals consistently produce higher performance than vague goals like "do your best."
Their meta-analyses found effect sizes ranging from 0.42 to 0.80 — substantial by any standard. The mechanism is straightforward: specific goals direct attention toward goal-relevant activities and away from goal-irrelevant ones. They reduce the variation in performance by eliminating ambiguity about what "done" looks like. When someone knows the target is "reduce response time from 48 hours to 12 hours," they allocate effort differently than when the target is "improve response time."
Critically, Locke and Latham identified that goal specificity works through four channels:
- Direction — attention focuses on what matters
- Effort — intensity scales to the difficulty of the specific target
- Persistence — specific goals provide a clear gap between current state and desired state, sustaining motivation
- Strategy — when the target is clear, people search for and apply task-relevant knowledge
This is what specification does for delegation. A well-specified delegation activates all four channels in the delegate. A vague delegation activates none of them — the delegate must first invent the goal before they can pursue it, and the goal they invent is unlikely to match yours.
George T. Doran formalized this into the SMART framework in 1981 — Specific, Measurable, Assignable, Realistic, Time-bound. The framework has limitations (it does not address how to implement, and the research support for the acronym as a whole is mixed), but its core insight endures: every unspecified dimension of a goal is a dimension where the delegate will substitute their own assumptions for yours.
Commander's intent: specification without micromanagement
There is a critical distinction between specifying the outcome and specifying the method. The Prussian military tradition of Auftragstaktik — mission-type tactics — illustrates this distinction with life-or-death stakes.
Developed in the early 19th century after Prussia's devastating defeats by Napoleon, Auftragstaktik gives subordinate commanders a clearly defined objective, a timeframe, and the forces available. It does not tell them how to achieve the objective. The subordinate decides on methods independently, adapting to conditions on the ground that the senior commander cannot see.
The modern NATO doctrine of "mission command" preserves this structure. The commander's intent statement specifies: the purpose of the operation, the key tasks that must be accomplished, and the desired end state. Everything else is left to the judgment of the person closest to the action.
This is not vagueness. It is the opposite of vagueness. The outcome specification is extremely precise — "seize and hold the bridge crossing by 0600, denying enemy use of the northern route." The method specification is deliberately absent — because the commander knows that conditions will change, and the person on the ground needs freedom to adapt.
The lesson for everyday delegation: specify the destination with maximum precision. Specify the route with minimum prescription. This is exactly the boundary between this lesson and the next (L-0526: Delegate outcomes, not methods). Clear specification is the prerequisite. Outcome-level delegation is the application.
The principal-agent problem: why vagueness is expensive
Economics formalizes the delegation challenge as the principal-agent problem. Whenever one party (the principal) delegates authority to another (the agent), three structural issues arise:
- Information asymmetry — the agent typically knows more about their own actions and capabilities than the principal can observe
- Interest divergence — the agent's incentives may not perfectly align with the principal's goals
- Verification difficulty — the principal cannot always confirm whether the agent acted optimally
Clear specification mitigates all three. When the outcome is precisely defined, information asymmetry matters less — the principal does not need to monitor the process if they can evaluate the result. When success criteria are explicit, interest divergence becomes visible — the agent knows exactly what "good" means, reducing the space for self-serving interpretation. When the specification includes measurable criteria, verification becomes straightforward.
Vague specification amplifies all three problems. The agent fills the specification gap with their own interpretation, which may reflect their convenience rather than your need. You cannot evaluate the result because you never defined what success looks like. And the ensuing disagreement — "that's not what I wanted" / "that's not what you said" — consumes more time and trust than the original task would have taken.
Prompt engineering is specification made literal
If you need proof that specification quality determines delegation quality, work with an AI system for a week. Large language models are, in a sense, the purest delegation partners: they have no ego, no competing priorities, no passive-aggressive resistance to unclear instructions. They simply do what you specify. And if your specification is vague, the output is vague. The feedback loop is immediate and unforgiving.
OpenAI's prompt engineering guidelines state the principle explicitly: provide clear instructions with specific details — the desired length, format, style, level of detail, and constraints. The less the model has to guess about your intent, the more likely the output matches your need.
The parallel to human delegation is exact. When you tell a colleague "write something compelling about the product launch," you are providing the same quality of specification as a one-line prompt to an AI. Both will produce something. Neither will produce what you actually needed, because you never said what that was.
Prompt engineering teaches a discipline that transfers directly to all delegation: the quality of the output is bounded by the quality of the input specification. This is not an AI limitation. It is an information-theoretic constraint. Claude Shannon's foundational model of communication (1948) identifies noise as any signal degradation between sender and receiver. Vague specification is self-inflicted noise — you are degrading your own signal before it even reaches the channel.
The people who get the best results from AI are not the ones who understand the technology best. They are the ones who have learned to specify clearly — to articulate what they want, what they do not want, what "done" looks like, and what constraints apply. This is the same skill that produces effective delegation to humans, to systems, and to processes.
The five-part specification framework
Every effective delegation specification answers five questions:
1. Outcome — What does "done" look like? Not the activity. The result. Not "research competitors" but "a comparison table of the five largest competitors' pricing, features, and market positioning, with a recommendation for our pricing tier." The outcome must be concrete enough that two reasonable people would agree on whether it has been achieved.
2. Constraints — What must not happen? Every delegation operates within boundaries. Budget limits, brand guidelines, technical requirements, ethical lines, dependencies on other work. Unstated constraints are invisible fences — the delegate walks through them without knowing they existed, and you blame them for trespassing.
3. Success criteria — How will you evaluate the result? This is where "better" becomes a number, a comparison, or a verifiable condition. "Increase form conversion from 12% to 20%." "Pass all integration tests." "Receive approval from the legal team." If you cannot state how you will evaluate the result, you have not finished specifying it.
4. Resources — What is available? Budget, tools, time, access to people, existing materials, authority to make sub-decisions. The delegate needs to know what they can use, not just what they must produce. Withholding resource information is a common specification failure — the delegate either under-delivers because they did not know resources were available, or over-commits because they did not know resources were constrained.
5. Timeline — When is it needed, and are there intermediate checkpoints? A deadline without checkpoints is a single point of failure. Intermediate checkpoints — "show me a draft outline by Wednesday, full draft by Friday, final by next Tuesday" — create opportunities to catch specification failures early, before full effort has been invested in the wrong direction.
The specification test
Here is a simple test for whether your specification is complete: could a competent stranger — someone with the right skills but zero context about your preferences, history, or unstated assumptions — produce an acceptable result from your specification alone?
If the answer is no, the missing information is still in your head. And every piece of information that remains in your head is a piece of information that the delegate will replace with their own assumption.
This does not mean specifications must be long. The commander's intent statement — "seize the bridge by 0600, deny enemy the northern route" — is two clauses. But it contains an outcome, a constraint (timing), and an implicit success criterion (the bridge is held, the route is denied). Brevity and precision are not enemies. Brevity and vagueness are.
What this makes possible
When specification becomes a deliberate practice rather than an afterthought, three things change:
Delegation scales. You can delegate to more people, more systems, and more AI tools simultaneously, because each delegation carries its own context. You are no longer the bottleneck who must be available to answer "what did you mean by...?" for every task in flight.
Trust builds faster. When the specification is clear and the delegate meets it, trust is earned on evidence rather than assumed on faith. When the specification is vague and the result disappoints, you do not know whether the delegate failed or your communication failed — and that ambiguity corrodes trust in both directions.
Your own thinking sharpens. The hardest part of writing a specification is often discovering that you do not yet know what you want. The specification forces the same kind of externalization discussed in Phase 1 of this curriculum — it makes your thinking visible, precise, and inspectable. If you cannot specify it, you have not thought it through. The specification is the proof.
This is the foundation for the next lesson. Once you can specify what you want with precision, the next question becomes: should you also specify how? The answer, almost always, is no — and that is the subject of L-0526: Delegate outcomes, not methods. But you cannot delegate outcomes until you can articulate them. Specification comes first.