Engineering teams often run OKRs well and performance reviews badly, or the other way round, and rarely connect the two cleanly. Tie them too tightly and engineers sandbag their key results to protect their rating. Keep them completely separate and reviews drift away from what the company actually needed built. This guide explains how to align OKRs and performance reviews for engineering teams so each does its job.

If you are not sure whether goal alignment is your biggest problem, the performance health check scores alignment alongside standards, bias and admin burden in about two minutes.

The core tension

OKRs and performance reviews answer different questions. OKRs ask: what are we trying to achieve this quarter, and how will we know? Reviews ask: how well did this person perform, against the standard for their level? The first is about direction and ambition; the second is about judgement and fairness.

The OKR tradition is explicit about keeping them apart. The What Matters FAQ, from John Doerr’s team, describes OKRs as quarterly rather than annual and “divorced from compensation”, one of the key differences from older management-by-objectives systems. The reason is practical: if hitting 100% of a key result drives your rating and pay, you will set key results you know you can hit.

McKinsey’s 2024 article “In the spotlight: Performance management that puts people first” describes the same issue. Where OKRs are set as ambitious “moonshot” goals, it suggests managers assess employees not only on OKR fulfilment but also, and to an even greater degree, on how hard they tried given the resources available. It also notes that about three in five companies in its sample assess a mix of the “what” and the “how”.

A model that works: OKRs as evidence, not as the score

The cleanest approach is to treat OKRs as one important source of evidence in the review, not as the rating itself. In practice:

  • OKRs set direction. Team and individual OKRs are set quarterly, linked to company priorities, and graded honestly, so that partly achieving an ambitious key result is treated as a reasonable outcome rather than a failure.
  • The review scores performance against the bar. Engineers are rated on deliverables, skills and culture against the talent bar for their level, as in the performance management framework.
  • OKRs feed the deliverables score. The review asks what the engineer contributed to the team’s key results, how complex that work was and how it was delivered, not whether the number reached 100%.

This keeps OKRs ambitious and reviews fair. An engineer who made a decisive contribution to a key result that landed at 60% can still be rated well; one who coasted on a key result that was set too low should not be.

What “deliverables” means for engineers

The playbook scores deliverables on three dimensions. For engineering they translate roughly as follows:

DimensionIn engineering termsEvidence that works
SpeedMeeting the commitments the team made, including OKR milestonesMilestones hit or missed, with context on scope changes
QualityHow many iterations work needed; defects and reworkReview feedback, incidents traced to changes, rework required
ComplexityHow much precedent existed; ambiguity handledDesign documents, novel problems solved, systems owned

Notice that none of these is lines of code or tickets closed. Volume metrics are easy to game and say little about impact. Use them, if at all, as context.

Skills and culture: the parts OKRs do not cover

OKRs say a lot about what got done and very little about how. For engineers, the skills and culture parts of the review carry that weight. Skills are defined per role by the relevant leader (in the playbook, the CTO defines skills for engineering roles): system design, code quality, testing, operational ownership, technical communication. Culture links each company value to observable behaviour: raising risks early, helping colleagues unblock, writing things down, owning incidents without blame.

Rating these separately, against the bar for each level, stops a strong OKR quarter from hiding a skills gap, and stops a missed key result from overshadowing excellent engineering behaviour. It is also where promotion decisions should come from: readiness for the next level shows up in skills measured against that level’s requirements, not in one quarter’s OKR score.

Writing OKRs that work as review evidence

  • Name contributors. For each team key result, note who is leading which part. It makes contribution visible at review time.
  • Record scope changes. A one-line note when priorities shift mid-quarter saves an argument later.
  • Grade with a sentence. A score plus one sentence of context (“landed at 25%; dependency slipped six weeks”) is far more useful evidence than a number alone.

Aligning the cadence

If OKRs are quarterly and reviews are annual, the review has to reconstruct four quarters from memory. The playbook recommends a quarterly review, which lines up naturally with quarterly OKRs:

WhenOKRsPerformance
Quarter startSet and link team OKRs to company priorities; individuals note their contributionConfirm level and scorecard; agree development focus
Weekly / fortnightlyUpdate progress1:1s capture examples and feedback
Quarter end, week 1Grade OKRs honestly; write a short retrospectiveSelf-assessment references OKR contribution
Quarter end, weeks 1–3OKR grades available as evidenceManager scorecards, calibration, sign-off

Grade OKRs first, then start reviews. That keeps the OKR conversation about the work and the review conversation about the person.

Using OKRs in engineering calibration

In calibration, OKR results help answer one specific question: did this engineer’s contribution make a difference to what the team needed to achieve? Useful prompts:

  • “What would have happened to this key result without this person’s work?”
  • “Was the key result set at the right level of ambition? Who set it?”
  • “Is this rating counting on-call, incident response and code-review work, which rarely appears in OKRs?”
  • “Did the scope change during the quarter, and was that reflected?”

For the full meeting format, see the calibration meeting template for mid-market tech companies.

Worked example

An illustrative platform team sets a key result to reduce p95 API latency by 40% this quarter. It lands at 25%. Engineer A designed the caching approach that delivered most of the gain and mentored two colleagues through it. Engineer B completed assigned tickets on time but took on no ambiguous work.

A rating tied directly to the key result would mark both engineers down equally for a 25% outcome. Under the evidence model, Engineer A’s deliverables score reflects high complexity and a decisive contribution, and their skills and culture scores reflect the mentoring. Engineer B is rated at the bar for speed and quality, with complexity flagged as the development area for next quarter. The team’s OKR retrospective separately notes that 40% was ambitious given a mid-quarter dependency, which shapes how next quarter’s key results are set.

Common mistakes

  • Rating on OKR percentage. It rewards sandbagging and punishes ambition.
  • Individual OKRs for everything. Engineering work is usually a team effort; most OKRs should be team-level, with individuals describing their contribution.
  • Ignoring invisible work. Reliability, reviews, mentoring and incident work rarely appear in OKRs but matter a great deal.
  • Letting OKRs go stale. If OKRs are not updated during the quarter, they are not useful evidence at review time.
  • Different cadences. Quarterly OKRs with annual reviews leave a long gap for memory to fill.

To see what moving to quarterly reviews would cost in time, use the review cost calculator. To check your engineering ratings for leniency or central tendency, use the bias checker.

Sources: What Matters, OKR meaning, definition and examples; McKinsey, In the spotlight: Performance management that puts people first (2024). Examples are illustrative.

Use with this guide