How to Write a Performance Review Self-Assessment (With Examples)

The self-assessment is where most people undersell themselves — not because they didn't do the work, but because six months of work is hard to reconstruct from memory on a Tuesday afternoon. Here's a practical approach, with examples.

The problem most people run into

The performance review self-assessment asks you to evaluate your own contributions over 6-12 months. Most people write one in a couple of hours, drawing mostly on what they remember — which skews toward recent events, visible wins, and anything they got explicit praise for.

What gets left out: the debugging that took three days, the meetings where you gave feedback that changed the direction, the PR reviews, the quiet work that kept things from breaking, the junior engineer you spent time mentoring.

This isn't dishonesty. It's memory. The self-assessment process systematically disadvantages people who do important work that doesn't produce visible artifacts.

How to actually prepare

1. Go to your sources first, then write

Before you write a word, gather:

Git log — your commits, merged PRs, reviews given
Slack / email — where you helped someone, where you gave feedback that changed something
Jira / Linear / GitHub Issues — tickets you closed, bugs you fixed, epics you contributed to
Calendar — recurring meetings where you had a role, ad-hoc calls where you provided technical leadership
1:1 notes — what you and your manager discussed, what you committed to, what you accomplished

This takes 20-30 minutes. It produces a list that is almost always longer than you expected. Start here.

2. Translate activities into impact

The goal of the self-assessment isn't to list what you did — it's to explain why it mattered. The format that works:

[What you did] → [What it produced] → [Why it mattered to the team/product/users]

❌ Just the activity

Fixed the authentication bug that was causing login failures.

✓ Activity + impact

Diagnosed and resolved a race condition in the token refresh logic that had been causing intermittent login failures for 3 days — blocking the team from shipping the onboarding flow. The fix required isolating a subtle timing issue across four services. Resolved the blocker and added a regression test to prevent recurrence.

The second version gives your manager material. It explains the difficulty of the work, the breadth of impact, and the defensive measure you took afterward.

What "impact" means for different types of work

For shipping features

What user problem does it solve?
What was technically complex about building it?
What does it enable next?

For bug fixes and performance work

What was the user impact before the fix? (slowness, errors, data loss)
How long had it been affecting users / the team?
What did you have to do to find and fix it?
Did the fix prevent future issues (tests, documentation, monitoring)?

For code reviews and mentoring

How many reviews? In what time period?
Any specific reviews where your feedback changed the design?
Engineers you mentored — what did they ship that you helped make possible?

For cross-functional work

What decisions did you influence?
What would have gone differently without your input?
What alignment did you create that wouldn't have existed?

A real before/after example

❌ Before: vague and thin

This year I worked on the authentication system, reviewed a lot of PRs, and helped with the new onboarding flow. I also did some performance work on the analytics endpoint. I mentored a couple of junior engineers. I think I contributed well to the team.

✓ After: specific and evidenced

Key Accomplishments Authentication System Overhaul (Q1-Q2) Led the auth refactor from JWT to a session-based system — a 3-month project spanning backend, frontend, and infrastructure. This resolved the session fixation vulnerability identified in the security audit and reduced auth-related support tickets by ~60% in the two months post-launch. Incident Resolution — Analytics Slowdown (March) Diagnosed and resolved a full-table-scan query causing 8-second load times on the analytics dashboard. Identified a missing index that had been introduced during a migration, fixed it, and added a query performance test to our CI pipeline to catch similar regressions. Turnaround: same day. Team Throughput Reviewed 94 PRs in H1, averaging 2-3 business days per review. Caught three significant design issues in review that would have required rework post-merge. Mentored Priya through her first three major features — she is now working independently on the notification system. Cross-functional Leadership Represented engineering in 6 product planning sessions, including two where I redirected scope that would have created technical debt. The dashboard nav redesign was the most significant: convinced design to simplify the structure in a way that will reduce future mobile implementation complexity by an estimated 40%.

How much is enough?

Aim for 3-5 specific accomplishments, each with 2-4 sentences. Quality over quantity — one well-evidenced example beats five vague claims.

Structure that works:

Lead with your highest-impact work — what you're most proud of, what moved the most important needles
Include one difficult thing — something technically hard, something you had to figure out, something that required persistence
Include collaboration — mentorship, reviews, cross-functional work (shows you're not just heads-down)
Address growth — one thing you got better at this year
Forward-looking — what you want to take on next

The tone question

Many people struggle with self-promotion. Writing "I led" or "I built" or "I resolved" feels immodest. The reframe that helps: you are not bragging — you are giving your manager information they need to advocate for you.

Your manager has limited memory. They have multiple direct reports. They're about to go into a room with other managers and make decisions about your career. The self-assessment is how you give them the material to make the case.

Underselling yourself doesn't make you humble. It makes your manager's job harder and your career outcomes worse.

Have your notes but not the words?

WorkLog turns raw notes — your git log, your Slack messages, your memory dump — into a structured performance review self-assessment. Free, no signup.

Try WorkLog →

Common mistakes to avoid

"We" instead of "I" — The self-assessment is about your contribution. Use "I" and attribute others where credit is genuinely shared.
Listing activities without outcomes — "Worked on the dashboard" says nothing. "Shipped the dashboard redesign that reduced user-reported confusion by X%" says something.
Recency bias — The thing you shipped last month feels large. The thing you shipped nine months ago is equally valid. Use your sources.
Ignoring maintenance and stability work — Keeping things from breaking is real work. Name it explicitly.
No forward-looking section — Managers want to know what you want next. Not including this is a missed signal.