Giving Feedback

---
name: giving-feedback
description: Deliver feedback with situation-behavior-impact structure, timeliness, and care calibrated to stakes. Use when correcting course, recognizing work, or preparing a hard conversation.
---

# Giving feedback

Feedback is information delivered so the receiver can use it. The
failure modes are symmetric: softening until the message vanishes,
or bluntness that triggers defense instead of change: structure and
timing beat both.

## Method

1. **Build on situation-behavior-impact.** The specific
   moment ("in yesterday's design review"), the observable
   behavior ("you dismissed the two questions about
   failover before they finished"), the concrete impact
   ("the team stopped raising concerns, and we may have
   missed a real gap": see design-critique's stakes).
   No character verdicts ("you are dismissive"), no
   mind-reading ("you clearly don't care"): behaviors are
   arguable and changeable; identities are neither.
2. **Deliver promptly, at the right stakes level.** Small
   course corrections within a day or two, casually
   ("quick thought on the review..."); patterns and serious
   issues get a scheduled private conversation with
   preparation (see one-on-one-meetings' boundary on
   ambushes). Feedback aged three months is archaeology
   the receiver cannot act on and will hear as a stored
   grievance.
3. **Make praise as specific as criticism.** "Your runbook
   let me fix the outage without paging you: that is what
   senior looks like" (see runbook-writing, promo-packet:
   specific praise is also evidence) teaches what to
   repeat; generic "great job" is pleasant noise. Public
   praise, private correction: as defaults, flexed by the
   receiver's stated preference.
4. **State the message once, plainly, then stop.** One
   clear statement of the issue and impact, then hand the
   floor: "how do you see it?" The sandwich buries the
   message; repetition hammers it into humiliation. Their
   context may genuinely change your read (see
   receiving-feedback: you might be the one updating);
   a conversation, not a verdict reading.
5. **Agree on the change and the follow-up.** End hard
   conversations with a concrete next state ("designs
   circulate a day before review"), an offer of support,
   and a check-in point; feedback without a landing spot
   is venting with structure (see
   one-on-one-meetings' action discipline). Notice and
   name improvement when it happens: the loop's reward
   step is the part everyone skips.
6. **Check your standing and your data first.** Before
   hard feedback: is this behavior or preference (see
   code-review's Nit-level rule generalized), is it a
   pattern or one bad day, do you have it firsthand or
   through the rumor mill? Secondhand feedback names its
   nature ("I was not there, but two people independently
   raised...") or waits until you have your own
   observation.

## Boundaries

- Feedback across power gradients lands heavier
  downward; managers calibrate for the amplification,
  and upward feedback deserves explicit invitation and
  visible non-retaliation (see receiving-feedback,
  one-on-one-meetings' candor symmetry).
- Some issues are not feedback conversations: policy
  violations, harassment, and legal matters go through
  formal channels immediately.
- Style-preference feedback dressed as impact
  ("I would have used a different pattern") crowds the
  channel; save it for explicitly-requested opinions or
  let it go (see code-review-comments).