No one teaches engineers how to give feedback. We spend years learning data structures, design patterns, and deployment pipelines, and then one day a colleague submits a pull request that makes our teeth clench — and we have no idea what to do with that feeling. We either say nothing (the path of least resistance), or we say something that lands like a brick: terse, harsh, and somehow personal, even when we didn't mean it to be.
The same applies in reverse. When a lead tells you "this code is too complicated" or a peer says "I'm not sure about this approach", our nervous systems treat it like a threat. Defences go up. We justify, we deflect, or we sit in quiet resentment for the rest of the sprint. Neither helps us grow.
This guide is a field manual for both sides of that conversation. We'll look at what makes feedback actually work, walk through ready-to-use scripts for awkward situations, and cover how to receive critique without losing your composure. Whether you're a new grad giving your first code review or a staff engineer trying to make feedback feel safe on your team, there's something here for you.
Why feedback feels so hard
Feedback is a social act wearing a professional costume. On the surface it's about code or a design decision. Underneath, it often touches identity — the story we tell ourselves about how capable we are. When someone questions our work, the brain's threat-detection machinery can't always tell the difference between "this function is too long" and "you are not good enough".
Two fears tend to dominate:
- Fear of conflict (for the giver). What if they push back? What if it gets awkward? What if they think I'm being unfair? Engineers who skew introvert — and that's many of us — often prefer the temporary comfort of silence over the short-term discomfort of honesty.
- Fear of looking incompetent (for the receiver). Especially when you're junior, or new to a team, or in the middle of proving yourself, critique can feel like evidence for the worst thing you suspect about yourself.
Here's the uncomfortable truth: avoiding feedback doesn't make those feelings go away. It just lets problems compound. The junior engineer who never gets honest signals keeps building the same habits. The senior engineer whose architectural choices are never questioned ships increasingly fragile systems. The team that avoids hard conversations eventually has them — just at the worst possible moment, under the worst possible pressure.
Research on psychological safety — most famously Amy Edmondson's work at Google and Harvard — consistently shows that teams where it is safe to speak up outperform teams where it is not. Not because those teams always agree, but because they surface problems fast enough to fix them. Withheld feedback is a hidden debt: invisible until it compounds into something expensive.
The good news is that giving and receiving feedback are skills, not traits. They can be practised, and a small improvement in how you phrase a comment or how you respond to critique makes a measurable difference to your working relationships.
What good feedback actually looks like
Before we get to scripts, it helps to understand what we're aiming for. Good feedback has four properties:
- Specific. It names something concrete — a file, a function, a phrasing, a behaviour in a meeting — rather than gesturing at a vague feeling. "This service does too much" is a starting point; "the
UserServicehandles both authentication and profile updates, and that makes it hard to test either in isolation" is feedback someone can act on. - Timely. Feedback given soon after the event is more useful and less emotionally loaded than feedback delivered weeks later, when context has faded and the work has moved on. Code review comments land best while the author still remembers the reasoning. One-on-one observations land best in the week they happen.
- About behaviour or work — not about the person. There is a meaningful difference between "you always overcomplicate things" (an attack on character) and "in the last three PRs I've seen, the data transformation logic was split across multiple abstraction layers, which made it hard to follow" (an observation about work). The first puts someone on trial. The second gives them something to examine.
- Actionable. Good feedback implies (or states) a path forward. "This is hard to read" leaves someone stuck. "Extracting the mapping logic into a named function with a clear return type would make this easier to follow" gives them a next step.
The SBI model
A simple structure that holds all four of those properties together is the Situation–Behaviour–Impact model, originally developed for leadership training and now used widely in software teams. You don't need to deploy it robotically on every comment, but it's a reliable scaffold when you're not sure how to start.
In practice, SBI sounds like this: "In yesterday's incident review [situation], when you interrupted the on-call engineer three times while they were explaining their findings [behaviour], it made it harder for the team to follow the timeline and I noticed the on-call engineer stopped contributing after that [impact]."
Notice that none of those three parts judge intent ("you were trying to dominate the room"), assign personality traits ("you're dismissive"), or generalise ("you always do this"). It describes what happened, factually, and what followed from it. That's why it tends to land without triggering a defensive shutdown.
Ready-to-use scripts: from vague to specific
Most of us have an instinctive reaction to someone else's work — a feeling that something is off, or could be better — before we have the words for it. The challenge is translating that instinct into feedback the other person can actually use. The table below shows common vague or loaded reactions alongside cleaner, specific alternatives.
| What you instinctively want to say | What lands better (and why) |
|---|---|
| "This is too complicated." | "The parseConfig function is doing three things: reading env vars, validating the schema, and setting defaults. Splitting those into separate functions would make each one easier to test and reason about." — Names exactly what is complex and suggests the fix. |
| "I don't like this approach." | "I'm wondering if polling every 500 ms will put too much pressure on the database at our current traffic volume — have you considered a webhook or a queue-based approach here?" — Grounds the concern in a specific risk and opens dialogue. |
| "You always miss the edge cases." | "In this PR I noticed there's no handling for an empty array in processItems — it would throw a TypeError at line 42. Can we add a guard clause or a test for that?" — Removes "always", ties to the specific instance. |
| "This needs a complete rewrite." | "The coupling between the data layer and the presentation layer in this component makes it hard to change either without touching both. Before we merge, could we extract the data-fetching logic into a custom hook?" — Names the structural issue and proposes a concrete first step. |
| "I disagree with this." | "My concern with this decision is that it ties us to a sync interface, which could block the event loop under load. Can you help me understand the tradeoffs you weighed?" — States the concern, invites the other person's reasoning. |
| "Good job." (and nothing else) | "The way you structured the error boundary in DataTable is really clean — it handles both network errors and parsing failures without leaking implementation details up the tree. That's a pattern worth copying." — See the next section on why praise needs specificity too. |
Before you post a review comment, try reading it back as if you were the author who just got it. Ask: do I know exactly what to change, and why? If either answer is "not really", add one sentence of specificity. You'll be surprised how often a single added sentence turns "confusing" into "actionable".
Praise is feedback too
Engineers are often more comfortable pointing out problems than acknowledging what's working. But positive feedback — when it's specific — is one of the highest-leverage things you can give a teammate. It tells them what to keep doing, which is as useful as knowing what to stop.
The trap is vague praise. "Great work on the migration" is better than nothing, but it doesn't teach anyone anything. What specifically was great? The thoroughness of the rollback plan? The way you communicated the status to stakeholders? The fact that you ran the migration in a canary before touching production? Each of those is a different lesson, and naming it makes it repeatable.
A few principles for praise that actually lands:
- Be specific about the behaviour. Use the same SBI structure: "In the incident review on Wednesday, when you walked through the failure mode step by step, it helped the whole team understand the root cause quickly."
- Name the impact. "The clear rollback plan you wrote meant that when we hit the edge case, the on-call engineer knew exactly what to do. That saved us at least 40 minutes of confusion."
- Make it public when it's deserved. Private praise is meaningful. Public praise — in a team channel, in a retrospective, in a group code review — signals to the whole team what excellent looks like. It also means a lot to the person on the receiving end, especially if they're junior or newer to the company.
- Don't delay it. Praise decays in value just like constructive feedback. If you notice someone doing something well, say it that week.
There's a good reason that code review culture guides often specifically call out the importance of positive comments: a PR that only ever has critical observations starts to feel like a minefield, even when all the observations are fair. A comment that says "I like this abstraction — clean" costs you five seconds and can shift the entire emotional tone of a review.
Receiving feedback well
If giving feedback well is hard, receiving it well might be harder. Critique arrives while you're emotionally invested in the work. It sometimes comes with poor delivery — blunt, unclear, or even unkind. And the gap between "someone is criticising my code" and "someone is criticising me" is narrower than we'd like it to be, neurologically speaking.
Here is a five-step practice that helps:
- Assume good intent until proven otherwise. Most engineers who leave critical review comments are trying to make the code better, not trying to make you feel bad. Start there. If the delivery is rough, separate the delivery from the signal — one can be poor while the other is valuable.
- Pause before responding. If you feel a spike of defensiveness, that's information: the feedback touched something real. Don't react from that spike. Take a breath. Read the comment again in 10 minutes. If it's a spoken conversation, it's fine to say "let me think about that".
- Ask clarifying questions. If the feedback is vague — "this feels overengineered" — you're entitled to ask for specifics. "Which part specifically feels overengineered to you? Is it the number of abstractions, the interface surface area, or something else?" This isn't a challenge; it's how you get feedback you can act on.
- Separate signal from delivery. Someone can be right about the substance and wrong about how they said it. Your job is to extract the useful signal and decide whether to act on it. You don't have to reward bad delivery, but you also don't have to let it block you from learning something true.
- Say thank you. Even if you disagree with the feedback, acknowledging that someone took the time to offer a perspective is good practice. "Thanks for flagging this — I'll think it over" is honest and closes the loop without committing you to agreement.
Receiving feedback well doesn't mean accepting all of it. You're allowed to disagree. The key is to disagree with evidence, not with emotion. "I see the concern, but I went with this approach because X — does that address it?" is a healthy response. Silence followed by ignoring the feedback is not — it shuts down the loop and teaches the person who gave it that speaking up isn't worth the effort.
Giving feedback upward and to peers
Most feedback guidance is written from the perspective of someone senior giving feedback to someone junior. But two of the most important — and under-discussed — directions are peer-to-peer and upward.
Peer feedback
Giving honest feedback to a colleague at the same level can feel awkward because there's no formal authority to hide behind. It can feel like overstepping. It isn't. Peer feedback, delivered well, is one of the most valued things on a high-performing team.
A few things that help: frame it as a question when you're uncertain ("I noticed X — is that intentional?"), give it in a one-on-one context before a public forum, and focus on the work rather than the person. If you have an ongoing working relationship, the investment in honest feedback builds trust over time. People who always tell you what you want to hear are pleasant; people who tell you the truth are useful.
Upward feedback
Giving feedback to your manager or tech lead is genuinely harder. There is a power asymmetry, and even the most psychologically safe team can't fully erase it. Some practical approaches:
- Use one-on-ones. Private conversations are the right venue. Don't give feedback that touches your manager's behaviour in a team meeting — that's unfair to them and creates an audience neither of you needs.
- Focus on impact, not character. "When the scope of the sprint changes in the last two days, I find it hard to prioritise well — is there a way to lock scope a bit earlier?" is easier to hear than "you keep changing the scope at the last minute". The first describes a problem to solve together; the second sounds like an accusation.
- Be specific and forward-looking. Name what happened once or twice — not a generalised pattern — and describe what would help. Leaders who receive feedback this way almost always respond better than to vague dissatisfaction.
- Pick your moment. Don't give upward feedback when your manager is mid-crisis, under deadline pressure, or visibly stressed. A calm one-on-one — not the one five minutes before a board meeting — is when this lands.
Feedback by context and team size
Not all feedback happens in the same setting, and the right approach shifts depending on where you are.
In code review
Code review is the most common feedback channel for most engineers, and it has its own norms. Written comments are asynchronous, re-readable, and permanent — which means they need more care, not less. A comment that would be fine in person ("this is a bit long") can read as cold or dismissive in a PR. Adding a sentence of context ("this is a bit long — extracting the validation logic into its own function might help readability") costs little and helps a lot. See the companion post on reviewing code kindly for a deeper dive into this specific context.
In one-on-ones
One-on-ones are the natural home for feedback that is more personal, more sensitive, or more longitudinal — patterns over time, career direction, interpersonal dynamics. The synchronous, private nature means you can watch for how the other person is receiving it and adjust. Prepare one or two specific points rather than arriving with a list of grievances accumulated over months.
In incident reviews (blameless post-mortems)
Incident reviews are a specialised feedback context with one non-negotiable rule: blameless. The goal is to understand what happened and improve systems, not to assign fault to individuals. In practice, this means the feedback is directed at processes, tooling, and knowledge gaps — not at people. "Our alerting didn't catch the memory leak early enough — should we add a threshold alert?" is the right register. "Why didn't you catch this?" is not. Teams that master blameless retrospectives get dramatically better at learning from failure.
By team size
Small teams (under ten people) often have informal feedback cultures — things get said in conversation, in shared Slack threads, over lunch. That informality is a feature: feedback happens fast and frequently. The risk is that it can also become inconsistent or unequal, where some people get a lot of honest input and others get none. As teams grow, a light structure — regular one-on-ones, explicit retro time, written PR norms — helps ensure feedback is distributed equitably rather than flowing only along existing social lines.
Key takeaways
- Avoiding feedback is not neutral — it lets problems compound and erodes trust over time.
- Good feedback is specific, timely, about work (not character), and actionable. The SBI model (Situation–Behaviour–Impact) gives you a reliable structure.
- Translate vague instincts into concrete observations. Name the file, the function, the meeting, the behaviour — not the general feeling.
- Praise is feedback too. Specific, public praise teaches the team what excellent looks like and is worth giving deliberately.
- To receive well: assume good intent, pause, ask clarifying questions, separate signal from delivery, say thank you.
- Upward and peer feedback follow the same rules — use one-on-ones, focus on impact, be specific and forward-looking.
- Context matters: code review, one-on-ones, and incident reviews each have their own norms. Blameless post-mortems direct feedback at systems, not people.
Feedback culture is built one conversation at a time. Start with the next PR you review: add one specific positive comment alongside your critiques, and try framing one observation in SBI. Over a few months, that habit changes how the whole team communicates. When you're ready to invest more deeply in the human side of engineering, continue with Mentoring Engineers — a look at how to help someone grow over the longer arc of their career.