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