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

#

1. 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.
2. Run through the agenda so nobody gets ambushed by a topic.
3. Growth since the last review — name the progress explicitly. People rarely notice their own.
4. Current performance, strengths first.
5. Areas for improvement, each with a specific, realistic target attached.
6. Career plans, and whether the current work actually points at them.
7. 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.

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.