Your performance review form is open, and the ticket history is full. Yay 🎉
You can see what you worked on but choosing what deserves a paragraph is harder.
For a software engineer performance review, choose accomplishments that show a change in a product, system, or team. For each one, record your contribution, the outcome, and the evidence behind it. Include reliability, technical decisions, mentoring, and coordination when you can explain their effect. Label outcomes that are still pending.
Copy the worksheet below into your notes and fill it in for each accomplishment you are considering. The six steps will help you check the evidence and choose what goes into your review.
Copy the accomplishment worksheet
Review period:
Role and expected scope:
Accomplishment:
Before: What problem or limitation existed?
After: What changed, and for whom?
My contribution: What did I personally decide, build, or enable?
Team contribution: What did other people own?
Evidence: What observation, measurement, or feedback supports the claim?
Measurement window and limitations:
Source references: Where can an authorised reviewer check the evidence?
Why it mattered for my role or team:
One-sentence version:
[ ] The accomplishment falls within this review period.
[ ] I can explain the change and my contribution separately.
[ ] The evidence supports the wording, including any numbers.
[ ] Estimates, pending outcomes, and unknowns are labelled.
[ ] This adds something distinct to my other selected accomplishments.
[ ] The detail is appropriate for the people and tools receiving it.
Decision: Include / needs evidence / keep in background notes
Next action, if evidence is missing:I suggest starting with three to five headline accomplishments, then adjusting to your company’s review form. You can keep the rest in your supporting notes.
Keep approved internal evidence in company-approved systems. In personal notes or external tools, use only information your employer permits you to retain. A source reference can describe an internal document without copying its contents or exposing its URL.
1. Set the review window and expectations
Write down the dates, your role, and the questions in the review form before searching your work history. Include any changes in team, responsibilities, or agreed goals during that period.
Use your company’s role expectations to judge relevance. An architecture decision might demonstrate the ownership expected at your level; a difficult incident might show technical judgment and collaboration. Explain that connection in ordinary language.
If you need help deciding which kinds of work qualify, start with what counts as an accomplishment for a software engineer.
2. Find work you might have forgotten
Look through the sources you are authorised to access:
- Pull requests, code reviews, and release notes
- Design documents and architecture decisions
- Incident reports, postmortems, and operational dashboards
- Product feedback and support issues
- Project plans and cross-team decisions
- Mentoring, onboarding, and pairing notes
- Specific feedback from peers or your manager
For each candidate, record the source reference and a rough sentence about why the work mattered. Leave the polishing until you have checked the claim.
Julia Evans describes recovering forgotten work from pull requests, tickets, launch emails, and design documents in her guide to brag documents. Her template also includes collaboration, mentoring, and documentation, which are easy to miss when you only scan shipped features.
If your notes are sparse, start with a few consequential projects and ask collaborators to help confirm the details. A weekly career-capture habit can save you some of that searching next cycle.
3. Describe your engineering accomplishments
Try completing this sentence:
I changed [before state] into [after state] for [person, team, customer, or system] by [specific contribution].
The examples below are fictional teaching examples, not customer results or claims about careercraft.ing. Use their structure only when your own evidence supports it.
| Work | Before: task description | After: accomplishment candidate | Evidence to check |
|---|---|---|---|
| Delivery | Built the import screen. | Added row-level validation so customers could correct rejected entries before submitting an import. | Released behaviour, acceptance tests, and feedback. Claim fewer support requests only if measured. |
| Reliability | Improved retries. | Added idempotency checks to the payment retry handler; replay tests confirmed that repeated requests no longer created duplicate charges in the tested scenarios. | Regression cases, test results, and release record. Production incident reduction needs separate evidence. |
| Architecture | Refactored permissions. | Consolidated three permission checks into one shared policy, removing inconsistent access decisions covered by the regression suite. | Decision record, code diff, and tests showing the earlier disagreement. |
| Mentoring | Helped a new teammate. | Paired on the release process and reviewed the runbook; the teammate then completed their first release without me taking over. | Their feedback, the runbook changes, and release record. |
| Glue work | Coordinated the migration. | Resolved an ownership gap between two teams and recorded the rollback decision, allowing the migration to proceed with an agreed recovery plan. | Decision notes, named owners, and migration approval. |
Record what you can observe. A recovery plan can be a useful result without a claim that it prevented an outage. For more examples of coordination and mentoring evidence, see the Glue Work Matrix.
If the outcome is still pending, say so. You can describe a completed technical milestone and the judgment behind it while keeping the hoped-for business result separate.
4. Check the evidence behind each accomplishment
Before selecting a candidate, check:
- I can explain what changed beyond the activity itself.
- I have separated my contribution from the team’s result.
- A source artifact or specific observation supports the claim.
- Every number has a definition, comparison, and time window.
- I have checked whether other changes could explain the result.
- I have labelled estimates and limitations.
Suppose your notes say, “Made builds faster.” Here is a fictional filled-in worksheet:
Before: Median CI duration was 12 minutes across 20 successful main-branch runs.
After: Median duration was 8 minutes across the next 20 comparable runs.
My contribution: Split independent jobs and removed repeated dependency installation.
Team contribution: A teammate implemented the dependency cache.
Evidence: CI run history and both pull requests.
Limitations: Both changes shipped together; the reduction cannot be attributed to mine alone.
One-sentence version: Contributed to reducing median CI duration from 12 to 8 minutes
by parallelising jobs and removing repeated setup, alongside a teammate's cache change.When no useful number exists, use a specific before-and-after observation, documented decision, or feedback. The engineering-impact guide covers how to describe those forms of evidence.
5. Choose a small, distinct set
Lay the candidates side by side. Prioritise work that is relevant to your role, has clear evidence, and adds something the other examples do not show.
If you are stuck, use this optional sorting aid. For each criterion, give 0 for missing, 1 for partial, or 2 for clear:
| Criterion | Question |
|---|---|
| Outcome | Can I describe the change? |
| Evidence | Can an authorised reviewer check it? |
| Scope | Does it demonstrate an expectation of my role? |
| Benefit | Can I explain who or what benefited? |
| Distinctness | Does it add something different to the set? |
Use the scores only to sort your notes. They have not been validated as performance ratings. If an item lacks evidence, follow up before making it a headline accomplishment, however well it scores elsewhere.
Check the final set for duplicated projects and overlooked work. Three bullets about the same launch may leave out a stronger example of debugging, mentoring, or technical judgment. Choose the set that represents your actual responsibilities; you do not need one item from every category.
If the form asks for growth areas, give them their own space. Describe what you want to improve without dressing it up as an accomplishment.
6. Turn the selected evidence into review copy
Use the one-sentence version from each worksheet as the opening of an accomplishment paragraph. Add the constraint or trade-off that explains your judgment, then include the evidence reference appropriate for the review system.
For the fictional CI example, that might read:
I contributed to reducing median CI duration from 12 to 8 minutes by parallelising independent jobs and removing repeated setup, alongside a teammate’s cache change. I kept the release checks sequential where they depended on the same environment. The comparison covers 20 successful main-branch runs before and after the changes; the run history and pull requests are linked in the review notes.
The X-Y-Z framework can help tighten a measured result. For the wider review structure and examples, use what to write in a software engineer self-review.
Before submitting:
- Each paragraph explains the result, my contribution, and the evidence.
- The wording respects measurement limits and shared ownership.
- The set covers the review period, including work completed earlier in it.
- Technical detail helps the reader understand a decision or outcome.
- Source references are accessible to the intended reviewer.
- Confidential detail stays within approved systems and audiences.
- I have followed the company’s form and length requirements.
Career Notes
Get better at proving your work.
A short newsletter for engineers who want clearer career stories, stronger self reviews, and better evidence before the next big conversation.
You’re subscribed.
Check your inbox for the first note.
Common questions
How many accomplishments should a software engineer include in a performance review?
For this worksheet, I suggest three to five engineering accomplishments as a starting point. Follow your company’s review form and length requirements; a short form may need fewer. Keep additional evidence available for follow-up questions.
How do I describe engineering accomplishments without metrics?
Describe an observable change, a resolved technical decision, or specific feedback, and identify the source. For example, a documented rollback decision can show that a team has an agreed recovery plan. It does not establish that you prevented an outage. Keep the claim within what the evidence supports.
Can I include an engineering project that has not launched?
Include completed engineering milestones when they demonstrate work relevant to your role. Describe what you finished, such as resolving an architectural uncertainty or validating a migration approach, and why it mattered. Label the launch and business outcomes as pending.
Is this a brag document template?
A brag document can hold an ongoing history of your work. This worksheet helps you select and verify accomplishments from that history for a particular review. You can use it with a document, spreadsheet, or approved notes tool.
Make next cycle easier
Save the completed worksheets where you are authorised to keep them. After your next meaningful piece of work, add the rough context and evidence reference while you can still find them.
If you want a private place for permitted career notes, careercraft.ing is built around capturing engineering work and preparing material for reviews. Start with one accomplishment from this week and fill in the worksheet.