Short answer
A fair engineering manager review explains how the engineer worked at the expected scope, not whether they match a preferred personality. Draw evidence from the full period, align the prose with the rating, and pair each development point with a next step.
Review the whole period
Collect evidence before drafting: design records, delivery notes, code review discussions, incident timelines, and Career Sync notes. A recent launch or incident should not replace the rest of the cycle.
Write in the third person. Describe the engineer's decisions and outcomes, not personality, confidence, hours, or how visible the work felt.
Make the rating and evidence agree
Start from the Function snapshot pinned to the cycle. Compare the evidence with the current level's expectations for scope, autonomy, complexity, and craft.
A rating above expectations needs evidence of different work, not extra effort. A rating below expectations needs the specific expectation that was not met and examples from the period.
- Name the level expectation being assessed
- Cite an artifact, decision, delivery, or operational outcome
- Explain why that evidence supports the proposed rating
Use a third-person review shape
Keep placeholders until you have verified the facts. A usable paragraph might read: They owned [system or project] through [stage]. Their [design or decision] addressed [known constraint], and [artifact] let [team or partner] continue the work. This evidence meets the [level] expectation for [competency].
Do not add a metric, customer, deadline, or incident outcome unless it appears in the source notes.
Behavior instead of praise
They documented the decision in [artifact], resolved the open review concern, and gave the team a clear owner and next action.
Assess operations and review fairly
For incidents, assess diagnosis, decisions, updates, remediation, and learning. Do not reward visible stress or after-hours availability. For code review, assess whether comments found meaningful risk and helped the author reach a sound decision.
Shared operational failures need shared context. Separate the engineer's actions from process gaps or decisions outside their control.
Write a concrete development path
Name the gap, its evidence, and what closed looks like. Avoid broad notes such as improve communication or show more ownership.
For example: Their last two design drafts left operational ownership unresolved. For the next cross-team change, they should name the on-call owner and rollout decision before review, then confirm both in the final document.