Giving Feedback That Engineers Actually Hear
A practical framework for delivering technical and behavioral feedback that drives change. Covers the SBI model, timing, peer feedback, performance reviews, and how to have the conversations that most managers avoid.
Most engineering managers are terrible at feedback. Not because they are bad people, but because they were engineers for 10 years and nobody taught them this. They either avoid feedback entirely — letting performance issues fester until they become termination conversations — or they deliver it so abstractly that the engineer walks away thinking everything is fine.
Feedback is a skill. Like any engineering skill, it has patterns, antipatterns, and best practices. This guide covers the mechanics of giving feedback that actually changes behavior.
Why Engineers Ignore Your Feedback
Before learning how to give feedback, understand why it fails:
| Failure Mode | What the Manager Says | What the Engineer Hears |
|---|---|---|
| Too vague | ”You need to be more proactive" | "I have no idea what to do differently” |
| Too delayed | ”Remember that thing 3 months ago?" | "Why are you telling me now?” |
| Too personal | ”You are not a team player" | "You are attacking my character” |
| Too sandwiched | ”Great work! But also… Great work!" | "I think I heard a compliment?” |
| Too public | Critical feedback in a team meeting | ”I am embarrassed and angry” |
| Too rare | Once a year in the performance review | ”This came out of nowhere” |
The common thread: feedback fails when it is unclear, untimely, or unsafe.
The SBI Framework
Situation-Behavior-Impact. This is the simplest, most effective feedback structure:
Situation: When and where did this happen?
Behavior: What specifically did the person do? (Observable actions, not interpretations)
Impact: What was the result of that behavior?Examples
Bad feedback: “Your code reviews are too harsh.”
Good feedback using SBI:
“In yesterday’s code review on the auth PR (situation), you left 14 comments, most of which were about style preferences rather than correctness (behavior). The junior engineer who submitted the PR told me they are dreading their next code review and considering not submitting changes unless they are confident they are perfect (impact).”
Bad feedback: “You need to communicate more.”
Good feedback using SBI:
“During last week’s incident with the payments service (situation), you identified the root cause and fixed it within 20 minutes, but you did not update the incident channel until the fix was deployed (behavior). The on-call manager and three other teams were still investigating the issue for those 20 minutes because they did not know you had it handled (impact).”
Notice: no interpretation, no character judgment. Just observable facts and measurable impact.
Timing: The 48-Hour Rule
| Timing | Effectiveness | Exception |
|---|---|---|
| Within 24 hours | ✅ Highest — fresh context, specific recall | If emotions are too high, wait |
| Within 48 hours | ✅ Good — still relevant and specific | Preferred window |
| Within 1 week | ⚠️ Declining — details get fuzzy | Acceptable for complex situations |
| Within 1 month | ❌ Poor — “I don’t even remember that” | Only if you discover impact later |
| At performance review | ❌ Terrible — feels like an ambush | Never save feedback for reviews |
The rule: If you notice something worth feedback on Monday, deliver it by Wednesday. If you consistently discover that a month has passed, you are avoiding feedback — and avoidance is the most damaging feedback failure mode.
Positive Feedback: More Important Than You Think
Engineers are starved for specific positive feedback. “Good job” is not positive feedback — it is noise. Specific positive feedback reinforces the exact behaviors you want to see more of.
Noise: “Great work on the migration!”
Specific positive feedback:
“The way you structured the database migration as three reversible steps instead of one big transaction (behavior) meant that when step 2 failed in staging, we could fix it without rolling back the entire migration (impact). That saved us at least a full day of rework. I want to see more of that kind of defensive engineering.”
The Ratio
Research consistently shows that high-performing teams have a feedback ratio of approximately 5:1 — five positive observations for every constructive one. This is not about being nice. It is about ensuring that people trust your feedback channel, so that when constructive feedback arrives, it lands.
| Ratio | Team Perception |
|---|---|
| 0:1 (only constructive) | “My manager only notices problems” |
| 1:1 (balanced) | “Feedback is unpredictable and stressful” |
| 3:1 (mostly positive) | “My manager is fair and notices my work” |
| 5:1 (research optimal) | “I trust my manager’s feedback and act on it” |
| 10:1 (overwhelmingly positive) | “The positive feedback feels performative” |
The Difficult Conversations
Some feedback conversations are genuinely hard. Performance is not improving. Behavior is affecting the team. The engineer is not meeting expectations. Here is how to handle them:
The Performance Improvement Conversation
Structure:
1. State the pattern (not one incident — the pattern)
"Over the last 6 weeks, three pull requests have been submitted
with failing tests, and two production deploys needed rollbacks."
2. State the impact
"This has created extra work for the team reviewing your PRs
and reduced our deployment confidence."
3. Ask for their perspective
"What is going on? Is there something I am missing?"
(Listen. Actually listen. There may be context you lack.)
4. Agree on the expectation
"Going forward, I need PRs to pass CI before requesting review,
and deploys to be validated in staging."
5. Agree on support
"What do you need from me to make this happen?
Pair programming? Reduced scope? Different assignments?"
6. Set a timeline
"Let's check in on this in 2 weeks. I want to see improvement
in the next 3 PRs."
7. Document everything
Send a follow-up email summarizing the conversation.
This protects both of you.What NOT to Do
| Don’t | Why |
|---|---|
| Don’t compare to other team members | ”Sarah never has this problem” is demoralizing and creates resentment |
| Don’t diagnose motivation | ”You clearly don’t care about quality” is a character attack |
| Don’t threaten implicitly | ”If this continues…” without specifics creates anxiety, not change |
| Don’t have the conversation in Slack | Hard feedback must be synchronous (video or in-person) |
| Don’t skip documentation | When you need to escalate, you will need a paper trail |
Peer Feedback Systems
The most valuable feedback often comes from peers, not managers. You see your reports in 1:1s and planning meetings. Their peers see them in code reviews, incident response, and daily collaboration.
Lightweight Peer Feedback Process
Quarterly cycle:
1. Each person selects 3-4 peers to give them feedback
2. Peers respond to 3 questions:
- "What should this person keep doing?"
- "What should this person start doing?"
- "What should this person stop doing?"
3. Manager synthesizes themes (anonymized)
4. Manager shares themes in 1:1 with context and coachingThis takes each person 30 minutes per quarter and produces better signal than any annual review process.
Implementation Checklist
- Practice the SBI framework on your next 3 feedback conversations (start with positive)
- Audit your feedback ratio: count positive vs constructive feedback over the next 2 weeks
- Set a personal rule: deliver feedback within 48 hours or write it down immediately
- Establish a quarterly peer feedback cycle with 3 simple questions
- For performance issues, document every conversation with date, content, and agreed actions
- Schedule feedback practice with a peer manager — rehearse difficult conversations
- Never save feedback for performance reviews — reviews should contain zero surprises
- Ask your reports: “How do you prefer to receive feedback?” and respect their answer
