Guides for engineering managers
How to write an engineering performance review (with a template)
A practical process for engineering managers: gather the evidence, decide the rating, then write something specific and fair. Includes a template you can copy.
- Decide the rating before you write, from evidence, against your company's written expectations for the level.
- Use one structure for every person: summary, impact, how they work, growth, and what's next.
- Every claim gets an example: what they did, when, and what changed because of it.
- Most of the work happens before review season. Keep notes as the half goes, or you will be writing from memory.
Writing a performance review for an engineer is hard for a boring reason: you have to summarise six months of someone's work, fairly, in about a page, and you probably remember the last six weeks best. The result is reviews that are vague ("great team player"), lopsided toward recent events, or quietly unfair to the people whose work is least visible.
This guide is the process we'd hand a new engineering manager writing their first review cycle. It works for a small startup with no HR process and for a company with a formal ladder.
Before you write: collect the evidence
The quality of a review is set before you write a word. Spend an hour per person gathering material:
- The work itself. The projects they shipped or drove, big pull requests, design docs, incident write-ups, and tickets they closed. Look across the whole period, not the last month.
- How they worked with others. Code reviews they gave, people they unblocked, questions they answered in Slack, interviews and onboarding they did. This is the work that rarely shows up anywhere, and it is often what separates levels.
- Your 1:1 notes. What they said they wanted to grow in last time, and what you agreed.
- Peer feedback, if your process collects it. Look for patterns, not single comments.
- Their self-review. Read it before you write, so you can respond to their view instead of talking past it.
As you go, write each item as one line: what happened, when, and what changed because of it. "Led the billing migration (May to July); cut failed charges from about 40 a week to near zero" is evidence. "Strong on billing" is not.
Decide the rating first, then write
If your company uses ratings or level expectations, decide where the person sits before writing the narrative. Lay your evidence against the written expectations for their level, one area at a time. If you write first, the text drifts toward whatever you remember most vividly, and the rating follows the text.
If you don't have a career ladder yet, a simple version is enough for a review: for each level, two or three sentences on scope (task, feature, system, team), autonomy, and influence on others. Even a rough ladder makes reviews far more consistent across people.
A structure that works
Use the same five sections for everyone on the team. It makes reviews faster to write and fairer to compare.
Engineering performance review template
- Summary (2 to 3 sentences). The overall picture and the rating, stated plainly. Someone who reads only this should know where they stand.
- Impact. The two to four most important things they delivered and why they mattered to users, the team, or the business.
- How they work. Collaboration, code review, communication, ownership, reliability. Specific examples, good and bad.
- Growth areas (one or two). The most important thing to work on, with an example of where it showed up and what "better" would look like.
- Next period. Concrete goals, and what you will do to support them.
Writing each section
Summary
Lead with the conclusion. "Priya consistently operated at the senior level this half, and was the main reason the payments migration shipped on time. Rating: exceeds expectations." Nobody should have to read to the end to find out how they did.
Impact
Pick the few things that mattered most, not everything they did. For each one, say what they did, the result, and what it says about their level. Prefer outcomes over activity: "reduced p95 checkout latency from 1.8s to 600ms" over "worked on performance". If the outcome isn't measurable, describe what changed: who stopped being blocked, which recurring incident went away.
How they work
This is where invisible work belongs. The engineer who reviews half the team's pull requests, writes the onboarding doc, or calms down every incident channel is doing real work that no ticket tracks. Name it, with examples, so it counts.
Growth areas
One or two, not a list of everything imperfect. Make each one specific and observable:
Weak: "Needs to communicate better."
Better: "On the search rewrite, the team learned about the two-week slip in the sprint demo. Next time, flag the risk in the project channel as soon as you see it, even before you have a fix."
Next period
Turn the growth areas into goals they can actually work on, and write down what you will do: the project you'll put them on, the person you'll pair them with, the meeting they'll start running.
Common mistakes
- Recency bias. The last six weeks crowd out the first four months. The fix is evidence collected across the whole period.
- Vague praise. "Great teammate" tells them nothing and helps no promotion case. Every compliment needs an example.
- Surprises. Nothing negative in a review should be news. If it is, the feedback should have happened in a 1:1 months ago.
- Personality instead of behaviour. "Abrasive" is a judgement. "In three design reviews this quarter, pushed back on ideas before asking what problem they solved" is something they can change.
- Counting activity. Commits and tickets closed are poor proxies for impact, and engineers rightly distrust reviews built on them. Use activity to jog your memory, then write about outcomes.
- Uneven effort. The people you worry about get two pages; your quiet steady performers get three lines. They notice.
Make next cycle easier
The single biggest improvement is to stop starting from zero. Keep a short running note per person: after a 1:1, after a launch, when you see a great code review, write one line with the date. We describe a lightweight way to do this in Brag docs for your whole team, and you can see how the finished paragraphs read in our performance review examples for software engineers.