What should I write in my self-review?

You sit down to write your self-review and suddenly your brain decides to delete the last six months.

You remember shipping things. You remember fixing bugs. You even remember being tired, a lot.

But when the form asks "What impact did you have this cycle?" everything comes out weak:

• "Worked on the dashboard redesign."
• "Helped with reliability improvements."
• "Supported the team."

The problem is not that these things are fake. The problem is that they are incomplete.

Your software engineer self-review should explain what changed because of your work, how you know it changed, and what you personally did to make that happen.

That is the short answer.

But if you want the review to actually help you, you need to stop writing a task list and start writing evidence.

Let's break down how to start doing this on your own.

Start with the 5 things your self-review has to prove

A good self-review is not a diary of everything you touched.

Your manager already knows you attended meetings, reviewed PRs, and fixed tickets. That is the baseline. What they need from you is a clear record of the work that changed something.

For most software engineers, the self-review should cover five areas:

1. Business or product impact
2. Technical impact
3. Reliability and operational impact
4. Collaboration, mentorship, and glue work
5. Growth areas for the next cycle

You do not need a huge paragraph for every area.

You need your strongest evidence.

Think of your self-review like a packet your manager can use later, when you are not in the room. If the review only says "improved onboarding flow," it will not survive calibration. If it says "reduced onboarding drop-off 18% by simplifying account setup and instrumenting the missing analytics events," the work becomes much easier to defend.

That is the job of a proper self-review document, often called a brag document.

The basic format

Use this structure for each major accomplishment:

I accomplished [outcome] as measured by [evidence] by doing [specific work].

If you have read my guide on the XYZ framework, this will look familiar.

The point is simple: start from the change, attach proof, then explain the mechanism.

Before:

"Worked on improving the dashboard experience."

This is honest, but it does not help much.

What improved? For whom? How do we know? What did you specifically do?

After:

"Reduced dashboard load time from 4.2s to 1.7s by replacing client-side aggregation with a cached API response, improving weekly active user engagement 9% for account managers."

Now we have:

• The outcome: reduced load time
• The evidence: 4.2s to 1.7s, 9% engagement lift
• The mechanism: cached API response instead of client-side aggregation
• The audience: account managers

That is the difference between an activity and an accomplishment.

Now that you have the basic format, let's look at how to frame some of the most common types of engineering work.

What to write for product work

Product work is usually the easiest category to explain because there is an artifact people can see, but that can also make you lazy.

You shipped the feature, so you assume the feature explains itself. It does not.

Before:

"Built the new invite flow for team accounts."

This tells me what you shipped. It does not tell me why it mattered.

After:

"Increased team account activation 14% by rebuilding the invite flow, reducing required setup steps from 5 to 2, and adding recovery states for expired invitations."

Notice that the technical work is still there. We did not hide it.

But now it serves the outcome.

When you write about product work, ask:

• What user behavior changed?
• What metric moved?
• What customer problem became easier?
• What did you do that made the change possible?

If you do not have a product metric, use a proxy. Time saved, support tickets reduced, fewer failed attempts, faster completion, better adoption across teams.

Do not invent numbers.

But do not stop at "built the thing" either.

What to write for technical work

And here we are at the classic engineer dilemma. Technical work often gets undersold because we describe it in terms only other engineers care about.

"Migrated service from X to Y."

Cool. Why did that matter?

The migration itself is not the accomplishment. The accomplishment is what the migration made possible.

Before:

"Migrated billing service to the new queue architecture."

After:

"Reduced billing job failures 32% by migrating the service to the new queue architecture, adding idempotent retry handling, and improving failure visibility for support escalations."

This is stronger because it connects the technical decision to reliability and support impact.

For technical work, look for evidence like:

• latency reduced
• error rate reduced
• build time reduced
• deploy frequency increased
• incident count reduced
• engineering hours saved
• support escalations reduced
• systems made easier to operate

This is where many engineers struggle because the impact feels obvious inside the team.

Outside the team, it is not obvious.

Your self-review has to translate the technical change into a business, customer, or team effect.

What to write for reliability work

Reliability work is tricky because the best outcome is often that nothing bad happened.

No incident.

No outage.

No angry customer.

No emergency rollback on a Friday afternoon.

That makes the work easy to ignore in a review, unless you frame it as risk reduction.

Before:

"Improved monitoring for the payments system."

After:

"Reduced payment incident detection time from 40 minutes to 6 minutes by adding service-level alerts, dashboarding retry failures, and documenting the on-call escalation path before the Q4 traffic spike."

Now the work has teeth.

You are not just saying you improved monitoring. You are showing the risk you reduced.

For reliability work, ask:

• what failure became easier to detect?
• what incident became less likely?
• what recovery became faster?
• what customer, revenue, or team risk did you reduce?
• what would have happened if nobody did this work?

That last question matters a lot. Prevention is impact, but only if you document the avoided cost.

What to write for glue work

This is where self-reviews get painfully vague.

"Helped unblock teammates."

"Mentored junior engineers."

"Improved communication between product and engineering."

All of those can be real contributions. They can also sound like filler if you do not attach evidence.

Glue work needs the same treatment as code work: before state, action, after state.

Before:

"Mentored junior engineers on the team."

After:

"Helped 2 junior engineers reach independent ownership on frontend tickets by pairing weekly, reviewing implementation plans before coding, and creating reusable testing examples, reducing my direct escalation load from 6 requests per week to 2."

That is much more useful.

It shows scope, mechanism, and evidence.

Another example:

Before:

"Coordinated with product and design on checkout improvements."

After:

"Unblocked checkout redesign by aligning product, design, and backend owners around 4 edge cases before implementation, preventing late rework and helping the team ship the experiment 1 week before the planned release window."

Glue work becomes visible when you name the thing that would have broken without it.

If this is a recurring pain for you, read the Glue Work Matrix. It gives you categories for the work that usually disappears in review season.

What to write when you do not have perfect metrics

I know what you are thinking.

"Andrea, this is great when you have numbers. What if I do not?"

Fair.

Not every accomplishment has a clean dashboard metric. That does not mean you have no evidence.

You can use:

• time saved
• number of people unblocked
• number of teams adopting the change
• before and after process steps
• incident count before and after
• support tickets before and after
• bugs prevented or caught earlier
• customer complaints reduced
• review cycles shortened
• manual work removed

The point is not to force fake precision.

The point is to give the reader something concrete enough to evaluate.

Before:

"Improved developer experience for local setup."

After:

"Reduced local setup from a full day to under 90 minutes by containerizing dependencies, automating seed data, and documenting the 3 most common failure states for new engineers."

That is a valid self-review bullet even if no revenue metric moved.

Engineering impact is not only revenue. It is leverage, speed, reliability, quality, and risk reduction.

The mistake is pretending those things do not count because they are harder to measure.

What to write for growth areas

Your self-review should not be a sales page for yourself. It also needs to show judgment.

But be careful: many engineers write growth areas like a confession.

Before:

"I need to communicate better and improve planning."

This is too broad. It gives your manager nothing to work with.

After:

"I want to improve how early I surface delivery risk. In Q2, the reporting export work needed a scope adjustment after implementation started. For the next cycle, I will write a short risk note before starting projects with cross-team dependencies, including known unknowns, owner names, and fallback options."

That is much stronger.

It shows:

• self-awareness
• a specific situation
• a concrete behavior change
• a way to evaluate progress next cycle

Growth areas should make you look coachable, not careless.

Name the pattern. Name the example. Name the next behavior.

A simple self-review template

You can use this structure when you are stuck.

## Summary

This cycle, my work focused on [theme], especially [project area 1], [project area 2], and [project area 3]. The main impact was [outcome].

## Key accomplishments

1. [Outcome] as measured by [evidence] by doing [specific work].
2. [Outcome] as measured by [evidence] by doing [specific work].
3. [Outcome] as measured by [evidence] by doing [specific work].

## Collaboration and glue work

- I helped [person/team] achieve [outcome] by [specific support].
- I reduced [friction/risk] by [coordination/process/mentorship action].

## Growth area

One area I want to improve next cycle is [specific pattern]. I saw this during [specific example]. My plan is to [specific behavior change].

## Next-cycle focus

Next cycle, I want to increase my impact by [scope, ownership, technical depth, mentorship, reliability, or cross-team leverage].

Do not treat this as a form you fill with corporate words, treat it as a forcing function.
If a sentence does not show evidence, sharpen it.

Software engineer self-review examples

Let's put a few common examples side by side.

Weak version	Stronger version
Built new admin dashboard.	Reduced admin task completion time 28% by rebuilding the dashboard around the 5 most-used workflows and removing 3 redundant approval steps.
Fixed bugs in checkout.	Reduced checkout-related support tickets 22% by fixing 4 recurring validation bugs and adding regression tests around coupon and tax edge cases.
Helped with incident response.	Cut incident recovery time from 2 hours to 35 minutes by adding rollback documentation, clarifying on-call ownership, and automating the health-check runbook.
Reviewed PRs for the team.	Improved review throughput for the frontend team by creating a checklist for accessibility and state-management issues, reducing repeat review comments across 6 engineers.
Mentored a junior engineer.	Helped a junior engineer independently ship their first customer-facing feature by pairing on architecture, reviewing test strategy, and gradually handing off implementation ownership.
Improved CI.	Reduced CI runtime from 18 minutes to 9 minutes by parallelizing test jobs and caching dependencies, saving roughly 3 engineering hours per week across the team.

The stronger versions are not longer because longer is better, they are stronger because they answer "so what?"

That is the question your self-review has to answer again and again.

The real goal

Your self-review is not about sounding impressive.

It is about making your work legible.

The review process will always have some memory fade, some bias, and some missing context. You cannot fully control that. But you can control the quality of the evidence you bring into the room.

Start with your last three projects.

For each one, write:

• what changed
• how you know
• what you did
• who benefited
• what would have happened otherwise

That is enough to turn most weak self-review bullets into something useful.

And this is exactly why I started building careercraft.ing.

I wanted a way to capture engineering wins while they are still fresh, then turn those raw notes into review-ready evidence without waiting for panic mode at the end of the quarter.

Because by the time review season arrives, the hard part should already be done.