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.

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:

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.

The meeting is the easy part

#

The structure is almost embarrassingly simple. After a sprint or a project phase, the team sits down and works through three questions:

1. What went well?
2. What didn’t go well?
3. What can we improve?

That’s it. The point is the feedback loop: pause regularly, look at what actually happened, and feed it back into how you work. A team that never pauses just repeats itself.

What separates useful retros from venting sessions

#

Candour, mostly. People will only name the real problem if they’re confident it won’t be held against them, so the safety of the room matters more than whichever format you picked. And the sharpest observations usually come from the quiet people — a retro where only the lead talks is a status meeting with extra steps.

The other half is what happens after the discussion. Every issue worth fixing should leave the room as an action item with a name and a deadline attached. Then — and this is the part most teams skip — open the next retro by reviewing last time’s items. Nothing kills retros faster than everyone quietly realising the action items are decorative.

Where you can, bring numbers too. Opinions like “the sprint felt slow” go in circles; a chart usually settles it.

The failure modes

#

Three I’ve seen up close: retros that turn into blame (fix the system, not the person), retros that run the identical format for a year until everyone’s on autopilot (change it up), and retros with no follow-up at all — which, as above, is the fatal one.

None of this is specific to software, by the way. Marketing campaigns, event management, research projects, manufacturing — anything with a repeating cycle benefits from the same loop. But wherever you run them, the test is the same: did anything actually change before the next one? If not, you’ve just been talking.

That’s the short version. The longer one is below, because I’ve had feedback conversations go wrong the same way more times than I’d like to admit: I raise something, the other person’s shoulders go up, and from that moment neither of us is really listening.

Why people get defensive in the first place

#

Defensiveness isn’t stubbornness, or at least it rarely starts that way. It’s what people do when they feel threatened, and feedback threatens more than we tend to think. You’re nominally talking about a pull request or a missed deadline. What the other person hears is a question about whether they’re good at their job, whether they belong on the team, whether you’ve been quietly thinking this for months.

Once someone feels that, their attention goes to protecting themselves, not to the point you’re making. Arguing harder only confirms the threat. So most of what works below is about lowering the stakes first and only then getting to the substance.

It also helps to remember that some people come into these conversations already bruised. A previous manager who only ever spoke up to criticise, a culture where mistakes got people sidelined. You can’t fix that history in one meeting, but it explains why a mild comment sometimes gets a much bigger reaction than it deserves.

Before the conversation

#

Most feedback conversations are decided before they start. A few things I do now that I didn’t used to:

I pick one thing. If I’ve saved up five issues, the person hears a prosecution, not feedback. The other four can wait, and often turn out to be symptoms of the first one anyway.

I do it soon. Feedback about something that happened six weeks ago lands as “why are you only telling me now?”, which is a fair question with no good answer. A day or two after the event is about right: soon enough that it’s fresh, late enough that neither of you is still hot.

I do it privately, and I don’t do it over chat if I can avoid it. Written feedback loses tone, and a defensive reader fills the missing tone in with the worst possible version. If it has to be written because the team is remote or across timezones, I keep it short and offer a call.

And I check my own state. If I’m annoyed, the other person will pick it up within the first sentence, whatever words I use. Some feedback I’ve given would have gone much better if I’d waited until I’d stopped being irritated.

What to actually say

#

The structure I keep coming back to is the one usually called situation, behaviour, impact (SBI): when it happened, what they did, and what it caused. The point is that each part is observable. There’s nothing in it about who they are, only about what happened.

Here’s the difference in practice. Say a developer merged a change on a Friday afternoon without waiting for review, and it broke checkout over the weekend.

The version that gets walls up: “You always rush things out. You need to be more careful.”

The version that has a chance: “On Friday the payment change went in without a review, and checkout was down for a few hours on Saturday. I’d like to understand what happened, because I don’t think it was carelessness.”

The second one names one event, says plainly what it cost, and ends by assuming good intent. “Always” and “never” are the words that do the most damage. They turn one incident into a judgement of character, and the other person will immediately think of the counterexample that proves you wrong.

I also try to own the observation. “I noticed” and “I’m concerned” are honest about the fact that this is my view, offered from my side, and they leave room for me to have missed something. Often I have.

Then I stop talking and ask. “How did it look from your side?” There’s usually context I didn’t have, like a deadline someone else set or a reviewer who was off sick. Even when there isn’t, the question tells the person this is a conversation and not a verdict.

Feedback also lands far better with a way forward attached. Not a list of problems but “next time, could we…”. Better still if the way forward comes from them.

When they push back anyway

#

You can do everything right and still get resistance. It tends to come in a few recognisable forms, and each one needs a slightly different response.

The most common is denial: “that’s not what happened.” Don’t argue about it. Go back to what you both can see, like the commit, the message or the date, and ask what you’re missing. If the facts really are disputed, it’s fine to say “let’s both look at it again and pick this up tomorrow.”

Then there’s deflection, as in “well, the requirements kept changing” or “so-and-so does it too”. There’s often some truth in it, so acknowledge it rather than dismissing it: “That’s fair, and we should fix the requirements problem too.” Then bring it back gently: “Separately from that, I want to talk about the review step.”

A counter-attack, like “you merge things without review all the time”, is the hardest one not to match. Take a breath. If they’re right, say so, because it’s the fastest way to lower the temperature, and you’ve just shown the openness you’re asking them for. Then come back to the original point.

Shutting down, whether that’s silence or “fine, whatever you say”, looks like agreement and isn’t. I’ll name it softly, something like “it seems like this didn’t land well, and that’s okay”, and offer to continue later. Forcing a response from someone who’s withdrawn just gets you a fake one.

Over-apologising (“I’m terrible at this, I’m so sorry”) is defensiveness too, just pointed inwards. The person is protecting themselves by getting the criticism in first. Reassure them that it’s one specific thing and not their whole performance, and move on to what happens next.

Through all of these, the one rule I try to hold is not to match their energy. When someone gets defensive, my instinct is to get defensive right back, and that’s the one move guaranteed to sink the conversation. If I stay level, the temperature usually comes down on its own. It helps to say the feeling out loud, something like “I can tell this is frustrating to hear”, rather than pretending the tension isn’t in the room.

Know when to stop

#

Sometimes none of it works and the walls stay up. Pushing harder at that point achieves nothing. It’s fine to park the conversation and come back in a day or two once things have settled. The feedback will still be true tomorrow, and people are often much more reflective once they’ve had a night to sleep on it. Some of the best follow-up conversations I’ve had started with the other person saying “I’ve been thinking about what you said.”

That one took me the longest to learn.

After the conversation

#

What happens in the following week matters as much as the conversation itself. If the person changes the behaviour, say you’ve noticed, explicitly and soon. That’s how they learn feedback from you isn’t only ever bad news, and it makes the next conversation easier.

And ask, when it fits, how the feedback landed. “Was that fair?” balances things and shows the openness you’re hoping for in return. When I moved into management I started doing this routinely, and it caught a couple of times where I’d been clearer in my head than out loud.

In short

#

Lower the threat before you raise the issue. Pick one thing, raise it privately and soon, describe the behaviour and its impact rather than the person, and ask for their side before suggesting a fix. When they push back, don’t match it. Acknowledge the feeling, return to the facts, and be willing to stop and pick it up another day. Then follow up, because the conversation after the conversation is where trust gets built.