Giving Feedback

Feedback that's specific, timely, kind and actionable.

Backend Engineer · Mid-level · core Frontend Engineer · Mid-level · core Data Engineer · Mid-level

Also known as: giving feedback to colleagues, constructive feedback, feedback conversation, how to give feedback, peer feedback

Good feedback helps a person improve, and bad feedback damages trust. Giving feedback well means being specific, timely, kind and actionable. It’s useful at every level, from a code review comment to a conversation with a teammate.

A simple structure: situation, behavior, impact

One widely taught model (often called SBI) keeps feedback concrete and about observable facts:

Situation: when and where.
Behavior: what you saw or heard, factually. Not your interpretation of their character.
Impact: the effect it had.
Then, if useful, what could be done differently or a question.

❌ “You’re careless with your pull requests.”

✅ “In yesterday’s PR (situation), the description was empty and the diff included unrelated formatting changes (behavior). It took me twice as long to review, and I wasn’t sure what to focus on (impact). Could you add a short summary and keep formatting changes separate next time?”

The second can be acted on. The first can only be defended against.

Principles

Be specific. Point to an example. “Great job” and “needs work” don’t teach anything.
Be timely. Feedback soon after the event is relevant and fresh. Saving it for a review months later is useless, and unfair.
Be kind and direct. Care about the person and say what you mean. Vague hints leave people unsure there’s a problem.
Focus on behavior, not personality. “The summary missed the cost” vs “you never think about cost”.
Give positive feedback too, and be specific. Saying what worked well helps people repeat it. It shouldn’t be a cushion before criticism, which makes people distrust the praise.
Make it actionable. What should they do differently? Offer help or an example.
Pick the right channel. Praise can be public. Criticism is usually better in private and in person (or on a call), because tone is hard to convey in text. Ask first: “Can I share some feedback on the demo?”
Check your own motives and facts. Do you know the full context? Ask a question before assuming.
Listen to the response. There may be context you didn’t have. It’s a conversation.
Don’t overload. One or two important points beat a long list.

Common mistakes

Waiting until you’re frustrated.
Giving feedback to a third party instead of the person.
Generalizing (“always”, “never”).
Burying the point in softening language.
Giving feedback you wouldn’t want to receive.

In code review, the same ideas apply (giving code review). When people are comfortable with candid feedback, the team learns faster (psychological safety). And remember the other side: receiving feedback well makes it easier for others to give it.