What criteria do you use to evaluate a developer's performance?

Question

Accepted Answer

I evaluate developers on the **outcomes they produce and the impact they have on the team**, not on raw output metrics like lines of code, commits, or story points. Good evaluation triangulates several signals over a meaningful window of time, not a single sprint.

## What I actually look at

- **Impact and ownership.** Do they ship work that moves the product or unblocks others? Do they own a problem end to end, including the messy parts like rollout, monitoring, and follow-up bugs?
- **Quality and reliability.** Does their code hold up in production? Are they leaving the codebase better or accumulating **tech debt** others have to pay down?
- **Autonomy at the right level.** A mid-level engineer who needs hand-holding on routine tasks is different from a senior who can take an ambiguous problem and return a plan.
- **Collaboration multiplier.** Code review quality, mentoring, design input, documentation. The best engineers raise the people around them.
- **Growth trajectory.** Are they better than six months ago? Are they responding to feedback?

## How I make it fair

- Calibrate against the **expectations of their level**, written down, so feedback is not arbitrary.
- Gather concrete evidence continuously rather than reconstructing it at review time. I keep notes per person.
- Separate **performance** (results) from **potential** (capability for the next level). Conflating them causes bad promotion and PIP decisions.

| Signal | Good source | Misleading source |
|---|---|---|
| Productivity | Outcomes shipped | Lines of code, commit count |
| Quality | Incident/defect trends | Subjective gut feel |
| Collaboration | Peer feedback, PR history | Volume of meetings |

## Pitfalls

- **Recency bias** — judging the last two weeks, not the period.
- **Visibility bias** — rewarding loud work and missing quiet glue work like on-call and reviews.
- Treating metrics as targets; the moment a metric becomes a goal, people game it.

## Why it matters

Fair, evidence-based evaluation drives trust, retention, and the right growth investments. Get it wrong and you promote the wrong people, demoralize your strongest contributors, and teach the team that performative work beats real impact.

Signal	Good source	Misleading source
Productivity	Outcomes shipped	Lines of code, commit count
Quality	Incident/defect trends	Subjective gut feel
Collaboration	Peer feedback, PR history	Volume of meetings