Guides for engineering managers
Performance review examples for software engineers
Side-by-side weak and stronger examples for every part of an engineering review, from impact to growth areas.
- A good review paragraph names what the person did, gives an example with a date or project, and says why it mattered.
- Below are weak and stronger versions for impact, code quality, collaboration, ownership, communication, and growth areas.
- Copy the shape, not the words. The specifics are what make a review useful.
Most review examples online are lists of phrases: "consistently delivers high-quality code", "a strong team player". Phrases like these are why reviews feel generic. An engineer can't act on them, and a promotion committee can't weigh them.
Below are examples of the paragraphs that actually go into an engineering review, each shown first as a typical weak version and then as a stronger one. The names and projects are made up. What matters is the shape: behaviour, example, effect.
Impact and delivery
Alex delivered a lot this half and was very productive.
Alex led the move from nightly batch exports to streaming (April to June), which customers had asked for in a third of churn interviews. He scoped it into three releases so we could ship value in weeks instead of one big launch, and the first release alone cut report freshness from 24 hours to under five minutes.
Code quality and technical judgement
Sam writes clean code and has good technical skills.
Sam's design doc for the permissions rewrite was the best this half: it compared three approaches, was explicit about what we were giving up, and got sign-off in one review. Since it shipped we have had no permission-related incidents, after four in the previous quarter. Sam also added the integration tests that caught two regressions before release.
Collaboration and code review
Jordan is a great team player and always willing to help.
Jordan reviewed more of the team's pull requests than anyone else this half, and the reviews teach as well as catch: newer engineers cited them twice in peer feedback as how they learned our data layer. When Mei joined in July, Jordan paired with her for her first two weeks and she shipped her first feature by week three.
Ownership and reliability
Taylor takes ownership and is reliable.
When the payment webhook incident hit on a Saturday in August, Taylor coordinated the response, kept the incident channel updated every 30 minutes, and wrote the postmortem by Tuesday. Two of its four follow-up actions were Taylor's own, and both are done. The retry policy change has removed that class of incident since.
Communication
Chris communicates well with stakeholders.
Chris's weekly update on the onboarding project became the template other teams now copy: three lines on progress, one on risks, one on what he needs. Sales told us they stopped asking engineering for status because the update already answered it.
Growth areas
Growth areas are where reviews most often go wrong. The goal is something the person recognises and can work on, not a label.
Morgan needs to work on time management.
On both the search and billing projects, Morgan's estimates were about twice as long in reality, and the team found out at the deadline. The work itself was strong. Next half, I'd like Morgan to break projects into milestones of a week or less and flag in the project channel when any milestone slips, even by a day. I'll review the first plan with him.
Riley should be more of a leader.
Riley is consistently the strongest debugger on the team, but most of that knowledge stays with her: in two incidents this half, the fix depended on her being online. To reach senior, I'd like Riley to spread it: write runbooks for the two systems she knows best, and lead one incident review as facilitator rather than fixer.
A summary paragraph
Priya operated at the senior level throughout this half. She drove the payments migration from design to launch, mentored two newer engineers through their first on-call rotations, and her reviews set the quality bar for the team. Her main growth area is scope: she tends to absorb work herself instead of delegating it, which made her the bottleneck in July. Rating: exceeds expectations. Next half she will lead the reconciliation project with two engineers, with the goal of shipping it without being on the critical path herself.
What makes these work
- A real example in every claim. A project, a date, a number or a named outcome.
- Outcomes, not activity. What changed for users or the team, not how many tickets moved.
- Invisible work counted. Reviews, mentoring and incident leadership are written up as real contributions.
- Growth areas with a next step the person can act on, and what the manager will do to help.
The hard part isn't the writing. It's having the examples on hand when you sit down. If you're starting from memory, see how to keep a brag doc for your whole team, and use the structure in how to write an engineering performance review.