How to Give Feedback to Engineers
Most engineering managers know they should give more feedback. Very few actually do it well. The typical failure mode looks like this: you notice a problem, you say nothing for weeks, and then you dump a vague complaint during a performance review. Your direct report is blindsided, defensive, and has no idea what to change. Nothing improves.
This is not a character flaw. It is a skill gap. Nobody taught you how to give feedback, so you default to either avoiding it entirely or delivering it so poorly that it backfires. Here is how to fix that.
Why Most Feedback Fails
Engineering manager feedback fails for three predictable reasons.
It is too vague. "You need to communicate better" tells someone nothing. Better at what? With whom? In what context? Vague feedback creates anxiety without creating clarity. The person walks away knowing you are unhappy but not knowing what to do differently.
It is too late. If you wait three months to mention that someone's PR descriptions are consistently too thin, you have missed the window where feedback is actionable. The behavior is now a habit, and your direct report reasonably wonders why you never said anything before.
It uses the sandwich method. You have heard this advice: start with a compliment, deliver the criticism, end with another compliment. Engineers see through this immediately. The compliments feel hollow, and the real message gets buried. People learn to brace themselves whenever you say something nice, because they know the "but" is coming.
The SBI Framework for Engineers
The most effective feedback model for engineering contexts is SBI: Situation, Behavior, Impact. It forces you to be specific, observable, and connected to outcomes.
- Situation: When and where did this happen? Be specific about the context.
- Behavior: What did you actually observe? Not your interpretation, not your assumption about their intent — the observable behavior.
- Impact: What was the result? How did it affect the team, the project, or you?
Here is what SBI looks like in practice across common engineering situations:
Code quality: "In your PR for the payments service refactor on Tuesday (situation), you added 400 lines with no tests and a one-line description (behavior). Two other engineers spent an hour each trying to review it and ended up approving it without fully understanding the changes, which slowed down the release (impact)."
Communication: "During yesterday's sprint planning (situation), you stayed silent when the team discussed the API design, then sent a long Slack message afterward disagreeing with the decision (behavior). The team felt like the discussion was reopened after they thought it was settled, and it added a day of back-and-forth (impact)."
Missed deadline: "You committed to finishing the migration script by Friday (situation), and on Monday I learned it was not started (behavior). The downstream team had blocked out their week to do integration testing and had to reschedule, which pushed the release by a sprint (impact)."
Meeting behavior: "In the last two incident reviews (situation), you jumped in to explain what went wrong before the person presenting had finished their timeline (behavior). I noticed the junior engineers stopped contributing after that, and we lost perspectives that would have helped us find the root cause (impact)."
Notice what SBI does not include: assumptions about why someone did something. You are describing what you saw and what happened as a result. That keeps the conversation grounded in facts rather than character judgments.
Giving Positive Feedback That Actually Means Something
"Great job on the release" is not feedback. It is a pleasantry. It feels good for a second and is forgotten immediately.
Positive feedback follows the same SBI structure. The goal is to reinforce a specific behavior so the person does it again — and knows exactly what they did right.
Instead of "Nice work on that PR," try: "In your authentication service PR (situation), you included a detailed description with a diagram of the state transitions and called out the tradeoffs you considered (behavior). That cut the review time significantly, and the two engineers who reviewed it both told me they learned something from your writeup (impact). That is the standard I want to see for complex PRs."
The last sentence is crucial. It tells your direct report that this is not just a nice thing they did once — it is what you want to see consistently. That transforms a compliment into a growth signal.
Giving Critical Feedback Without Destroying Trust
Critical feedback is where most managers freeze up. Here are the principles that make it work:
Deliver it privately, always. Never criticize someone's work in a public channel or group meeting. Even mild corrections in public feel humiliating and will destroy trust instantly.
Deliver it quickly. The ideal window is within 24-48 hours. The longer you wait, the less connected the feedback feels to the actual event. If you notice something on Tuesday, bring it up in your next 1:1 or schedule a quick five-minute conversation.
Separate behavior from identity. "Your PR descriptions are too short" is about a behavior. "You are a careless engineer" is about identity. One is fixable. The other is an attack.
Ask questions before making statements. Before delivering your observation, ask: "Can you walk me through your thinking on the API design you proposed?" You might learn something that changes your feedback entirely. Maybe they made a tradeoff you were not aware of. Maybe they were under time pressure you did not know about.
End with a clear ask. After delivering SBI feedback, state explicitly what you want to see going forward. "Going forward, I would like you to flag deadline risks at least two days before the due date so we can adjust plans." This gives them a concrete action instead of just a criticism to sit with.
When and Where to Give Feedback
Positive feedback: Give it publicly when appropriate (team meetings, Slack channels). Public recognition amplifies the effect and signals to the team what good looks like. But check with the person first — some engineers are uncomfortable with public praise.
Critical feedback: Always private. Always in a 1:1 or a dedicated conversation. Never in a group setting, never in a public Slack channel, never in a PR comment that is really about a behavioral pattern rather than a code issue.
Real-time vs 1:1: Small observations can wait for your next 1:1. Significant issues should not wait. If someone just derailed a meeting or committed something that will cause an incident, have a brief private conversation that day. Do not let urgency be an excuse to skip preparation, though — even a quick feedback conversation benefits from thinking through the SBI framing first.
Handling Defensive Reactions
When someone gets defensive, your instinct will be to back off or over-explain. Resist both.
Pause and listen. Let them respond fully. Do not interrupt. Their defensiveness often contains useful information — maybe they feel the feedback is unfair, or maybe they are dealing with something you do not know about.
Acknowledge their perspective without retracting. "I hear you that the timeline was aggressive. I still need you to flag risks earlier so we can adjust together." You can validate their experience without withdrawing the feedback.
Stay grounded in observable behavior. If the conversation drifts into "but I always..." or "that is not fair," bring it back to the specific situation. "I am talking about the payments PR on Tuesday specifically. Let us focus on that one."
Follow up. After a tough feedback conversation, check in during your next 1:1. Ask how they are feeling about it. Reinforce that the goal is their growth, not punishment.
Building a Feedback Habit
The hardest part of feedback is not the conversation — it is remembering to have it. You see something worth mentioning on a Wednesday, and by Friday's 1:1 it has evaporated.
Write it down immediately. When you notice a behavior worth discussing — positive or critical — capture it in the moment. A quick note with the date, what you observed, and the impact is enough. Tools like Gemba are built for exactly this: capturing observations and talking points throughout the week so they surface in your next 1:1 instead of disappearing into your memory.
Aim for a 3:1 ratio. For every piece of critical feedback, try to deliver at least three pieces of specific positive feedback. This is not about softening blows — it is about making sure you are noticing what people do well, not just what they do wrong. Most managers dramatically under-index on positive feedback.
Make feedback a standing part of your 1:1 agenda. Do not wait for something big. Every 1:1 should include at least one specific observation about your direct report's work from the past week. This normalizes feedback as a regular conversation rather than a special event that signals something is wrong.
The bar for feedback is low. Most engineering managers give almost none. If you start using SBI consistently, capture observations as they happen, and make feedback a weekly habit, you will be better at this than 90% of managers your reports have ever worked with. That is not a high standard. But it is the one that actually builds trust and changes behavior.
If you want a system that helps you track observations, organize 1:1 agendas, and build a consistent feedback habit — try Gemba for free. It was built for engineering managers who want to get better at exactly this.