How to write a self-review.

A self-review is the one document in your year where you tell the story of your work before someone else does. Keep it short. Make it specific, and true.

The shape that works

• Impact. What changed because of your work, for users, the team or the business. Before and after.
• Collaboration. How you made other people faster or better, with one example each.
• Growth. What you learned, what you'd do differently, and what you want to own next.

Three to five bullets in each. One page is plenty; your manager reads a stack of these in the same week.

An example of the shape. The project and numbers are made up.

Five rules

1. Evidence first. Gather it before you write. You'll remember the last month and forget the first five.
2. Before and after. "From 820 ms to 310 ms" beats "much faster". Without a number, describe a change someone could see.
3. Your part, clearly. "I led", "I wrote" and "I decided" for your part, "we" for the team's. Don't borrow in either direction.
4. Admit one miss. A line on what didn't work, and what you changed, reads as judgement.
5. Point forward. End with what you want to own next half. It turns the review into a plan.

Phrases to drop

"Worked on", "helped with", "was involved in", "various", "ensured quality", "drove alignment". They say you were near the work. Replace each one with what you did and what changed.

Have a list already? Paste it into the free self-review generator and get it sorted into impact, collaboration and growth, with a reminder on every line that still needs a number.

Examples by role

What reviewers look for changes with the job, so each page has its own examples, phrases and ways to gather evidence.

• Self-review examples for backend engineers: reliability, APIs, migrations and on-call.
• Self-review examples for frontend engineers: performance, accessibility and shared components.
• Self-review examples for iOS engineers: releases, crash-free rate and launch time.
• Self-review examples for Android engineers: ANR rate, staged rollouts and device coverage.
• Self-review examples for QA engineers: bugs caught early, automation and flaky tests.
• Self-review examples for SRE and DevOps engineers: SLOs, paging load, deploy safety and toil.
• Self-review examples for data engineers: freshness, data quality and self-serve datasets.
• Self-review examples for engineering managers: team outcomes, people, hiring and decisions.
• Self-review examples for product designers: research, outcomes and the design system.
• Self-review examples for product managers: outcomes, decisions, discovery and launches.

Keep the record as you go

Start with a brag doc template if you don't keep one yet. Most of a self-review is memory work. A running note of what you shipped, who you helped and what you waited on makes review week an afternoon instead of a weekend.

Sill keeps that record for you. On the Mac it reads your local git history (commit messages and times, never code). On iPhone, iPad and Mac it records the tasks you finish, the releases you ship and the follow-ups you send, with receipts like day 6, asked 3×. Sill Pro's Review generator turns months of it into a draft per project, and where Apple Intelligence is available it writes a first-person draft on the device; nothing leaves it. Commits come only from the Mac app. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.

Writing a standup instead? See 12 standup examples for developers or paste your commits into the standup generator.