How to Give Difficult Feedback to Engineers

A senior engineer’s code reviews are technically excellent and consistently harsh. Over a few weeks, the manager notices that pull requests from two junior engineers are increasingly going to other reviewers, and one of them has asked about a transfer. The manager knows a conversation is needed. For three weeks, the plan has been to raise it “when the moment is right”. The moment has not come, and the silence is starting to look like approval. Knowing how to give difficult feedback to engineers early is what breaks that silence.

Most managers recognize this situation. The conversation feels risky, so it waits, and the waiting makes it bigger. It gets easier with a structure, especially when the person you need to correct is someone you also depend on.

Why Hard Feedback Gets Delayed

Two forces push the conversation back. The first is discomfort: you feel the awkwardness immediately, while the cost of silence arrives later and spread out, so the calendar keeps offering better moments. The second is worry about the relationship. In practice, what damages relationships is rarely the candor itself. It is surprise: feedback that arrives weeks late, in front of others, or as a vague hint the person has to decode.

Meanwhile, silence has its own effect. The engineer reads it as acceptance, and the people affected read it as the manager taking sides. By the time the conversation happens, it is about a pattern instead of one incident, and patterns are harder to hear. The PMBOK Guide groups this skill under emotional intelligence, and the most practical part of emotional intelligence here is managing your own discomfort early enough that the feedback stays small.

Situation, Behavior, Impact, Then Intent

The Center for Creative Leadership’s Situation-Behavior-Impact model, SBI, keeps feedback anchored to observable facts:

• Situation: when and where, so there is no doubt which moment you mean.
• Behavior: what the person actually did or said, as a recording would show it. No adjectives, no interpretation.
• Impact: the effect on the work, the team, or you.

CCL also describes a fourth step that turns the statement into a conversation: asking about intent. “What were you aiming for there?” invites the person to explain, and it often reveals a gap between what they meant and how it landed. That gap is usually where the real fix lives.

The difference between SBI and a verdict is easy to hear:

SBI has a weakness when used too literally: recited word for word, it sounds scripted, and an impact statement about your feelings can tip into passive aggression (“the impact was that I felt let down”). Use the structure to prepare, then say it in your own words. Keep impact statements about effects on the work and the team wherever you can.

Behavior can change by tomorrow. Identity cannot. Feedback about what someone did gives them something to act on; feedback about who they are gives them something to defend.

Protect the People Who Raised Concerns

Sometimes you hear about a problem from someone else, often a more junior colleague. Do not repeat what they told you or name them in the conversation. Saying “Priya told me she’s avoiding your reviews” to a powerful senior engineer puts Priya at risk and teaches the whole team that raising concerns is dangerous.

Instead, gather evidence you can describe first-hand. Read the review threads yourself. Notice the routing pattern in your own tooling. Attend the next design review. Then give feedback on what you observed. If the only evidence comes from a confidential report and the issue is serious, such as harassment or discrimination, it belongs with HR, not in an SBI conversation.

Prepare in Writing

BEFORE THE CONVERSATION
Situation:  one specific time and place.
Behavior:   what a recording would show. No adjectives.
Impact:     on the work, the team, or you. One sentence.
Intent:     the question you'll ask: "What were you aiming for?"
Change:     the one specific thing you hope will be different.
Setting:    private, unhurried, not five minutes before another meeting.

Timing has one rule: soon. Within days, while both of you remember the details. Feedback about something from last quarter feels like a file being opened, not a conversation. For distributed teams, make an exception to written-first habits: hard feedback should happen live, on a call. The norms for everything else are in async communication for distributed engineering teams.

Two Feedback Conversations

A missed commitment:

Manager: Have you got ten minutes? I want to talk about the payments review. It was due Monday and came in Thursday, and that pushed the release by three days. Can you walk me through what happened?

Engineer: I picked up the on-call rotation, and the audit requests ate the week. I did say it was tight.

Manager: You did, and taking on-call was the right call. The part I’d like to change is that “tight” arrived without a date or options. If you tell me the same day that something is slipping and what the trade-off is, I can re-sequence work or find help. Can we agree on that for next time?

Engineer: Same day, with the trade-off. That’s fair.

The harsh reviewer from the opening:

Manager: I want to talk about review style, because I think it’s affecting the team. On Tuesday’s checkout PR, your first three comments were “why would you do this”, “this is wrong”, and “did you test this at all”. Over the past month, I’ve noticed fewer PRs being sent to you for review, and review threads with you getting shorter. What were you aiming for with those comments?

Senior engineer: The design was broken and there were no tests. Should I have pretended otherwise?

Manager: No. The technical points were right, and I want you to keep making them. What I’m asking about is how they’re phrased. The same points as questions, like “what happens here under retry?”, would land and teach at the same time. What would a great version of that review look like to you?

Senior engineer: Same content, questions instead of verdicts. I can do that.

Manager: Thanks. I’ll read your next few reviews and tell you honestly how they come across.

Both conversations follow the same shape: a specific situation, observable behavior, its impact, a genuine question, and one agreed change. Neither starts with an apology for raising it, and neither uses words like “attitude”.

I have worked with my fair share of difficult engineers, and one thing is consistent: most people get defensive when they receive feedback. My own approach has been to start by acknowledging their technical strengths, honestly and specifically, and then give specific feedback on how their behavior, or a lack of ownership, affected the team. The acknowledgment is not padding. It lowers the defensiveness enough for the actual message to be heard.

What to Avoid Saying

Praise used as padding. There is a difference between acknowledging someone’s genuine strengths and burying a correction between two generic compliments. Honest, specific acknowledgment of what someone does well lowers defensiveness and helps the feedback land. Vague praise used purely as cushioning does the opposite: many people hear the praise and miss the point, and experienced engineers learn to brace whenever they are complimented. If you open with a strength, make it real and specific, then state the feedback plainly, and do not soften it again at the end.

“You always” and “you never”. They turn one incident into a judgment about character, and the person will immediately think of the exceptions.

“I’m not angry, but…” It announces exactly the emotion it denies.

Correction in public. Praise can happen in front of the team. Correction belongs in private, every time.

Kim Scott’s Radical Candor sums up the balance well: care personally and challenge directly. Care without challenge becomes vague niceness that helps nobody; challenge without care becomes aggression.

Follow Up in Writing

The conversation starts the change; the follow-up decides whether it lasts. Send a short note the same day:

Thanks for talking about [topic] today. What I took away: we agreed that
[specific change], starting [when]. I'll check in on [date]. If anything
makes this harder than it sounds, tell me early.

It is not bureaucracy. It prevents the next conversation from becoming a dispute about what was agreed. Then notice the change when it happens, and say so specifically. The same precision that made the correction land makes the recognition land too.

During the conversation itself, listen actively: say back what you heard before responding, especially when you disagree. People accept feedback far more readily when they feel understood first.

When the Difficult Person Is Your Best Engineer

The hardest version of this conversation is with someone the team depends on: the senior engineer who knows the payments system better than anyone, ships reliably, and leaves a trail of bruised colleagues behind them. Managers delay this conversation more than any other, because the fear is concrete. What if they leave?

It helps to count the costs honestly. The visible cost of losing a strong engineer is easy to imagine. The less visible cost of keeping one who drives others away builds up quietly: juniors who stop asking questions, reviews routed around them, good people transferring out, and a team whose knowledge stays concentrated in one person because nobody wants to learn from them.

A few principles help:

• Separate the value from the behavior, out loud. “Your technical judgment is one of the most valuable things on this team. The way it’s delivered is costing us.” Both statements are true, and saying both makes the second easier to hear.
• Frame it as part of the role, not a personal favor. Many engineering career frameworks treat raising the people around you as part of what seniority means. If yours does, use it: “At your level, how others learn from your reviews is part of the job.”
• Do not trade standards for retention. If the team learns that being indispensable exempts someone from basic respect, everyone else’s standards drop too.
• Involve them in the fix. Ask them to help write the team’s review guidelines, or to pair with a junior for a month. People change more readily when they help define the new standard.
• Give a clear timeline, and be prepared for either outcome. Most people respond well to direct, respectful feedback. If they do not, after clear conversations and real support, losing them may be the better result for the team.

When Feedback Is the Wrong Tool

If the issue is an ongoing disagreement between two people rather than one person’s habit, use the approaches in how to handle conflict on an engineering team. If the same pattern continues after two clear, documented conversations, it has become a performance matter and your manager or HR should be involved. If the person is on another team, take the specifics to their manager rather than going around them. And if the behavior is harassment or abuse, stop coaching and escalate immediately.

FAQ

How do you give difficult feedback to engineers?

Describe a specific situation, the observable behavior, and its impact, then ask what they were aiming for. Do it privately and within a few days of the event. Agree on one specific change, and confirm it in a short written note the same day.

What is the SBI feedback model?

SBI stands for Situation, Behavior, Impact, a feedback structure from the Center for Creative Leadership. You anchor the moment, describe only what was observable, and name the effect. CCL’s extended version adds a fourth step: asking about the person’s intent.

What should you not say when giving feedback?

Avoid generic praise used only to cushion the message; acknowledge real strengths specifically, then state the feedback plainly. Avoid “you always” and “you never”, which turn one event into a judgment about character. Avoid “I’m not angry, but”, and never correct someone in front of others.

How do you give feedback to a senior engineer?

Use the same structure, with two adjustments. Acknowledge the genuine strength of their work, because senior engineers notice insincere praise immediately, and ask them to design the change themselves. Then follow up, because established habits rarely change after one conversation.

Sooner Is Kinder

When you give difficult feedback to engineers, the hardest part is usually the decision to have the conversation at all. Prepare the specifics, protect the people who raised concerns, ask before you prescribe, and follow up in writing. More on communicating as an engineering leader is in communication.

Last updated on 10 October 2026