I have given a lot of feedback over the years, and for a long time I was bad at it. I confused honesty with effectiveness. I thought that if I said the true thing clearly enough, the work would change. It often did not. The engineer would nod, the meeting would end, and the next pull request would look exactly like the last one. The problem was not that my feedback was wrong. The problem was that it never landed.
Feedback that lands changes behavior. Everything else is just talking. In a regulated fintech environment, where a sloppy migration or an unreviewed access change can become an incident with real regulatory weight, the cost of feedback that does not land is not abstract. It compounds. So over time I built a set of habits, mostly through getting it wrong, that make feedback far more likely to actually take hold. None of this is clever. Most of it is just discipline applied consistently.
Separate the Signal From the Noise
The first failure mode is volume. When I started managing, I gave feedback on everything I noticed, because noticing felt like the job. The result was that nobody could tell what mattered. If I commented on a variable name with the same energy I used to flag a missing audit log, the engineer had no way to prioritize. Both arrived as a paragraph in a review thread. Both felt like criticism.
Now I am deliberate about budget. In any given interaction I try to deliver one or two things that genuinely matter and let the rest go, or batch them into a low-stakes note. This is not about softening. It is about preserving the value of my own attention. When I rarely escalate, an escalation means something. When I say "this one is important," people stop and listen, because I have not cried wolf over indentation. Scarcity is what gives feedback its weight.
Be Specific or Be Silent
Vague feedback is the most common kind and the least useful. "Be more proactive," "communicate better," "raise the quality of your work" — these are not feedback, they are verdicts. The recipient hears a judgment about their character with no instruction about what to do differently tomorrow. They cannot act on it, so they either guess or quietly conclude that I do not actually know what I want.
The fix is to anchor every piece of feedback to a specific, observable moment. Not "you need to communicate better" but "in Tuesday's incident channel, the team did not know the payment processor was degraded until forty minutes in, because the first status update came after you had already started mitigating. Next time, post a one-line status before you dig in." That version is harder to write. It requires that I actually remember the event and have paid attention. But it is something a person can do.
If you cannot point to the specific moment that prompted the feedback, you are not giving feedback. You are sharing an impression, and impressions should not be delivered as if they were facts.
Specificity also protects me. When I am forced to cite the exact instance, I sometimes discover that my impression was wrong, or built on a single bad day, or really about something else entirely. The act of grounding the feedback in evidence is a check on my own bias before it ever reaches the other person.
Describe Behavior, Not Character
There is a meaningful difference between "you were careless with that database change" and "the migration went out without a rollback plan." The first is about who someone is. The second is about what happened. People defend their identity reflexively and almost never defend a described action, because the action is just a fact sitting on the table that we can both look at together.
When feedback attacks character, even gently, the recipient spends their energy managing the threat rather than absorbing the lesson. They are calculating whether they are still trusted, whether this is going in a review, whether they need to push back to protect themselves. None of that energy goes toward fixing the thing. Behavioral language keeps the conversation on the work, where it belongs, and where it can actually be resolved.
Time It for Absorption
Good feedback delivered at the wrong moment is wasted. If someone is mid-incident, fighting a production fire at the edge of their competence, that is not the time to mention that their commit messages have been terse. Their working memory is full. Whatever I add will either bounce off or, worse, register as kicking them while they are down.
I think about timing along two axes. The first is proximity: feedback is most useful close to the event, while the details are fresh and the choices are still vivid for both of us. Waiting until a quarterly review to mention something that happened in March is nearly useless, because neither of us remembers the texture of it. The second axis is readiness: the person has to have the spare capacity to actually take it in.
- Right after a shipped feature, when the adrenaline has settled but the memory is sharp, is often ideal for reflective feedback.
- In the middle of a crisis is almost never the right time for anything except direct operational instruction.
- The first hour of someone's morning, before they have context-switched into their day, tends to land better than the last tired hour of the afternoon.
- Immediately after public praise, a critical note can feel like a bait and switch, so I keep those separated.
None of this means delaying hard conversations indefinitely while I wait for a perfect moment that never comes. Avoidance dressed up as timing is still avoidance. It means being deliberate enough not to torpedo a real message with bad scheduling.
Ask Before You Tell
Some of the most effective feedback I have given was not me telling someone anything. It was me asking a question that let them find it themselves. "Walk me through how you decided to skip the staging deploy" usually surfaces the issue faster and more durably than "you should not have skipped staging." When people reach the conclusion on their own, they own it. When I hand it to them, they merely receive it, and received conclusions have a short shelf life.
This is not a manipulation technique where I already know the answer and I am just steering. Often I genuinely do not know why someone made a choice, and the explanation changes my mind, or reveals a process gap that is the actual problem. The engineer who skipped staging may have done so because the staging environment had been broken for two weeks and nobody had time to fix it. That is not a feedback conversation about discipline. That is a tooling problem I now need to own.
Make the Standard Explicit
A lot of feedback fails because it references a standard the recipient never knew existed. I once told an engineer their design doc was incomplete, and they were genuinely confused, because by their previous team's norms it was thorough. The gap was not effort or skill. It was that I had a standard in my head — threat model, rollback strategy, data retention implications — that I had never written down or stated. I was grading against a rubric only I could see.
Now, before I critique work against a standard, I make sure the standard was actually communicated. If it was not, the feedback is on me, not them, and the right move is to articulate the expectation going forward rather than penalize them for missing a target they could not see. In a fintech context this matters enormously, because so much of our quality bar comes from compliance and security requirements that are not obvious from the code alone. Nobody intuits a SOC 2 control. It has to be taught.
Explicit standards also make feedback feel fair, which is what makes people accept it rather than resent it. "This needs a rollback plan because every production migration does, that is our rule" is received very differently from "this needs a rollback plan" delivered as if the person should have known. The first is a standard. The second feels like a personal failing, and people do not improve well when they feel ambushed.
Separate the Coaching From the Verdict
One of the hardest lessons I learned is that day-to-day coaching and formal evaluation cannot share the same channel without poisoning each other. If every piece of feedback I give might end up in a performance review, people stop hearing my coaching as help and start hearing it as evidence being collected against them. They get defensive, they hide their struggles, and the very information I need to help them goes dark.
So I am explicit about which mode I am in. Most of my feedback is coaching: low-stakes, frequent, aimed at making the next piece of work better. It is not going anywhere. It is between us. Evaluation is a separate, deliberate, clearly-flagged event where I summarize patterns over time and where there are stakes. Conflating the two makes coaching scary and makes evaluation feel like an ambush, because the person never saw the pattern being built.
If your evaluation contains a surprise, you have failed as a manager. The review should be a summary of conversations the person has already had, not the first time they hear that something was wrong.
Keeping these channels distinct is what lets me be both generous and demanding. I can coach constantly and gently precisely because the high-stakes judgment lives somewhere else, on a known schedule, with no hidden surprises.
Close the Loop
Feedback is not a one-way transmission that ends when I stop talking. It lands only when I confirm it was received the way I intended and then notice when the behavior actually changes. Far too often I delivered something, assumed it was understood because the person nodded, and was annoyed weeks later when nothing had shifted. The nod is not comprehension. It is frequently just the social signal that ends an uncomfortable conversation.
So I close the loop in two directions. At the end I ask the person to tell me what they took away, in their words, which surfaces the gap between what I said and what they heard with surprising regularity. And then, crucially, when they do change the behavior, I name it. "I noticed you posted a status update first during today's incident — that is exactly what I was hoping for." That acknowledgment is what tells the person the change was seen and mattered, and it is what makes the lesson stick rather than quietly erode.
Without that closing acknowledgment, people reasonably conclude that the feedback was a one-time complaint rather than a real expectation, and they drift back. Reinforcing the change costs me ten seconds and is the single highest-return thing I do in the entire feedback cycle. It is also the part most managers skip, because by then we have moved on to the next problem.
Conclusion
Giving feedback that lands is not about finding the perfect words or the gentlest framing. It is about respecting the constraints of the person receiving it: their limited attention, their need for specifics they can act on, their reflex to defend their identity, and their need to understand the standard they are being held to. When I get those things right, the words almost do not matter, because the conditions for the message to take hold are already in place. When I get them wrong, no amount of careful phrasing saves me. The work that follows tells me everything I need to know about whether it actually landed.