Editorial blueprint-style illustration of a performance review template grid on a desk, with citation columns visible alongside a technical pen and ruler.

Engineering Performance Review Template (IC + Manager Tracks)

Most engineering review templates ask the right questions and then leave you with a blank box. You end up writing "great communicator" without anything to back it up. This template adds one column that fixes that: every claim has to point to an artifact. Copy it, paste it into your doc tool, and ship a stronger review by Friday.

There are two tracks here — IC (individual contributor) and engineering manager — plus a leveling rubric so ratings aren't pure vibes, and a fully filled-in example using a fictional senior engineer. No email gate, no signup. Just scroll, copy, and use it.

Key Takeaways

Every section uses a three-column structure — Claim, Supporting artifact, Impact — so reviews stay evidence-grounded instead of adjectival.

The template covers both IC and manager tracks; the IC version emphasizes delivery and craft, the manager version emphasizes team outcomes and people.

A 5-level competency rubric (L3 through L7) is included so ratings calibrate to expectations, not to mood.

A complete worked example for a fictional senior engineer ("Priya, L5") shows what filled-in looks like.

How to use this template

Block 90 minutes before you open the doc. Pull evidence first, write second. You'll want commit history and PR review data (GitHub, GitLab, Bitbucket), incident records (PagerDuty, Statuspage), project tracker exports (Linear, Jira, Asana), design docs, and any peer feedback you've collected. The citation column is the rule that keeps you honest — if you can't name an artifact, don't make the claim.

Then go section by section. Fill the Claim column with one specific sentence. Fill the Supporting artifact column with a link, file path, ticket ID, or document name. Fill the Impact column with the consequence — what changed for users, the team, or the business. Three sentences per row is plenty.

For a full walkthrough of the evidence-gathering process, see our how-to-write-performance-review-engineers guide. For the broader category of tools that automate this kind of synthesis, see the pillar on performance review software.

The IC track template (blank)

Copy this block. Each section has the same Claim / Supporting artifact / Impact columns. Aim for 3-5 rows per section; quality beats volume.

Delivery and impact

### Delivery and impact

| Claim | Supporting artifact | Impact |
|---|---|---|
| [What they shipped or moved forward] | [PR link, ticket ID, design doc] | [User, team, or business outcome] |
| | | |
| | | |

Summary (3-4 sentences): What did this person ship this cycle and what did it
change? Anchor to the artifacts above; do not introduce claims here that you
didn't cite in the table.

Code quality and craft

### Code quality and craft

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Quality signal: test coverage, defect rate, review feedback] | [PR, incident, test report, lint metric] | [Reliability, velocity, or maintenance impact] |
| | | |
| | | |

Summary (2-3 sentences): How does this person's craft show up in the codebase?
What gets better because they touched it?

Collaboration and influence

### Collaboration and influence

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Mentorship, cross-team coordination, design review] | [Doc, thread link, mentee feedback, RFC] | [Who got unblocked or leveled up] |
| | | |
| | | |

Summary (2-3 sentences): How does this person make the people around them
more effective?

Growth and goals

### Growth and goals

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Goal from last cycle and outcome] | [Original goal doc, completed deliverable] | [Skill gained or gap remaining] |
| | | |
| | | |

Next-cycle goals (2-3 bullets, each with a measurable artifact target):
- [Goal] — target artifact: [what "done" looks like]
- [Goal] — target artifact: [what "done" looks like]

detailed evidence-gathering walkthrough

The Engineering Manager track template (blank)

Manager reviews evaluate team outcomes, not just individual output. Same column structure; different lens.

Team delivery (velocity, quality, reliability)

### Team delivery

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Team shipped X / hit Y SLO / reduced incident count by Z] | [Roadmap doc, SLO dashboard, incident postmortems] | [Customer or business outcome] |
| | | |
| | | |

Summary (3-4 sentences): What did the team accomplish under this manager's
leadership? Tie outcomes to the artifacts.

People (growth, retention, promotions)

### People

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Promotion, growth plan, retention story, hire] | [Promo packet, 1:1 notes, exit/stay interview, offer accepted] | [Team capability or stability gained] |
| | | |
| | | |

Summary (3-4 sentences): How did this manager develop and retain the team?

Strategy and cross-functional

### Strategy and cross-functional

| Claim | Supporting artifact | Impact |
|---|---|---|
| [Strategy doc, roadmap negotiation, cross-team initiative] | [Doc link, decision record, partnership outcome] | [Org-level impact] |
| | | |
| | | |

Summary (2-3 sentences): Where did this manager shape direction beyond their
immediate team?

pillar on performance review software

Competency rubric and leveling guidance

Ratings drift when "exceeds expectations" isn't anchored to a level. Use this rubric to calibrate. Adjust the labels to match your ladder (L3 through L7 here roughly maps to Google's L3-L7, Meta's E3-E7, or "Engineer I" through "Principal").

| Level | Scope | Delivery | Influence | Citation density expectation | |---|---|---|---|---| | L3 (Engineer I) | Single task, defined work | Completes well-scoped tickets with review support | Within own team, asks good questions | 3-5 PR-level artifacts per section | | L4 (Engineer II) | Single project, scoped feature | Owns feature end-to-end, debugs production | Pairs effectively, reviews peer PRs | 5-7 artifacts including design docs | | L5 (Senior) | Multi-quarter project, ambiguous problem | Defines and ships systems; owns reliability | Influences team direction, mentors L3/L4 | Design docs, incident leadership, mentorship trail | | L6 (Staff) | Cross-team initiative | Drives architectural decisions across teams | Sets technical direction org-wide | RFCs, strategy docs, cross-team artifacts | | L7 (Principal) | Org-wide technical strategy | Sets multi-year technical vision | Shapes engineering culture and hiring bar | Public-facing artifacts, org-level decisions |

A "meets expectations" rating means the citation column reads like the row for the engineer's level. "Exceeds" means it reads like the row above. "Below" means the artifacts cited are scoped to the row below. That's it — no more arguing about whether someone "had impact."

Our finding: When citation density falls more than one level below the engineer's title, calibration meetings almost always surface a leveling mismatch rather than a performance problem.

Filled-in example: Priya, L5 Senior Engineer

Here's what the IC track looks like fully filled in. Fictional, but the artifact patterns are real.

Delivery and impact

| Claim | Supporting artifact | Impact | |---|---|---| | Led the checkout latency rewrite | Design doc checkout-v2-rfc.md, PRs #4421-#4488 | p95 dropped from 840ms to 310ms; cart abandonment fell 4.2% (analytics dashboard, Q1) | | Migrated billing service off legacy queue | Linear epic ENG-1207, runbook billing-cutover.md | Eliminated 6 hours/week of on-call paging (PagerDuty data Jan-Mar) | | Shipped INP improvements on the dashboard | PRs #4502, #4517, Lighthouse run logs | INP improved from 320ms to 180ms (CrUX field data, week of Apr 14) |

Summary: Priya was the technical lead for two infrastructure-critical projects this cycle. The checkout rewrite moved a top-five business metric, and the billing cutover materially reduced on-call burden for the whole team. Both projects are documented end to end.

Code quality and craft

| Claim | Supporting artifact | Impact | |---|---|---| | Increased test coverage on payments-core from 62% to 84% | Coverage report Apr 30, PRs #4455-#4490 | Two regressions caught pre-deploy that previously would have shipped | | Zero post-deploy incidents on owned services | PagerDuty incident log, Jan 1 - Apr 30 | Team reliability composite rose 12% | | PR review quality cited by 4 peers | Peer feedback excerpts (anonymized, on file) | New hires onboarded faster — average first-PR-merged dropped from 9 to 5 days |

Summary: Priya's reviews are cited as a primary reason teammates ship cleaner code. Her own services had no production incidents this cycle.

Collaboration and influence

| Claim | Supporting artifact | Impact | |---|---|---| | Mentored two L4 engineers through promotion-track work | Growth plan docs, 1:1 notes, both packets in current promo cycle | Built mid-level bench; reduced lead burden on me as manager | | Authored the team's RFC template | rfc-template.md, adopted by 3 sibling teams | Cross-team design reviews now have a shared format | | Led incident review for the April S1 outage | Postmortem doc 2026-04-12-checkout-s1.md | 4 follow-up actions tracked; 3 completed in-cycle |

Summary: Priya's influence is starting to extend beyond her team. The RFC template adoption is the clearest signal.

Growth and goals

| Claim | Supporting artifact | Impact | |---|---|---| | Last cycle's goal: own a multi-quarter project end to end | Checkout rewrite (see Delivery) | Goal met; ready for staff-track scope next cycle | | Last cycle's goal: develop cross-team influence | RFC template adoption | Goal partially met; deeper cross-team work is the next step |

Next-cycle goals:

Lead a cross-team initiative spanning checkout, billing, and notifications — target artifact: published cross-team roadmap with quarterly checkpoints
Begin staff-track scoping work — target artifact: one technical strategy doc reviewed by the staff+ group

Rating: Exceeds expectations at L5. Citation density reads at the L6 row for Delivery and Collaboration. Recommend opening a staff-track growth conversation.

This is what an evidence-grounded review looks like end to end. Notice that almost every sentence in the summaries traces back to a row in the table.

Where this template fits in your workflow

Hand-filling the citation column takes about 90 minutes per direct report if your tools are organized, longer if they're not. That's the unavoidable cost of writing reviews that survive calibration. PerfCopilot was built to do exactly this synthesis step — pulling commits, PRs, incident data, and ticket history into a draft that already has the citation column populated — but the template works perfectly well on its own. The free tier covers up to 5 direct reports.

Frequently asked questions

How long should each section be in this engineering performance review template?

Aim for 3-5 rows in the citation table plus a 2-4 sentence summary per section. The total IC review lands around 600-900 words; manager reviews run 800-1,100 words. Length isn't the goal — citation density is. A 400-word review with traceable artifacts in every row beats a 1,500-word essay with no evidence.

Can I use this template for a self-review?

Yes, and the citation column is actually most valuable in self-reviews. It forces you to anchor your claims to artifacts your manager can verify, which is exactly what calibration committees look for. Run through both the IC delivery and growth sections; skip the manager track unless you're a manager.

What if I can't find an artifact for a claim I want to make?

Drop the claim or rewrite it qualitatively. If you can't point to a PR, doc, ticket, dashboard, or piece of written feedback, the claim probably won't survive scrutiny in calibration anyway. The discipline of the citation column is to keep the review honest, not to fill rows for their own sake.

Does this work for remote teams?

Better than most templates, actually. Remote teams already produce most of their work in writing — design docs, async standups, written PR reviews — which means the artifact column is easier to fill. Co-located teams sometimes have to retroactively reconstruct what happened in hallway conversations.

How does this differ from the templates from Confirm or Pragmatic Engineer?

The structural difference is the citation column in every section. Most templates ask "describe their impact" and leave you a blank box; this one requires that every claim point to an artifact. The leveling rubric and the filled-in worked example are also free here and not gated behind an email signup.

Sources

Google re:Work, Performance management research, retrieved 2026-05-19, https://rework.withgoogle.com/subjects/managers/
Lara Hogan, Resilient Management — performance review frameworks, retrieved 2026-05-19, https://larahogan.me/blog/
Will Larson, Staff Engineer's Path — leveling and rubric guidance, retrieved 2026-05-19, https://staffeng.com/

By Samira Bahmanyar · HR Manager

Last updated 2026-05-19. This template is free to copy, modify, and redistribute under your team's own documentation. No attribution required.