How to Write a Self-Review (Template + Examples)

Most people skip the self-review or rush through it at the last minute. That's a mistake. Your self-review is your chance to tell your own story before someone else tells it for you. Here's the truth: your manager is not tracking everything you did this year. They're busy. They forget. If you don't write it down, it doesn't exist in the room where decisions get made. A good self-review isn't about bragging. It's about being specific. "I contributed to the project" tells your manager nothing. "I cut the onboarding time from two weeks to five days by rewriting the training guide" tells them everything. I've read hundreds of self-reviews. The ones that stand out are not the most polished — they're the most concrete. Real numbers. Real situations. Real results. That's what wins in a calibration meeting.

The 5-section self-review template

Most self-reviews fit the same skeleton, regardless of company or role. Five sections, in this order, on one to two pages. Fill them in from your brag document and career journal — not from memory.

• Summary — three sentences. The headline of the cycle, the level you operated at, the trajectory.
• Top three accomplishments — the wins your manager should remember, with dates, metrics, artifacts.
• Growth and feedback — what you got better at, what feedback you acted on, what you'd do differently.
• Areas to develop — one or two, named specifically, with a plan for next cycle. Not weaknesses, not apologies.
• Looking forward — one paragraph on what you want to own next half, and one specific question for your manager.

Section 1: Summary (three sentences)

The summary is what gets read. Calibration meetings are time-pressed; many of the people who will discuss your rating will not read past sentence three. Use that constraint. Sentence one names the cycle headline. Sentence two names the impact. Sentence three signals trajectory.

Example: 'This half I owned the auth migration end-to-end and shipped feature flag service v2. The migration cut login latency 40% with zero downtime; the flag service replaced four in-house systems and unblocked 11 product teams. Heading into H2, I'm ready to take on cross-team technical leadership of the platform consolidation effort.'

Section 2: Top three accomplishments

Pick exactly three. Not five, not nine. The constraint forces you to actually rank them. Lead each with a one-line headline; follow with two or three lines of evidence: dates, metrics, the artifact, the cross-functional cast.

• Headline: 'Owned auth provider migration — 40% login latency drop, zero downtime'.
• Evidence: 'Scoped with security in March, dual-write phase shipped April 14, full cutover April 28. Runbook (link) adopted by platform team. Postmortem on the dual-write race condition (link) is now required reading for new hires.'
• Cast: 'Worked with [SRE], [Security], and [Product] across three teams.'

If you keep a brag document, this section is largely already written — you are extracting your top three impact items and adding evidence depth. If you do not keep one, this is the section that takes longest, because you are reconstructing from memory. The fix is not faster writing; it is a daily three-line career journal entry you start tomorrow.

Section 3: Growth and feedback

Two short paragraphs, max. The first names a thing you got better at and the evidence for it (a behavior, not a skill — managers can verify behaviors). The second names a piece of feedback you received and what you did about it. Both paragraphs end with a specific moment, not a generality.

Example: 'I got better at writing RFCs that name tradeoffs early. The auth migration RFC went through one round of review instead of three, and the design partner explicitly cited the alternatives section as the reason. Last cycle's feedback was that I shipped before aligning with downstream teams; this half I introduced a pre-RFC round of one-pagers and three projects that would have generated late surprises did not.'

Section 4: Areas to develop

This section is the trap. Most people either skip it (looks like lack of self-awareness) or list a generic weakness like 'time management' (signals you have not thought about it). The right move is to name one concrete area, scoped to the next level you are growing into, with a plan.

Example: 'I want to grow my ability to influence technical direction outside my immediate team. I have not yet written an org-wide RFC. Plan for H2: own the platform consolidation RFC; partner with [Senior IC] on the review process; aim to publish by end of M2.' This is hard to write because it requires admitting a limitation you can verify. That is exactly why managers trust it.

Section 5: Looking forward

Two sentences on what you want to own next cycle. One specific question for your manager — not 'do you have any feedback' (they always do, generically), but a real question about scope, calibration, or trajectory. 'I am hoping to own [area X] next half — does that align with what the team needs, or should I be looking at [area Y]?' The question is what the manager will respond to in writing, which becomes a paper trail for next cycle.

Phrases that work

• 'Owned X end-to-end' — beats 'led X' or 'helped with X' because it names the scope of accountability.
• 'Cut Y from A to B' — anchors a metric to a baseline. '40% faster' is forgettable; '2.1s to 1.3s' is not.
• 'Adopted by [team]' — shows your work was taken up beyond you, which is the test for impact above your level.
• 'Wrote the [doc] that became the team's [reference]' — names a durable artifact, not an event.
• 'Got better at [behavior]' — verifiable, beats 'improved my [skill]'.
• 'I would do X differently next time' — signals reflection without performing humility.

Phrases that don't work

• 'Helped with' — gives no signal about the size of your contribution.
• 'Was responsible for' — passive; says nothing about outcome.
• 'Worked hard on' — managers do not rate effort; they rate impact.
• 'Took ownership of' — empty buzzword unless you also name the artifact.
• 'I think I performed well' — opinion-of-self is the lowest-trust evidence in the document.
• 'Blew it out of the park' — undermines the data you just provided.

Worked example: senior engineer, H1 review

Below is a condensed self-review for a senior IC at a 200-person company. Anonymized. Five sections, fits on two pages. Notice that the summary names trajectory, the wins lead with impact and follow with evidence, and the areas-to-develop section contains a verifiable plan.

• Summary: This half I owned the auth migration and shipped feature flag service v2. The migration cut login latency 40% with zero downtime; the flag service replaced 4 in-house systems and unblocked 11 product teams. Heading into H2, ready to take on cross-team technical leadership of platform consolidation.
• Top win 1: Owned auth migration end-to-end — 40% login latency drop, zero downtime cutover April 28. Runbook adopted by platform team.
• Top win 2: Shipped feature flag service v2 — 11 teams onboarded, replaced 4 internal systems, p99 latency 12ms.
• Top win 3: Cut p99 checkout latency from 2.1s to 480ms across three commits — full writeup in eng wiki, presented at all-hands.
• Growth: Got better at writing RFCs that name tradeoffs early — auth migration RFC went through one review round instead of three. Acted on last cycle's feedback by introducing pre-RFC one-pagers; three would-be late surprises were caught.
• Areas to develop: Want to grow ability to influence technical direction outside immediate team. Plan: own platform consolidation RFC, partner with [Senior IC], publish by end of M2.
• Looking forward: Hoping to own platform consolidation next half. Specific question: does that align with what the team needs, or should I be looking at the API gateway rewrite instead?

How to write the whole thing in 90 minutes

• Block one 90-minute window. No phone, no Slack. Coffee, not lunch.
• Open your career journal and your brag document side by side.
• Spend 15 minutes pulling every candidate accomplishment from the cycle into a working list. Don't filter.
• Spend 10 minutes ranking by impact. Pick three. Cut the rest.
• Spend 30 minutes drafting the five sections in order. Keep each section short.
• Spend 20 minutes on phrases — replace 'helped with' / 'worked on' with the verbs from the phrases-that-work list.
• Spend 15 minutes on the looking-forward question. Make it specific. Make it answerable in writing.
• Stop. Send to your partner / closest peer. Submit tomorrow morning, not tonight.

Common mistakes

• Listing every PR — calibration meetings are time-pressed; the doc gets skimmed; nine wins read as zero wins.
• Padding with effort — managers rate impact, not hours.
• Using vague verbs — 'helped', 'worked on', 'contributed to' tell the reader nothing about your scope.
• Skipping the areas-to-develop section — reads as low self-awareness.
• Listing weaknesses instead of growth areas — calibration committees are not your therapist.
• Asking generic questions in the looking-forward section — 'do you have feedback?' is not a question that generates signal.
• Submitting on day-of — you will see something obvious to fix the morning after writing it.

Your self-review is not just a form to fill out. It's the document that shapes how your manager talks about you when you're not in the room. Bloomly doesn't write your self-review for you. That's not the point. The point is that you already did the work — Bloomly just helps you find it, organize it, and say it clearly. No more staring at a blank page. No more trying to remember what you did six months ago. Start with what you know. Build from there. Your next review doesn't have to feel like a guessing game.