A useful performance review for a software engineer is a two-way conversation, not a verdict. The engineer brings a self-review, the manager brings specific examples, and you both leave with two or three measurable goals you agreed to and a written record of them. Below is how I run one, the template I fill in, and what specific feedback sounds like next to the vague kind.
Since taking over an engineering team earlier this year, performance reviews have gone from something that happens to me to something I’m responsible for running. I’m writing this partly to organise my own thinking, so take it as notes from someone figuring it out rather than gospel.
Why bother with reviews at all?#
The purpose, at any level, comes down to two things: help people keep learning, and make sure the ones performing beyond their role actually get rewarded for it.
Plenty of small companies claim they don’t have the time or resources for reviews, and quietly fall back on tenure as the only signal for who’s ready for a senior role. That’s a mistake, and not just because tenure is a lazy metric. Skipping reviews removes the two-way channel between employer and employee, and the working relationship suffers for it.
It cuts in both directions. An engineer can be working in what they honestly believe is the best way for the company while their habits, methods, or communication style drift somewhere unhelpful — without feedback, nobody catches it. And employers who never hear from their people in a structured way stay comfortably oblivious to what those people actually think of the company.
What each side should walk in expecting#
From the employee’s side the list isn’t complicated. They want to know how their work lines up with the team’s goals, what they’re doing well, and where to improve — specifically, not “communicate better”. They want their contributions recognised, a real conversation about career progression and training, and a process that’s fair and based on their work rather than office politics.
From my side of the table, I expect people to arrive with a self-assessment: their own view of what went well and what didn’t. I’m hoping for openness to feedback rather than a defence lawyer’s opening statement, a genuine discussion about future goals, and honest insight into how they feel they fit into the team. Reviews are also when I do my own planning — team composition, potential promotions, who needs what kind of development.
One framework won’t fit every engineer#
Engineering teams span different cultural backgrounds, experience levels, and specialities, and the same review script doesn’t work for everyone. Equal treatment and fair treatment aren’t the same thing; the approach has to flex with each person’s needs, career stage, and contribution. The baseline is making sure every engineer’s role and responsibilities are clearly defined and actually match their compensation.
The place this bites hardest is titles and pay. When someone is unsure about their title or feels ready for promotion, vague encouragement is poison. What works is concrete: agree on specific challenges or project goals that serve as the benchmark for the next rank, so advancement has objective criteria instead of vibes. Same for compensation — if someone feels underpaid or wants more responsibility, put measurable targets into their plan that spell out what needs to happen before the next review to justify the change. Then actually hold both sides to it at that review.
Improvement feedback needs the same treatment. A specific training programme, workshop, or project aimed at a specific gap is useful. “Keep growing your skills” is not.
Benchmarks start at the first meeting#
The first review meeting with a new report is mostly about setting the baseline. Walk through what the role actually involves and how it feeds team and company goals. Agree on the measurable outcomes performance will be judged against. Set goals for the near term and further out. It’s also the right moment to talk about culture and expected behaviour, how and when feedback will arrive, what resources and mentorship are available, and what the career path from their seat looks like. None of this is thrilling, but every later review is easier because it happened.
The agenda I use after that#
- Small talk. It sounds trivial, but it takes the tension out of the room, and the rest of the conversation is more honest for it.
- Run through the agenda so nobody gets ambushed by a topic.
- Growth since the last review — name the progress explicitly. People rarely notice their own.
- Current performance, strengths first.
- Areas for improvement, each with a specific, realistic target attached.
- Career plans, and whether the current work actually points at them.
- Targets, goals, and actionable items for the next review.
KPIs only work if they’re personal#
For engineers on a product team, KPIs have to fit both the team’s objectives and the individual. Front-end, back-end, and full-stack roles differ; junior and senior roles differ more. Commit volume might tell you something about a junior developer, and it tells you nothing about a senior engineer whose main output is architectural decisions. That’s why KPIs get set in a conversation, not copied from a template.
The areas I look at:
- Quality of code: error rates, adherence to standards, how often their work needs bug fixes
- Project delivery: milestones and deadlines met
- Innovation and problem solving: efficiency improvements, hard problems actually resolved
- Collaboration: peer reviews, contribution to team goals and discussions
- Personal development: learning goals hit, certifications, new technologies picked up
- Customer impact: feedback from users, engagement with the features they shipped
On the measurable side, unit testing is an input I’ve been warming to. This article from InfoQ looks at folding unit testing into performance reviews — the mechanics of it, and what it does to team culture — and argues for mixing qualitative and quantitative measures of code health. Worth a read if you’re hunting for KPIs that don’t reduce engineers to line counts.
Whatever you pick, agree on it together in the review or a 1:1, and revisit it as roles, projects, and technology shift. A KPI nobody agreed to is just a stick.
The template I fill in#
I keep one document per person and add a section per review, so the history is in one place. This is the skeleton:
## Performance review: [Name], [period]
**Role and level:** [title, and what that level means on this team]
**Goals from last review:** [copied from the previous section]
### Self-review (filled in by the engineer beforehand)
- What went well, with an example or two
- What didn't, and what they'd do differently
- What they want to be doing in a year
### Progress on last review's goals
- [Goal]: met / partly / not met, with the evidence
### Strengths (specific examples)
- [What they did, when, and what it changed]
### Areas to improve (each with a target)
- [Behaviour or skill] → [what "better" looks like] by [date]
### Career and level
- Where they are against the next level, and what's missing
### Goals until the next review
1. [Measurable goal]
2. [Measurable goal]
### Agreed actions
- [Who] will [do what] by [when]The self-review comes in a day or two before the meeting, never during it. Reading it first changes the conversation: half the time the engineer has already named the thing I was going to raise, and we can spend the meeting on what to do about it.
Questions for the self-review#
These are the prompts I send ahead of time. They’re open on purpose, so the answers tell me how someone sees their own work, not just what they did:
- What are you most proud of since the last review, and why that?
- Where did you get stuck, and what would have unstuck you sooner?
- What feedback have you had from teammates or reviewers that stuck with you?
- Which of last review’s goals do you think you met, and which do you want to drop or change?
- What do you want to learn next, and is your current work giving you a chance to?
- What should I be doing differently as your manager?
The last question gets the most awkward pauses and the most useful answers.
What specific feedback sounds like#
Most bad review feedback isn’t harsh, it’s vague. Here’s the difference, with examples of the kind I try to write:
| Vague | Specific |
|---|---|
| “Communicate better.” | “On the payments migration, the delay surfaced in the sprint review rather than when you found it two weeks earlier. Next time, flag a slip in the team channel the day you see it.” |
| “Great job this quarter.” | “Your write-up of the caching options let us decide in one meeting instead of three. Keep doing those for anything that takes more than a day to choose.” |
| “Be more senior.” | “At the next level, I’d expect you to own a feature’s design end to end. Lead the design review for the search rework and bring two options with the trade-offs.” |
| “Code quality needs work.” | “Three of your last ten PRs needed a follow-up fix for missing edge cases. Add tests for the failure paths before asking for review, and we’ll look at the rate again next quarter.” |
Each specific version names an event, says what it changed, and points at something the person can do next. It takes longer to write, which is exactly why I make myself collect examples through the quarter instead of trying to remember them the night before.
Write it down#
After the meeting, write a summary: the key points discussed, any issues raised, the action items, and the objectives both of you agreed to. It sounds bureaucratic, but the written record is what prevents the “that’s not what we agreed” conversation six months later. Documented issues get tracked instead of evaporating, action items hand the next review its opening agenda, and people take goals more seriously once they’re on paper.
That’s the whole system, really: clear expectations from day one, KPIs shaped to the person, everything documented, and follow-up on every action item. A review that isn’t a two-way conversation with measurable outcomes is a checkbox exercise, and engineers can smell a checkbox exercise from the calendar invite.