How to Give Feedback That Actually Changes Behavior

"You need to be more senior."

I said that to an engineer once, in a performance review, with a straight face. He nodded. He thanked me. And for the next three months, he changed nothing. Not because he ignored me. Because I had given him nothing to change. I handed him a label and called it feedback.

That failure taught me more than any management book. Feedback is not the act of telling someone your opinion of them. Feedback is an attempt to change what a person does. If the behavior does not change, the feedback did not work. It does not matter how honest you were, how well you meant it, or how carefully you softened it. The only scoreboard that counts is whether something is different next week.

I have given a lot of bad feedback. Vague feedback, late feedback, feedback that made someone defensive instead of better. I have also watched a single well-placed sentence change how an engineer worked for years. The difference between the two is not talent or charisma. It is a handful of specific choices. This post is about those choices.

Most feedback fails before it is even delivered

Walk into any engineering org and you will hear the same feedback given over and over. "Be more proactive." "Show more ownership." "Communicate better." "Be more strategic." Every one of these is useless, and here is why.

None of them point at a behavior. They point at a trait. "Be more proactive" is not something a person can do on Monday morning. It is a judgment about their character dressed up as advice. The person on the receiving end hears it, feels vaguely bad, and has no idea what to actually do differently. So they do nothing, or they guess, and the guess is usually wrong.

The test I now apply to every piece of feedback before it leaves my mouth is simple. Could the person act on this tomorrow? If I cannot name the specific thing they did, the specific thing I want instead, and the specific reason it matters, then I am not ready to give the feedback. I am just venting a feeling in their direction.

There is a second, quieter reason feedback fails. Most of it is never given at all. The manager notices the problem, decides it is not worth the awkward conversation, and files it away. Then it comes out months later in a review, all at once, as a surprise. By then the engineer has been doing the wrong thing for two quarters, believing everything was fine, because the person whose job was to tell them stayed quiet. Withheld feedback is not kindness. It is a debt you are forcing them to pay later, with interest.

Say the actual thing that happened

The single biggest upgrade you can make is to replace judgments with observations. Instead of naming a trait, describe what you saw.

Here is the difference in practice. "You dominated that design review" is a judgment. The engineer can argue with it, and they will. "In the design review this morning, you spoke for about forty of the sixty minutes, and when Priya started to raise a concern you talked over her twice" is an observation. There is nothing to argue with. It is just what happened.

The framework I keep coming back to is old and boring and it works. Situation, behavior, impact. Name the specific situation. Describe the specific behavior you observed, not your interpretation of it. Then explain the impact it had. "In the design review this morning" is the situation. "You spoke for forty of sixty minutes and talked over Priya twice" is the behavior. "The result is that we only heard one design, and Priya is the person closest to that subsystem, so we probably missed the real risks" is the impact.

That last part, the impact, is what gives the feedback its weight. Without it, you are just describing someone's behavior back to them, and they will wonder why you care. The impact is the answer to the "so what." It connects the behavior to a consequence the person actually cares about. A good engineer does not want to accidentally silence the person who knows the most. Once they see that link, the behavior almost changes itself.

Be careful that the impact is real and specific, not inflated. "You talked over Priya and now the whole team thinks you are arrogant" is a threat, not an impact, and it is probably not even true. "We missed the risks Priya was going to raise" is an impact. Stick to what actually followed from the behavior. The moment you exaggerate, the person stops listening to the substance and starts defending themselves against the exaggeration.

Aim at the behavior, never at the person

There is a line you must not cross, and crossing it is the fastest way to make sure nothing changes. Feedback about a behavior invites change. Feedback about a person's identity invites a fight.

"You were unprepared for that meeting" is about a behavior. It stings, but it is fixable, and the person knows exactly what to do next time. "You are careless" is about who they are. There is no action that fixes "careless." All the person can do is either accept a bad label about themselves or reject it and reject you along with it. Almost everyone rejects it. The moment feedback becomes a verdict on their character, a door closes, and whatever useful thing you had to say does not make it through.

This matters even more with your strongest people, because strong engineers have strong identities tied to being good at their jobs. Tell a great engineer they are "not a team player" and you have not given them a growth area. You have attacked the thing they are proud of, and they will spend the conversation defending their self-image instead of hearing you. Tell that same engineer "in the last two sprints you merged three changes to the shared auth module without pinging the other teams who depend on it, and it broke their staging twice," and now you have a specific, fixable thing. Same underlying issue. Completely different outcome.

The rule I hold myself to is this. Separate the person from the behavior, every single time, out loud. "You are a strong engineer, which is exactly why this surprised me" does real work. It tells them the feedback is about a specific gap, not a downgrade of how I see them. It keeps them on my side of the table, looking at the problem together, instead of across the table from me defending themselves.

Give it now, not at review time

Timing changes everything. Feedback has a short shelf life, and most managers let it rot.

The best time to give feedback is right after the thing happened, when the details are fresh for both of you and the stakes are low. A quiet word the same afternoon costs almost nothing and lands cleanly. The same message delivered three months later in a review is a different, worse thing. The details are fuzzy. The person cannot fully remember the meeting you are describing. And it now carries the weight of having been saved up, which makes a small thing feel like a big one.

I try to close the gap to hours, not weeks. If someone dominates a design review in the morning, I say something before the end of the day. Not in front of the team. Just a two-minute conversation. "Hey, quick thing about this morning." The smaller and faster the feedback, the easier it is to give and the easier it is to hear. Feedback saved up for the annual review is the worst of all worlds. It is stale, it is a surprise, and it arrives attached to your rating and your compensation, which guarantees the person is too anxious to actually absorb it.

There is one exception. When you are angry or the moment is hot, wait. Feedback delivered in frustration is almost always aimed at the person, not the behavior, and the other person can feel the heat and stops listening. Sleep on it if you need to. But sleep on it for a night, not a quarter.

Kill the feedback sandwich

Someone taught a generation of managers to bury criticism between two compliments. Say something nice, slip in the hard thing, close with something nice. It feels kind. It does the opposite of what you want.

The sandwich fails for a simple reason. People are not stupid. After they have been sandwiched a few times, they learn that your compliments are just packaging for bad news. Now your praise is worthless, because every time you say something nice they brace for the "but." And the actual message, the thing you needed them to hear, gets lost. You wrapped it so carefully that they walked away remembering the bread and not the filling. I have watched engineers leave a sandwiched conversation genuinely believing they had been praised, when the whole point was to flag a serious problem.

Be direct instead. This does not mean be harsh. It means say the thing plainly, with care, and let it stand on its own. "I want to talk about the incident on Tuesday, because I think there is something to learn from it." No preamble, no fake compliment, no softening that muddies the message. Directness is not the opposite of kindness. Sparing someone a clear message they need is the unkind thing, because it leaves them to fail again.

The care shows up in your tone, your privacy, and the fact that you are having the conversation at all. It does not need to show up as a compliment sandwich. If you genuinely care about the person, say the hard thing clearly, and they will feel both.

Make sure it actually landed

Feedback is not a broadcast. It is a conversation, and the conversation is not over when you finish talking. It is over when you are reasonably sure the message got through the way you meant it.

The most common failure I see, in myself included, is delivering the feedback and then moving on, satisfied that we said it. But you have no idea what the other person actually heard. They might have heard something harsher than you meant and are now quietly crushed. They might have heard something softer and think it was a minor note. They might disagree entirely and have context you are missing. You will not know unless you make space for them to respond.

So after I give feedback, I stop talking and I ask. "How does that land?" "Does that match how you saw it?" "What am I missing?" Then I actually listen, because sometimes the answer changes my mind. More than once I have delivered feedback, asked the question, and learned that the thing I was criticizing had a reason I did not know about. The engineer who "went quiet" in meetings had been told by a previous manager to stop interrupting. The person who missed the deadline had flagged the risk to someone who never passed it on. If I had delivered my feedback and walked off, I would have been confidently wrong and damaged trust for no reason.

Asking also does something subtle and important. It turns the feedback from a thing you are doing to them into a problem you are solving together. That shift, from opponent to partner, is most of what makes feedback stick. People change for people they trust are on their side.

Positive feedback is feedback too, so stop wasting it

Almost everything I have said applies just as much to the good stuff, and most managers are shockingly bad at reinforcing feedback. They think praise is optional, a nice-to-have, something you do to keep morale up. It is not. Positive feedback is one of the most powerful tools you have for shaping behavior, and it is almost free.

The catch is that vague praise is as useless as vague criticism. "Great job this week" changes nothing. The person has no idea what specifically was great, so they cannot do more of it. Praise has to be as specific as criticism to be worth anything. "The way you wrote up that incident, with the timeline and the exact contributing factors and no blame on anyone, made it easy for the whole team to learn from it instead of getting defensive. Do that every time." Now the person knows exactly what worked and will repeat it.

Specific positive feedback is how you get more of the behavior you want without ever having to give the negative version. Catch someone doing the right thing and name it precisely, and you have reinforced it far more effectively than if you had waited for them to do the wrong thing and corrected it. The best-run teams I have been part of ran on a steady stream of specific, genuine, small praise. Not inflated, not constant, not fake. Just noticing when someone did the right thing and saying so, out loud, with detail.

The part everyone skips: follow up

Here is the difference between feedback that changes behavior and feedback that does not, and it is almost never the delivery. It is what happens after.

Most feedback is given once and then forgotten by the person who gave it. The manager says their piece, feels the small relief of having said it, and mentally checks the box. The problem is that behavior change is hard, and one conversation is rarely enough to make it happen. If you never mention it again, you have told the person, implicitly, that it did not really matter. And they will read that signal correctly and go back to what they were doing.

Following up is what proves you meant it. A week or two later, if the behavior improved, say so. "I noticed you pulled Priya into the design discussion early this time, and it caught a real problem. That is exactly it." Now the loop is closed. The person knows you were paying attention, they know the change was noticed, and the new behavior gets reinforced right when it is still fragile. If the behavior did not improve, the follow-up is where you find out why, calmly, before it becomes a bigger issue.

This is also the honest test of whether your feedback was any good. If you followed up and nothing changed, one of a few things is true. The feedback was not specific enough to act on. The person did not actually agree with it. Or there is a constraint you do not understand. All three are useful to know, and you only find them by following up. Feedback without follow-up is not really feedback. It is just a comment.

When it still does not work

Sometimes you do everything right and the behavior still does not change. It is worth being honest about those cases, because the advice above is not magic.

The first thing to check is whether the person actually agrees there is a problem. You cannot feedback someone into changing a behavior they do not believe is wrong. If a senior engineer genuinely thinks dominating design reviews is fine because their designs are usually right, then no amount of well-structured feedback will move them until that underlying belief shifts. That is a deeper conversation about what the team needs from them, not a quick correction. Sometimes the honest outcome is that you disagree, and then you have a different kind of decision to make.

The second thing to check is whether you have the standing to give the feedback at all. Feedback runs on trust. If the person does not believe you have their interests at heart, everything you say sounds like an attack, no matter how carefully you phrase it. This is why the relationship comes first and the feedback second. If I have not invested in someone, my feedback has no foundation to stand on, and I have earned the defensiveness I get. The fix is not better feedback technique. It is going back and building the trust I skipped.

And sometimes, after all of it, the behavior simply does not change, and you are out of the realm of feedback and into the realm of consequences. That is a real part of the job too. But you only get to that point cleanly if you gave the feedback clearly, specifically, and repeatedly first. If you did that, you can act with a clear conscience, and the person is never blindsided.

What it comes down to

Strip away the frameworks and feedback is one simple thing. You are trying to help another person see something they cannot see about themselves, so they can do better, because you are on their side. Everything in this post serves that. The specificity so they know what to change. The focus on behavior so they do not feel attacked. The timing so it is fresh. The directness so the message is not lost. The follow-up so it sticks.

The engineer I told to "be more senior" eventually did become more senior, but not because of that review. It happened later, once I learned to say the actual thing. "In the last three incidents, you fixed the immediate bug but did not go back and fix the class of bug, so we saw the same failure again. I want to see you fix the pattern, not just the instance." That he could act on. And he did.

The feedback that changes behavior is never the feedback that makes you feel like a good manager for having delivered it. It is the specific, slightly uncomfortable, clearly said thing that gives another person something real to do differently tomorrow. Say that thing. Then help them do it.