Clarify a vague assignment by offering a draft interpretation. State the outcome you think is required and ask your manager to correct the gaps before you commit to a deliverable.
What should you say when an assignment is unclear?
Use the CLEAR brief: Completion, Level, Exclusions, Authority, Review.
"My understanding is that completion means a five-slide recommendation for Friday's leadership review. It should include customer impact and cost, while detailed implementation stays out of scope. I can recommend an option, and you make the final decision. Could we review the outline Wednesday?"
That statement is easier to answer than "What do you want?" The manager can correct one element instead of rebuilding the task from nothing.
HSE's Management Standards on role clarity ask organizations to make responsibilities clear and provide a way to raise uncertainty. A communication framework cannot solve every organizational design problem, but it can expose the specific ambiguity before work accumulates around it.
Which questions create useful clarity?
Ask questions that change what you will do. Five practical questions map to CLEAR:
- Completion: "What decision or deliverable should exist when this is done?"
- Level: "What does good enough look like for this version?"
- Exclusions: "Which related work is outside the scope?"
- Authority: "What can I decide, and what requires approval?"
- Review: "When should I show you the first version?"
Do not fire all five as a questionnaire when only one is missing. Listen to the assignment, identify the highest-cost uncertainty, and start there.
If the request is "Improve our onboarding," the highest-cost question is likely the target outcome. If the request is "Send the client an updated timeline," authority and deadline may matter most.
How do you ask for help without sounding unprepared?
Show the work already done and name the exact blockage. A useful help request includes your objective, attempt, obstacle, and requested input.
"I am trying to estimate migration time. I mapped the three services and checked last quarter's deployment notes. I cannot tell whether the legacy database needs a separate validation pass. Can you confirm that assumption or point me to the owner?"
This is the OAOR help request: Objective, Attempt, Obstacle, Request. It respects the other person's time and gives them something concrete to answer.
When you truly have no starting point, say so directly:
"This is my first procurement review. Could you show me one completed example and the approval sequence? I will draft the new one from that."
Pretending certainty can create expensive rework. A bounded request for orientation is a professional response to a new task.
What if your manager stays vague?
Convert the available information into written assumptions and create a decision point.
"I will proceed with a short recommendation for the product lead, using retention as the primary metric, and send an outline Wednesday. Please correct any of those assumptions by Tuesday afternoon."
This approach prevents indefinite waiting, but use judgment. High-risk financial, legal, security, safety, or customer commitments may require explicit approval rather than an assumption deadline.
If priorities conflict, ask for the tradeoff:
"The new analysis and Friday's launch plan each require most of Thursday. Which outcome should be protected?"
If feedback changes repeatedly, compare versions neutrally:
"Last week the goal was a technical recommendation. Today I hear that the audience needs a budget decision. Should I replace the architecture section with cost scenarios?"
A ten-minute clarity drill
Take one vague task from your current week. Explain it aloud in 30 seconds using CLEAR. Any field you cannot say is a question to take back to the manager.
Then practice the OAOR help request. Keep the "attempt" section to two actions and the "request" to one answerable ask. Recording matters because written clarity can disappear in a long spoken preamble.
Use this rubric:
| Element | Clear version |
|---|---|
| Outcome | Names a deliverable or decision |
| Standard | Gives audience, depth, or example |
| Scope | States one exclusion |
| Ownership | Separates recommendation from approval |
| Timing | Includes deadline and review point |
For a related way to clarify live discussion, read meeting answer structure.
Limits of clarification
A well-phrased question cannot create strategy where leadership has not made a decision. It also cannot fix chronic understaffing or contradictory authority. When ambiguity persists, document assumptions, risks, and decisions without using the recap as a threat.
Clarify a request before the meeting moves on
When a request arrives in a meeting, ask for the missing decision detail before accepting the work. In this fictional exchange, a manager says, "Make the onboarding analysis more strategic." A useful response is: "Which decision should the analysis support: where customers leave, or which fix to fund?" Once that is clear, confirm audience, deadline and completion standard.
Close with a read-back: "I will compare the two funding options for Friday's review. I will include the cost range and one risk for each, and leave the full interview notes in the appendix. Is that the right scope?" If the manager cannot yet define the outcome, agree on a small exploratory draft and a review point. Rehearse the question and read-back without turning clarification into a long list of demands.
Frequently asked questions
Will asking questions make me look incompetent?
Specific questions after a reasonable attempt usually signal judgment. Repeatedly asking for information already documented can create a different impression, so show what you checked.
Should I ask in writing or in a meeting?
Use a live conversation for complex ambiguity and a written recap for the final agreement. A simple deadline question can stay in chat.
What if the priority changes after I begin?
Restate the new outcome, identify work that will be discarded or delayed, and confirm the revised deadline. Treat the change as a planning decision.
Test the assignment with two different deliverables
Suppose the request is "Give leadership an update on onboarding." Sketch two plausible outputs before asking for clarification. One is a single chart showing where people abandon setup. The other is a recommendation to remove two setup steps. Both describe onboarding, but they support different decisions.
Ask: "Does leadership need to understand current performance, or approve a change? I can prepare either, but the recommendation needs a cost estimate from engineering."
Once the manager chooses, test the boundary: "If the cost estimate is missing Thursday, should I send the performance update with the recommendation marked pending?" This question exposes what happens when a dependency slips. It also separates a draft you can produce from a decision you cannot make alone.
For rehearsal, ask a partner to change one condition after you read back the task. They might move the deadline forward or change the audience from the product team to finance. Revise only the affected parts. Check whether the deliverable, approval owner, and review time still agree. The exercise ends when both people can describe the same output without reading your notes.
Use concrete examples when a quality bar still sounds abstract.
