Feedback is a habit, not an event
The feedback that changes behavior is small, close to the moment, and boringly frequent. The feedback that damages people is saved up and delivered all at once. How I give it, and the sentence I use to start.
The worst feedback I ever gave was accurate, well organized, and six months late. I had been noticing that a senior engineer on my team dismissed ideas from junior people in design reviews. I noted it. I meant to bring it up. Then the performance cycle arrived and I put all of it, every instance, in the written review.
He read it as an ambush, because it was one. Six months of examples he had never heard about, delivered in the document that determined his rating. We spent the next quarter rebuilding trust that I had spent with one paragraph.
I do not save feedback anymore.
Close to the moment, small, and often
The feedback that works is delivered within a day or two of the thing, is about one thing, and takes about ninety seconds. "In the design review yesterday, when Priya suggested the queue, you moved on before she finished the sentence. I do not think you meant to shut her down, but it read that way to the room. Worth watching."
That is the whole intervention. No meeting request, no document, no framework. Just a specific observation, close to the event, with the impact named. Most people fix it after hearing it once, because most people do not know they are doing it.
The frequency is what makes it safe. If the only feedback someone gets from me is critical, each instance is a big deal. If they hear something from me every week, most of it neutral or positive, the critical ones land as information rather than verdicts.
The sentence I start with
I open almost every piece of corrective feedback the same way: "Can I give you some feedback on something I noticed?" Then I wait for the yes.
It sounds like a formality and it is not. Asking gives the person a moment to get ready, and it turns the next sentence into something they agreed to hear rather than something that was done to them. Nobody has ever said no. Several people have said "give me five minutes," and those five minutes made the conversation better.
Observation, impact, then stop
The structure I use is short. What I observed, in specific terms, with no interpretation of motive. What the impact was, on me or the team or the work. Then I stop and let them respond.
The stopping is the hard part. The urge is to soften, to explain, to pile on context until the point is buried. Or to prescribe: here is what you should do instead. I try to do neither. The observation and the impact are enough for a capable adult to figure out the rest, and the fix they come up with will stick better than mine.
Feedback upward and sideways
The same structure works on my own manager and on peers, with one addition: I say what I want. "When the priorities changed on Friday afternoon without a heads up, the team lost the weekend planning they had done. Next time I would like fifteen minutes of notice, even if it is just a message." Managers get remarkably little direct feedback and most of them take it well when it comes with a request attached.
The feedback I do not give
There is a category of feedback that is really just my preference dressed up as a standard. I would have named the variable differently. I would have written the update with fewer words. Those are not feedback, they are taste, and delivering them as feedback teaches people to write for me instead of for the reader.
The test I use is whether I can name the impact on someone other than myself. If I cannot, I keep it.
What changed with AI in the loop
Once the tools were producing a large share of the code, feedback shifted from the code to the judgment around it. "This function is too long" stopped being useful, because the tool would happily produce a shorter one. What mattered was: did you understand what this change does, did you notice that the generated test does not test the failure case, did you consider whether this needed to be built at all.
Those are harder conversations and they happen in review, in the moment, which is exactly where feedback belongs. The engineers who grew fastest that year were the ones who got a comment like that on almost every pull request for a month and then did not need them anymore.