receiving-feedback · git:20260720.adc529a · 2026-07-20 · sha256 9bfd3c3c9c5e23e8
receiving-feedback git:20260720.adc529aA
Immutable. This exact content is served forever at /api/v1/blob/9bfd3c3c9c5e23e8.
---
name: receiving-feedback
description: Receive feedback by listening past delivery, extracting the signal, and closing the loop with visible action. Use when getting reviews, criticism, or hard performance conversations.
---
# Receiving feedback
The receiver controls whether feedback becomes growth or noise.
The skill is separable from the giver's: badly-delivered feedback
still carries information, and extracting it while your pulse is up
is a trainable move.
## Method
1. **Regulate first; the window is thirty seconds.** Defense
arrives before understanding: breathe, take notes (writing
occupies the defensive voice), and hold the rule "respond
to none of it now if hot". "Thank you: let me think about
this and come back tomorrow" is a complete, high-status
response to hard feedback.
2. **Listen for the data under the delivery.** Clumsy,
overstated, or badly-timed feedback usually wraps a true
observation; translate ("you always ship broken code" =
two recent regressions landed on them: see
giving-feedback's SBI, run in reverse). Judge the
information's usefulness separately from the giver's
skill in delivering it.
3. **Ask for specifics until it is actionable.** "Can you
give me a recent example?" "What would good have looked
like there?": genuine curiosity, not cross-examination;
the difference is whether you are gathering or rebutting.
Vague feedback ("be more strategic") stays useless until
pinned to moments and behaviors (see
mentoring-engineers' concreteness).
4. **Triangulate before big updates.** One person's feedback
is one sensor: weight by their vantage point, check
against others who see the same work ("I got feedback
that X: does that match what you see?"), and look for
the pattern across sources and time (see
ml-error-analysis's instinct: one error is noise, a
cluster is signal). Discard respectfully what
triangulation refutes; you are not obligated to act on
everything.
5. **Decide, act, and close the loop visibly.** Choose the
1-2 changes worth making (not all ten at once), tell the
giver what you are doing ("you were right about review
turnaround: I have blocked mornings for it"), and check
back later; closing the loop is what converts givers
into allies who keep telling you the truth (see
giving-feedback's follow-up step, from the other
chair). People stop giving feedback to those who argue
with all of it or act on none of it.
6. **Build your own early-warning system.** Ask
specifically, not generally: "what is one thing that
would have made that design better?" beats "any
feedback?"; ask the people positioned to see your gaps
(the reviewer you frustrate, the report who reads your
moods: see one-on-one-meetings' both-directions
candor); and log what you hear (see decision-journals)
so annual reviews contain no ambushes.
## Boundaries
- Feedback about immutable traits, or delivered as
harassment, is not a growth opportunity; name it,
document it, escalate through real channels.
- In formal performance conversations, listening well
does not mean accepting inaccurate claims into the
record; correct facts calmly, in writing, while still
mining the true parts (see salary-negotiation's poise
under pressure).
- Feedback-seeking can become approval-seeking; the goal
is a calibrated self-model, and at some point you
decide and move (see tradeoff-analysis:
reversibility applies to self-change too).