Performance Review Tips for Software Engineers

A performance review is a small piece of writing that has to do a lot of work. It has to give the engineer signal they can act on, it has to hold up when read by HR who don’t know the codebase, and it has to age well when someone else reads it twelve months later for the promotion conversation. Most of the tips below come from watching reviews succeed and fail at those three jobs.

I’ve split the tips into three groups: tactics for managers, tactics for engineers, and the moves both sides should get right. For the deeper framework behind these tips see how to write a performance review for a software engineer.

Tips for managers

1. Keep an evidence diary

The single highest-leverage habit you can build is a one-line note per week per engineer. After a 1:1, after a design review, after an incident: drop one specific thing they did into a doc. Six months later, when you sit down to write the review, you have a hundred specific bullets instead of having to reconstruct the period from memory. The reviews that come out of this practice are unrecognisably better.

2. Write each review at least twice

Write the first draft, then put it aside for a day, then come back and delete every sentence that could appear unchanged in another engineer’s review. The cuts will tell you what actually has signal. The first draft will always have generic prose in it; that’s normal. The second pass is where the review gets sharp.

3. Solve for the calibration conversation

Your review is going to be discussed in a room with other managers. The cases that get supported are the ones with specific evidence. “Strong technical contributor” does not carry weight in calibration. “Led the billing migration end-to-end, design doc referenced by three other teams” does. Write for the room you’re going to defend the review in.

4. Don’t deliver new feedback in the review

If the engineer is hearing a piece of feedback for the first time in writing at review time, something has gone wrong in your 1:1 cadence. The review should be a written summary of conversations the two of you have already had. New feedback belongs in 1:1s, weeks before the review. Reviews are bad places to deliver surprises.

5. Be specific about under-performance

The instinct when an engineer is underperforming is to soften the language so the conversation goes well. That backfires. Vague feedback (“needs to step up”) gives the engineer nothing to act on; specific feedback (“design proposals are typically written after implementation has started, which has caused two re-do cycles this half”) gives them a concrete behaviour to change. Separate the behaviour from the person.

6. Ground every claim in an artefact

For every strength or weakness you name, you should be able to point at a specific PR, design doc, incident, or moment that evidences it. If you can’t, the claim is a hunch, and hunches don’t belong in a review. This habit alone removes most of the prose that reads as AI-generated, because AI-generated reviews are exactly the ones with no artefacts underneath them.

7. Calibrate up and down the seniority ladder, not just sideways

When you write “operating at senior level on technical contribution,” you’re making a claim that requires a mental comparison to other senior engineers in the org. Make the comparison explicit in your own head before you write the line. If you wouldn’t hand this engineer the same scope of work you’d hand to your current strongest senior, the line is probably premature.

Tips for engineers

8. Build your own evidence inventory in week one of the cycle

The single biggest mistake engineers make is leaving the self-eval until the night before it’s due. Half-an-hour at the start of the cycle, building a list of what you’ve shipped and contributed to, makes the actual writing trivial. See the prep step in software engineer self-evaluation examples for the exact list.

9. Read your last review before writing this one

Last cycle’s feedback (your manager’s comments on you, plus your own goals) is the calibration baseline for this cycle. If you set three goals last period and only mention one of them in this self-eval, you’re effectively letting your manager bring the other two up. Better to surface them yourself, including the ones that didn’t go as planned.

10. Lead with the headline

Your manager is reading six self-evals back-to-back during review week. The first sentence of each section needs to be the thing you want them to remember. Don’t bury the senior- promotion case at the end of a 400-word paragraph. The first line of your “biggest impact” answer should literally be the biggest impact.

11. Name your misses, name the fix

The instinct on the “what didn’t go well” prompt is to either skip it (red flag in calibration) or volunteer something vague that sounds like a strength (“I’m too detail-oriented”). Both fail. Naming a real miss with what you’d do differently builds trust and demonstrates judgement; it’s the move that often pushes a promotion case from borderline to clear.

12. Don’t over-correct for modesty

If you led a project, say you led it. “I supported the team in shipping X” when you actually owned X is a miscalibration that costs you. Engineers from cultures or backgrounds that value modesty often under-state contribution by default. The fix isn’t to swing to the other extreme; it’s to describe the work accurately. The role is what it is.

13. Make your goals double as a promotion case

If you’re a mid-level engineer who wants to be senior in 12 months, the goals you set this cycle should be the work that proves you’re senior. “Own a cross-team initiative,” “write the design doc for X,” “mentor a new ramp” are senior-level moves. Vague goals (“continue to grow”) signal you haven’t thought about the next level concretely.

Tips for both sides

14. Have a pre-review conversation

Two weeks before the review, set a 1:1 specifically to talk through what each of you is going to write. The point is not to synchronise the documents; it’s to surface any disconnects before they get written into the formal record. If you both think the half’s biggest impact was project A and you’re going to highlight it, great. If the manager thinks it was project A and the engineer thinks it was project B, that’s a useful conversation to have early.

15. Push back on biases before they land in writing

Three biases that show up in engineering reviews more than managers like to admit: recency (the last sprint counting more than the first three), halo (a strong project bleeding into unrelated bucket assessments), and proximity (the engineer you’ve been in more meetings with feeling stronger than the one whose work is more remote). Both sides should name these explicitly when they spot them.

16. Treat the review as the start of the next cycle, not the end of this one

The post-review conversation is more important than the document itself. The document is a record; the conversation is where next-period direction gets set. Use the conversation to agree on two or three specific things to do differently, write those down somewhere you’ll see them again in a month, and return to them in 1:1s. A review that doesn’t change behaviour was paperwork.

The shape of a review that ages well

A test I sometimes apply: if I read this review twelve months from now, would I be able to picture the half it was written about? The good reviews pass this test. They have specific artefacts named, specific behaviours described, specific forward-looking calls. The weak reviews don’t. They could have been written about any engineer in any half at any company.

That’s the bar. Everything else in this article is in service of it.

For more on the cluster: the manager-side process is in how to write a performance review for a software engineer, worked examples are in performance review examples for software engineers, and the engineer-side counterpart is in software engineer self-evaluation examples.