What makes feedback to a software engineer useful?
Engineers work in artifacts: pull requests, design docs, incidents, tickets. Feedback anchored to an artifact can be checked, and feedback that can be checked is hard to dismiss. "Your code quality needs work" invites an argument about what quality means. "[PR] shipped without tests on the error path, and that's the path that failed" does not.
Every phrase below follows the same shape: a specific situation, an observable behavior, the impact, and for constructive feedback a concrete next step. Swap the bracketed parts for your real examples. If you cannot fill in the brackets, you are not ready to give that piece of feedback yet; go find the example first.
One rule for using a phrase bank honestly: these are starting points for your own words. An engineer who hears a sentence that sounds templated will assume the rest of the review was too.
Feedback examples for code quality
Code quality feedback lands best when it points at a specific pull request or module and names the cost or benefit to whoever touches that code next.
Positive
- "Your refactor of [the billing module] split a 900-line file into four pieces with clear boundaries. The next two changes there took a day each instead of a week."
- "The tests you added on [the retry logic] caught a regression in [PR] before it shipped. That's the kind of coverage that pays for itself."
- "Your PR descriptions explain why, not just what. Reviewers approve faster and nobody has to ask you in Slack."
- "You pushed back on adding a new dependency for [feature] and wrote the 40 lines yourself. That kept our attack surface and upgrade burden smaller."
- "Naming in [service] is consistent enough that a new engineer found their way around it in a day."
Constructive
- "Your last three PRs were over 1,000 lines each. Reviews took four days and still missed [bug]. Can you aim for changes a reviewer can finish in 30 minutes?"
- "[PR] shipped without tests on the error path, and that's the path that failed in [incident]. For anything touching payments, error-path tests are part of done."
- "I've seen the same workaround copied into three services. Let's talk about whether it belongs in a shared library, and who owns it."
- "The comments in [module] describe what the code did two versions ago. Out-of-date comments cost more than none. Can you update or remove them as part of the next change?"
- "You're optimizing [query] that runs twice a day. The slow endpoint users actually feel is [endpoint]. Let's point that skill there."
Feedback examples for delivery and estimation
Delivery feedback goes wrong when it sounds like "work faster". Aim it at visibility and planning: when the person raised a risk, how they broke work down, what they did when the estimate broke.
Positive
- "You flagged on day three that [project] would slip by a week and came with two scope cuts. That gave product time to choose instead of finding out at the deadline."
- "You broke [epic] into slices that each shipped on their own. We had something in users' hands after week one."
- "Your estimates this quarter were within 20% on four of five items. People plan around your numbers now."
- "When [dependency] blocked you, you found the owner, agreed a date, and wrote it in the ticket. Nobody had to chase it."
- "You shipped [feature] behind a flag and turned it on gradually. When the edge case showed up, we flipped it off in a minute."
Constructive
- "[Project] was marked on track in standup until two days before the deadline. I'd rather hear 'I'm not sure' in week one than 'it's late' in week four."
- "Your tickets tend to be one large item that stays in progress for two weeks. Can you break the next one into pieces that each finish in two or three days?"
- "You said yes to [request] from [team] without checking our sprint commitments. Next time, bring it to planning so we can decide what moves."
- "The last three estimates were off by 2x or more, all in the same direction. Let's look at what's missing from them, usually testing and review time."
- "You polished [feature] for an extra week after it met the acceptance criteria. Ship it, get feedback, then polish what users actually notice."
Feedback examples for collaboration and code review
Collaboration feedback needs the most care, because it is the easiest to hear as a judgment of personality. Keep it on observable behavior in reviews, meetings and documents.
Positive
- "Your code review comments separate blocking issues from nits. Authors know what has to change and what's optional."
- "You paired with [new hire] on their first two tickets. They shipped to production in their first week."
- "In the [design] review you asked the question nobody else asked, about what happens when [service] is down. It changed the design."
- "You wrote up the [incident] timeline the same day. The postmortem started from facts instead of memory."
- "You disagreed with [decision] in the meeting, said why, and then committed fully when the team went the other way."
Constructive
- "Three engineers mentioned that your review comments read as dismissive, for example '[quoted comment]'. The point was right. Can you add the reason and a suggestion?"
- "PRs assigned to you wait about three days for review. The team's average is under one. If you're overloaded, tell me and we'll rebalance."
- "You fixed [issue] in [team]'s service without telling them. The fix was good, but they found out from an alert. Loop the owners in first."
- "In [meeting] you interrupted [colleague] twice before they finished. I'd like you to let people land their point, then respond."
- "Decisions you make in DMs aren't visible to the rest of the team. Can you post the outcome in the team channel or the ticket?"
Feedback examples for ownership and reliability
Ownership is what separates a senior engineer from a fast one. Feedback here should point at follow-through after the code merged: on-call, monitoring, the boring fix nobody asked for.
Positive
- "After [incident] you didn't stop at the fix. You added the alert that would have caught it and a runbook entry. That's ownership."
- "You noticed [job] failing silently for a week and fixed it without being asked. Nobody else had seen it."
- "On-call was quieter this rotation because you fixed the three noisiest alerts from last time."
- "You took [unglamorous migration] that nobody wanted and finished it. Two teams are unblocked because of it."
- "When [feature] broke for one customer you followed up with support until it was closed, not just until the PR merged."
Constructive
- "[Service] has been your area for six months and there's no dashboard or alert for it. Before the next feature, can you add the basic monitoring?"
- "You merged [change] at 5pm Friday and went offline. When it broke, on-call didn't know the context. Let's avoid end-of-week merges on risky changes."
- "The action items from [postmortem] assigned to you are still open after six weeks. Either close them or tell me they need to be reprioritized."
- "When [bug] came in you said it belonged to another team. It did, partly, but the customer was still waiting. Can you own the coordination even when the fix is elsewhere?"
- "Your documentation for [system] stops at setup. The next person on call won't know how to debug it. Please add the failure modes you know about."
Feedback examples for growth and learning
Growth feedback is where you connect current behavior to the next level. Be explicit about the gap; vague encouragement is how engineers end up surprised in calibration.
Positive
- "Six months ago you avoided [area]. Now you're the person others ask about it."
- "You asked for feedback on your design doc before the review, and the final version was much stronger for it."
- "Your tech talk on [topic] is now the onboarding link for new hires on that system."
- "You took the feedback about review tone from last cycle and changed it. People have noticed."
- "You're starting to think about [system] across teams, not just within ours. That's what the next level looks like."
Constructive
- "To reach senior, you need to lead a project across at least one other team. Let's find one this quarter, and I'll back you if it gets hard."
- "You tend to pick tickets in areas you already know. I'd like you to take the next [area] ticket, with [mentor] as backup."
- "Your technical work is at the next level. Your written communication isn't yet. Let's start with you writing the design doc for [project]."
- "You've mentioned wanting to move into management. The first step is mentoring someone. Would you take [new hire]?"
- "You get frustrated when requirements change and it shows in meetings. Changing requirements are part of the job. Let's talk about how to handle them."
Feedback examples for ai-tool use
This is the newest category and the one most review templates do not cover yet. The principle is simple: the engineer who submits the change owns it, whoever or whatever typed it.
Positive
- "You used [agent] to generate the migration scripts and then wrote tests that caught two mistakes it made. That's the right split of work."
- "Your PR descriptions say which parts were AI-assisted and what you checked by hand. Reviewers know where to look."
- "You set up the prompt and context files for [repo], and the team's AI suggestions got noticeably more relevant."
- "When the AI reviewer flagged 30 issues on [PR], you sorted them by severity and fixed the four that mattered. You didn't let noise slow the merge."
- "You noticed the model was producing a deprecated pattern and wrote it up for the team. That saved everyone from the same mistake."
Constructive
- "In our walkthrough of [PR], you couldn't explain how [function] handled the empty case. If you submit it, you need to be able to explain it, whoever wrote the first draft."
- "Your PR size has roughly tripled since you started using [tool]. Reviewers can't keep up. Please keep changes small even when generating code is fast."
- "[Generated code] included a hard-coded credential pattern that review caught. Treat generated code like code from a new contractor: read every line."
- "You're dismissing every AI review comment without reading them. Some are noise, but [comment] would have caught [bug]. Skim for the high-severity ones."
- "You've stopped writing design notes since you started using agents. The agent doesn't remember why we chose [approach]. The notes are for the next human."
How do you give feedback without making an engineer defensive?
Describe what happened before you say what it means. Defensiveness usually starts when the listener hears a verdict about who they are ("careless", "not a team player") instead of a description of something they did. Engineers are trained to debug claims, and a claim about character has no stack trace they can inspect.
The Center for Creative Leadership's Situation-Behavior-Impact model gives you the structure:
- Situation: when and where. "In Tuesday's design review for the search rewrite..."
- Behavior: what you observed, without interpretation. "...you said the caching proposal 'wouldn't work' and moved to the next item..."
- Impact: what it caused. "...and Priya didn't raise her concern about cache invalidation, which came up again in the incident last week."
CCL also describes an extended version that adds a fourth step: ask about intent. "What was going on for you there?" Often there is a reason you did not know about, like time pressure or an earlier conversation. Asking turns a monologue into a conversation and gives the engineer a way to engage that is not a defense.
Rewrites that lower the temperature
| Triggers defensiveness | Say this instead | Why it works |
|---|---|---|
| "You're always late with reviews." | "Your last five review requests waited three days on average." | "Always" invites a counterexample. A number invites a conversation. |
| "You need to be more proactive." | "The [job] failure ran for a week. I'd like you to own the alerting for services you build." | Names the gap and the expected behavior instead of a trait. |
| "Your code is sloppy." | "[PR] had no tests on the error path, and that path failed in production." | Points at the artifact, which the engineer can verify. |
| "People find you difficult." | "Three reviewers mentioned your comment on [PR] read as dismissive. Here it is." | Specific and sourced, without naming who said it. |
| "Good job this quarter!" | "Flagging the slip on day three gave product a real choice. Keep doing that." | Positive feedback also needs specifics, or nobody knows what to repeat. |
Habits that matter more than the script
- Give it soon. Within a few days, while both of you remember the details.
- Give it in private for anything constructive. Praise can be public if the engineer is comfortable with that.
- One topic per conversation. Stacking three issues makes the engineer defend all three and fix none.
- Earn it with positive feedback. If the only time you are specific is when something went wrong, every specific comment will sound like a warning.
- Ask what would help. Sometimes the fix is on your side: unclear priorities, an overloaded sprint, a missing reviewer.
Kim Scott's Radical Candor frames the balance as caring personally while challenging directly. Most managers who struggle with feedback lean too far toward one of the two. The SBI structure helps with the challenge; the habits above help with the care.
How do you turn these phrases into a performance review?
A written review is a summary of feedback already given, organized by your company's competencies. For each competency, write evidence, impact and expectation:
Evidence: "Led the payments retry redesign across two teams; shipped in six weeks."
Impact: "Failed-payment tickets dropped noticeably in the following month, and the design doc is now the template for cross-team changes."
Expectation: "At senior level, we expect this scope as the norm. Next cycle: lead one project without needing me to unblock other teams."
Two checks before you submit. First, would the engineer be surprised by anything here? If yes, have that conversation before the review lands. Second, read the reviews for your whole team side by side. If the women get "helpful" and "collaborative" while the men get "technical" and "strong", or if one person's review is all adjectives and another's is all evidence, fix it before calibration does it for you.
If feedback keeps landing badly across the whole team, the problem may not be the phrasing. Silence in retros and defensiveness in 1:1s are both on the list of signs an engineering team is failing. And if you are the one running out of energy for these conversations, read about engineering manager burnout.
Related Guides
Signs Your Engineering Team Is Failing
The quiet signals, their likely causes, and the first move for each.
Engineering Manager Interview Questions
26 leadership questions with strong vs weak answers and a scoring rubric.
CTO Delegation Framework
What to own, what to hand off, and how to widen the boundary over time.
Engineering Manager Burnout
Warning signs, recovery, and what CTOs can do before it starts.
AI Code Review (aistrategy.guide)
How AI changes code review, and where human reviewers still matter.
Sources
- Center for Creative Leadership, Use Situation-Behavior-Impact (SBI) to Understand Intent: the SBI model and the intent step.
- Kim Scott, Radical Candor: caring personally while challenging directly.
- Douglas Stone and Sheila Heen, Thanks for the Feedback (Viking, 2014): why people resist feedback and how receivers can work with it.
Frequently Asked Questions
What is a good example of constructive feedback for a software engineer?
How do you write a performance review for a software engineer?
How often should engineering managers give feedback?
What is the SBI feedback model?
How should managers give feedback about AI coding tool use?
