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).