Giving Structured Feedback

Option C correctly applies the SBI (Situation-Behaviour-Impact) feedback framework:

SBI breakdown:
• S — Situation: "our architecture review on Tuesday, during the discussion about caching strategy" — specific, not vague "in meetings"
• B — Behaviour: "spoke over @sarah three times before she could finish" and "same with @james" — observable actions, not personality judgments ("aggressive", "dominant")
• I — Impact: "both stopped trying to contribute after that; potentially lost valuable perspectives in a decision that will affect the team for months" — connects the behaviour to a real consequence

What makes this excellent beyond SBI:
1. Intent acknowledgement — "I think it comes from enthusiasm" — separates the behaviour from malicious intent, lowers defensiveness
2. Stakes framing — "your voice carries weight; that makes inclusive discussion more important" — reframes the feedback as being about maximising their positive influence, not just correcting bad behaviour
3. Collaborative framing — "I'd like us to work on it" — shared ownership, not accusation

SBI vs vague feedback:
• Vague: "You're too dominant" → triggers defensiveness, no actionable change
• SBI: specific situation + observable behaviour + concrete impact → actionable, harder to dismiss

Option C is a professional written performance review section:

What makes it effective:
1. Leads with strengths — specific work artifact ("PR #488"), specific skill demonstrated — not generic praise
2. Development area framing — "development area", not "weakness" — the framing affects how the person receives it
3. Specific incidents — "two client-facing status updates in Q3 required significant revision" — evidence, not impression
4. Specific pattern named — "technical details the audience didn't need; resolution/next steps not prominent enough" — tells them exactly what to change
5. Normalizes the gap — "common growth area at this career level" — reduces shame, contextualizes
6. Concrete goal with support — specific action (draft updates for next two incidents), specific mechanism (share with manager before sending), specific commitment (I'll provide coaching) — not "should improve"

The "specific artifact + pattern" rule:
Every feedback item in a performance review should be traceable to at least one specific event, PR, meeting, or document. "Bad at emails" is unchallengeable and therefore often challenged. "These two updates needed revision for these specific reasons" is specific and actionable.

The goal quality test:
A good review goal has: an action, a timeframe, a deliverable, and a support structure. "Needs to improve communication" passes zero tests. "Draft next two incident updates for manager review" passes all four.

Option C is the professional response to pushback on code review feedback:

Structure:
1. Validates their reference — "you're right that the docs describe that pattern" — acknowledges they weren't wrong to check
2. Explains the gap — "docs predate some scaling issues we ran into" — fills in context they couldn't have had
3. Gives specific evidence — N+1 at 10K req/s, specific incident reference, postmortem PR — makes the concern concrete and verifiable
4. States the motivation — "rather have this conversation now than discover in production" — frames it as looking out for them, not winning an argument
5. Stays genuinely open — "if you think the trade-off is different for this use case, walk me through your reasoning" — this is not rhetorical; they might have context you lack

Why "because I said so" damages junior growth:
Junior engineers learn by understanding the "why". A senior who can't explain a review comment is either applying cargo cult patterns or doesn't have time to teach. The first is a problem; the second damages trust over time. Both result in juniors who comply without learning.

When the junior's pushback is right:
Sometimes they know something you don't. "Walk me through your reasoning" is not just diplomatic — it's intellectually honest. Good feedback culture goes both directions.

Option C is the professional corrective feedback conversation:

Structure:
1. Names the specific event — "the auth story last sprint, marked done before it was complete" — concrete, not general
2. Sets intent — "not to blame; to understand so we can prevent it" — lowers defensive response
3. Asks for their side first — understanding the engineer's experience might reveal something unknown (blocked? overwhelmed? unclear scope?)
4. Distinguishes the real issue — "the issue isn't the delay — it's the communication" — names the actual behavior that needs to change, not the symptom
5. Explains the business reason — "the earlier we know, the more options we have; marking done removes that optionality" — connects the behavior to real consequences
6. Makes a specific behavioral agreement — "if you're at risk by mid-sprint, flag it in standup" — concrete, observable, agreed
7. Changes the frame — "I'm interested in supporting you earlier" — positions the manager as a resource, not a guard

The "behaviour vs. person" distinction:
Feedback about "marking a story done" (behaviour) is received very differently from "you're dishonest" (person). Always target the behaviour and its impact on the team's ability to work.