In receiving feedback you disagree with, several legitimate demands compete at once. The useful question is which demand must be protected first and which can wait. The purpose here is turning observations into information someone can use. Useful feedback reduces ambiguity about what happened and what to do differently next time.
A simple decision tree
If the first signal is too many examples at once: use ask what the person noticed. If the issue is missing information: use use examples close to the event. If the problem is pressure rather than information: use check understanding by asking for the person’s takeaway. The point is to match the tool to the constraint instead of using the same response every time.
Decision 1: what are you protecting?
Name the outcome in one line. For receiving feedback you disagree with, ask whether the priority is speed, quality, trust, learning, ownership or another constraint. When two priorities conflict, decide which one wins for this attempt and why.
Decision 2: what will make you pause?
Use praise with no information about what worked as an early warning. A pause is not inactivity; it is a chance to prevent giving feedback only when something is wrong. The pause can be one breath, one written note or one clarifying question.
Decision 3: when do you switch plans?
Plan B begins when the original approach no longer protects the objective. Switch from ask what the person noticed to connect the behavior to its impact if the first tool is no longer producing useful information or if the cost of continuing rises.
Language for the decision point
For the next one, could you try…?
What is the one thing you are taking from this conversation?
Review the branch you actually used
| Attempt | Decision point | Branch used | Evidence | Next rule |
|---|---|---|---|---|
| 1 | too many examples at once | ask what the person noticed | evidence of behavior change in the next comparable situation | Change one variable |
| 2 | praise with no information about what worked | use examples close to the event | amount of rework after the feedback | Keep what helped |
| 3 | What became predictable? | Repeat the reliable move | clarity of the requested behavior | Increase difficulty only if stable |
A before–during–after protocol
Before: use use examples close to the event and decide what would count as a satisfactory response. During: watch for praise with no information about what worked and correction with no future action; when either appears, use separate evaluation from development and the short cue “What is the one thing you are taking from this conversation?”. After: capture one piece of evidence about whether the receiver can state the next step and one adjustment for next time. The protocol is deliberately short so it remains usable when receiving feedback you disagree with becomes demanding.
How to keep the protocol honest
Do not judge the attempt only by the final result. A good outcome can hide a poor process, and a difficult outcome can still contain a better decision. Review whether the chosen behavior supported turning observations into information someone can use. If you notice confusing disagreement with lack of understanding, treat that as information about the design of the routine, not as proof that you lack the skill.
Use a smaller unit of improvement
Do not try to improve the whole situation at once. Choose one decision point, one sentence, one handoff, one pause, or one review habit. A small unit is easier to rehearse and easier to measure. Once it is reliable, connect it to the next part of the situation. This is slower than collecting many techniques, but it usually produces clearer learning because you can tell which change affected the result. Applied to receiving feedback you disagree with, keep the review tied to feedback rather than turning it into a broad judgment about ability. Write one observation from the attempt, one decision you would repeat, and one change for the next comparable situation. If you cannot name those three items, the review is probably still too general. The purpose is to leave the situation with a usable next experiment, not a longer explanation of why it was difficult.
Questions people ask
What if I forget the technique in the moment?
Shorten it. Put ask what the person noticed into the environment before the event and use one sentence such as “For the next one, could you try…?” rather than trying to remember a full framework.
What if another person makes the situation harder?
Keep the boundary between influence and control clear. You can use use examples close to the event, state the relevant constraint, and decide whether to continue, pause, renegotiate or escalate.
How long should I practice before changing the plan?
Run several comparable attempts unless the approach creates a clear problem. Look for a trend in clarity of the requested behavior, not a perfect first performance.