What Should Go Into a Developer Performance Review Packet?

A developer performance review packet should include seven things: outcomes, work artifacts, peer feedback, manager notes, metrics with context, level expectations, and unresolved questions. It should not be a dashboard screenshot, a ticket-count report, or a folder of vague praise. The packet has one job: make the review specific enough to be fair. Most weak reviews are weak before the writing starts. The manager opens the form, remembers the last few weeks, searches a few tickets, scans Slack, and tries to turn fragments into judgment. That is how recency bias enters. It is how invisible work disappears. It is how engineers who did important but quiet work feel unseen. The Pragmatic Engineer notes that managers cannot know everything an engineer does and can overweight recent work unless accomplishments and context are captured before the review [1]. Engineering Manager Tools gives similar guidance: gather evidence throughout the cycle, collect feedback from multiple sources, and record specific examples [2]. The packet is the antidote to memory-based reviews.

1. Outcomes

Start with what changed because of the engineer's work. Did a project ship? Did reliability improve? Did a migration reduce risk? Did a customer issue get resolved? Did a team move faster because this person simplified a process or clarified a technical direction? Outcomes keep the review grounded in impact. Avoid writing "closed 42 tickets" as if the count explains performance. A ticket count can show activity. It cannot explain difficulty, scope, quality, or judgment.

2. Work artifacts

Every important claim should have an artifact nearby. Useful artifacts include project briefs, pull requests, design docs, RFCs, incident reviews, launch notes, architecture decisions, code review examples, and stakeholder updates. Artifacts prevent the review from becoming vibes. They also help calibration because another manager can inspect the evidence behind a claim. The point is not to attach every PR. The point is to attach the few artifacts that explain the work.

3. Peer and cross-functional feedback

Managers do not see everything. Peers see review quality. Staff engineers see technical judgment. Product managers see tradeoff communication. Designers and support teams see collaboration. Junior engineers see mentorship. A good packet includes targeted feedback from people who worked close enough to be specific. Weak feedback says, "Great teammate." Strong feedback says, "She caught a migration risk during design review, paired with two newer engineers, and kept the API launch from slipping when requirements changed."

4. Manager notes from the cycle

The packet should include dated observations from 1:1s, project check-ins, and feedback conversations. This matters because a formal review should not surprise the engineer. If the first time someone hears about a concern is review day, the manager waited too long. Manager notes should capture growth signals, commitments made in 1:1s, feedback already given, behavior changes over time, examples of increased scope, and areas that still need support. These notes turn the review from a verdict into a continuation of an existing conversation.

5. Metrics with context

Metrics can belong in a review packet. They should not become the review. Cycle time, review time, deployment frequency, incident involvement, and delivery patterns can help managers ask better questions. But raw metrics are easy to misuse. The SPACE framework argues that developer productivity is multi-dimensional: satisfaction, performance, activity, communication and collaboration, and efficiency and flow all matter [3]. That is the right posture for a review packet. Metrics should be prompts:

• Why did cycle time increase?
• Was the engineer handling harder work?
• Did they take on review load for the team?
• Were they blocked by unclear requirements?
• Did they reduce risk in a way the dashboard does not show?

If a metric cannot be explained with context, it should not influence the rating.

6. Level expectations

A review packet needs a map from evidence to expectations. The same behavior can mean different things at different levels. A mid-level engineer owning a service migration may show strong growth. A staff engineer doing the same work may need evidence of broader technical direction, mentorship, or cross-team influence. Include the relevant level rubric or expectations, then map examples to them. This helps the review answer the real question: compared with the role's expectations, what has this engineer demonstrated?

7. Unresolved questions

A good packet also names what is unclear. Maybe peer feedback conflicts with manager observations. Maybe metrics show a delivery slowdown that needs explanation. Maybe a project missed its deadline for reasons outside the engineer's control. Maybe the engineer did important glue work but the impact is hard to quantify. Do not hide ambiguity. Capture it. Unresolved questions tell the manager where to investigate before turning evidence into a rating.

What not to include

Weak packet item	Better version
Ticket count	Project outcome and scope
PR count	Technical judgment, review quality, or shipped impact
Vague praise	Specific feedback tied to work
Dashboard screenshot	Metric trend plus context
Manager memory	Dated observation or artifact
Generic competency note	Example mapped to level expectation

Tools can help centralize the packet, but they do not replace manager judgment. The manager still has to decide what the evidence means.

Final recommendation

Build the packet before writing the review. If the packet cannot explain the rating, the review is not ready. If the packet is mostly counts, screenshots, and generic praise, it is not evidence yet. A strong developer review packet should let a skeptical engineer understand the judgment, even if they do not agree with every part of it.