Home / Self-review guide
How to write a self‑review, with examples
Most self-reviews undersell the person who wrote them. Not because the work was small, but because nobody remembers a year of work in one sitting. Here is how to fix that.
By Devin Pickering · 6 minute read
Start by collecting, not writing
The hardest part of a self-review is not the writing. It is remembering. Before you write a single sentence, spend 30 minutes pulling raw material from the places your work actually lives:
- Your sent email. Search month by month. What you sent is a record of what you moved forward.
- Your calendar. Recurring meetings you started, workshops you ran, people you onboarded.
- Chat threads. The quick "can you help with this" requests add up to a pattern of being the person others rely on.
- Shipped work. Releases, documents, decks, tickets closed.
- Thank-you notes. Anything someone thanked you for is evidence of impact.
Write everything down as a rough list. Do not judge it yet. You will be surprised how much you had forgotten.
Turn tasks into outcomes
A task says what you did. An outcome says why it mattered. Reviewers remember outcomes. A simple shape that works almost every time:
I did [the work], which [changed something], shown by [the evidence].
Worked on the checkout redesign.
Rebuilt checkout into fewer steps, which cut drop-off by about 18% in the first month after launch.
Helped with onboarding.
Onboarded two new designers onto our design system, so both were shipping production work in their second week.
Examples are illustrative.
When you do not have a number
Not every win comes with a metric, and that is fine. Never invent one. A made-up number is the fastest way to lose a reviewer's trust. Instead, use one of these:
- Scope: how many people, teams, or products it touched.
- Time: how much faster something got, or how much time it saved others.
- Before and after: what was broken, and what works now.
- Who relied on it: which team now uses what you built.
If a number exists but you do not have it, go get it before the review. Ask the analyst, check the dashboard, or ask the person who benefited. One real number beats five vague claims.
Do not skip the small stuff
Big projects are easy to remember. The hundred small things are not, and in my opinion they matter just as much. Unblocking a teammate, fixing a process nobody owned, answering the same question well for the tenth time. One small item reads as trivia. A pattern of them reads as someone the team depends on. Group them:
Became the go-to person for design system questions across three product teams, answering dozens of requests and turning the most common ones into documented patterns.
Choose what to lead with
Your reviewer will read the first few lines closely and skim the rest. Lead with your clearest business impact, then your strongest supporting win, then range: mentoring, process, the things beyond your own projects. Three to five headline accomplishments is plenty. Everything else can sit below as supporting detail.
Write it in your own voice
Your self-review should sound like you on a good day, not like a corporate press release. Plain sentences, real verbs, specific details. "Led cross-functional synergy initiatives" tells your manager nothing. "Got design and engineering agreeing on one spec before build, which stopped the rework we had on the last two releases" tells them everything.
A quick checklist
- Collect raw material from email, calendar, chats, and shipped work.
- Rewrite each item as work, change, and evidence.
- Find real numbers, or use scope, time, or before and after.
- Group the small wins into patterns.
- Lead with your clearest impact. Keep it to three to five headlines.
- Read it out loud. If it does not sound like you, rewrite it.
Skip the collecting next time
My Accomplishments does step one for you all year. It keeps track of what you get done in Outlook, Teams, and meetings, so your next review starts from a full list instead of a blank page.