Write Self Review

Write Self-Review

Help an IC write a self-review that is specific, evidence-based, and strengths-first. A self-review is not just a form — it's preparation for a two-way performance conversation with your manager. Write it to represent your work accurately, so your manager has the full picture before the review meeting.

> Note: This skill helps you write the self-review document. The review meeting itself > is a separate conversation — but this document shapes what gets discussed.

---

Step 1: Gather context

a. Company template

Ask:

> "Does your company have a self-review template or form? If so, share it — I'll follow > that structure exactly. If not, I'll use a standard format."

If a template is provided, use it as the output structure. Map all subsequent steps into its sections.

b. Role and expectations

• Role title and level (e.g., Senior Engineer, Product Designer III)
• Review period (e.g., "2025", "H2 2025", "Q3-Q4")
• Goals or objectives set at the start of the period. If none were formally set: "What were the key expectations for your role during this period?"

c. Career framework

Ask:

> "Does your company have a career ladder or competency framework? You can share the > relevant section for your level, point me to a file, or skip it."

d. Rating scale

Ask:

> "What is your company's self-rating scale?" > > If none provided, default to: Outperformed / Delivered / Inconsistent

e. Evidence inputs

Ask what's available to draw from:

• Project notes, task trackers, or work logs
• One-to-one notes with your manager
• Pull requests, design docs, shipped features
• Metrics or dashboards you influenced
• Slack messages, emails, or feedback you received
• Peer feedback (formal or informal)

The more sources, the stronger the review. If the IC has limited records, work with what's available — but note that continuous documentation throughout the period produces better reviews.

---

Step 2: Coach on common pitfalls

Before writing, briefly surface these — they're the most common ways self-reviews go wrong:

Underselling (the most common mistake)

Most people undersell. You contributed more than you think. Watch for:

• Describing team outcomes without claiming your specific role
• Using "we" when you personally drove the work
• Omitting work you did that felt routine but was actually valuable
• Leaving out impact on teammates (mentoring, unblocking, knowledge sharing)

Overselling

• Claiming team outcomes as individual achievements
• Inflating your role in cross-functional work
• Taking credit for outcomes you influenced but didn't drive

The test: If a teammate read this, would they recognize your contribution as accurately described?

Vagueness

• "Helped with the migration project" — What specifically did you do?
• "Improved team processes" — Which process? What changed? What was the result?
• Every claim needs a specific action and a measurable or observable outcome.

Missing the "so what"

• Listing activities without outcomes. "Wrote 47 unit tests" means nothing without: "...covering the payment flow, which caught 3 regression bugs before release."
• Always answer: Why did this matter?

Ignoring difficulties

• Reviewers notice if you claim everything went smoothly. It didn't.
• Honest reflection on challenges shows self-awareness — a trait managers value.
• Frame difficulties as growth: what was hard, what you learned, what you'd do differently.

Personality vs. behavior

• Don't write about who you are. Write about what you did.
• Not: "I'm a strong communicator." Instead: "I led the weekly sync with the platform team, which resolved the API versioning disagreement in 2 weeks."

---

Step 3: Build the self-review

Anchor on the goals and expectations from Step 1. For each section, work through it with the IC.

3a. Achievements (strengths-first)

Lead with what you accomplished. Structure each achievement using Context → Actions → Results:

• Context: What was the situation or challenge?
• Actions: What did you specifically do? (Your decisions, initiative, execution — not the team's)
• Results: What was the outcome? Include quantitative evidence where possible:
• Metrics you moved (adoption, revenue, quality, speed)
• Timelines met or beaten
• Feedback received
• Problems prevented or resolved

Aim for 3-5 achievements. Group by theme if helpful (e.g., "Technical Delivery", "Team Contribution", "Process Improvement").

Calibration check for each achievement: "Am I describing what I did, or what the team did?" If the answer is "the team," zoom in on your specific contribution within that team effort.

3b. Team impact

Separately from individual achievements, capture:

• How you helped teammates (unblocking, pair programming, code reviews, onboarding)
• Contributions to team culture or processes
• Knowledge sharing (docs, presentations, informal teaching)

This section is often undersold. Explicitly prompt: "Did you help anyone get unstuck? Did you improve a process? Did you document something others now rely on?"

3c. Difficulties and learnings

Be honest. Pick 1-3 genuine challenges:

• What made it hard? (Not "the project was complex" — be specific about the difficulty)
• What did you learn?
• What would you do differently?
• What's still a work in progress?

Frame as growth, not failure. Managers respect self-awareness far more than a claim that everything was easy.

3d. Objectives assessment

Map each goal from the start of the period:

• State the original goal
• Assess: Achieved / Partially achieved / Pivoted / Not achieved
• Explain context — especially if goals changed or priorities shifted
• Note what was delivered instead if focus shifted

If goals weren't formally set, assess against the role expectations discussed in Step 1.

3e. Development plan

Propose 1-3 concrete actions for the next period:

• What skills do you want to develop?
• What experiences would help you grow?
• Connect to career framework if provided
• Be specific: "Lead a cross-team project" is better than "grow leadership skills"

Owning your development plan signals maturity and makes the review conversation more productive.

3f. Self-rating and justification

State your rating using the company's scale. Justify with specific evidence — reference the achievements and impact you documented above.

Don't agonize over the rating. State what you believe is accurate and why. Your manager may see it differently — that's what the review conversation is for.

---

Step 4: Review and refine

Before finalizing, check the draft:

| Check | What to look for | |-------|-----------------| | Specificity | Flag any vague statements. Every claim should have a concrete action or outcome. | | Evidence | Flag claims without supporting data or examples. | | Balance | Is it all positive? Add honest difficulties. Is it all negative? Surface the wins. | | Behavior-based | Flag any personality-based statements. Rewrite as observable actions. | | Accurate scope | Flag anything that claims team work as individual. Zoom in on your role. | | Goal alignment | Does the review clearly address the goals/expectations from the period? |

Suggest specific improvements for any flagged items.

---

Output format

If the IC provided a company template, follow it exactly.

Otherwise produce:

# Self-Review: [Name]
**Period:** [Review period] | **Role:** [Title & Level]

## Achievements
[3-5 themed C-A-R sections]

## Team Impact
[How you supported teammates, culture, and processes]

## Difficulties & Learnings
[1-3 genuine challenges and what you learned]

## Objectives Assessment
[Goal-by-goal assessment]

## Development Plan
[1-3 concrete actions for next period]

## Self-Rating
[Rating with justification]

---

Tone

• Write in the IC's voice, not corporate-speak. This should sound like a person describing their work, not a press release.
• Be confident without being boastful. State facts directly.
• Be honest about challenges. Self-awareness is a strength, not a weakness.
• Keep it scannable — the manager will read many of these. Use headers, bullets, and bold for key outcomes.
• Remember: this document prepares you for a conversation. Write it so your manager understands your perspective before you sit down together.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: PierrickMartos
• Source: PierrickMartos/Leadership-Skills
• License: MIT

Install and usage instructions live in the source repository linked above.