How to prepare for a performance review: from work log to self-review

Prepare for a performance review by keeping a short record as you finish work, then write your self-review from that record. For each task, note what you did, what changed, who asked for it, and the date. At review time, group the notes by project and write each group up as the situation, what you did, and the result.

Why start collecting months before the review?

Because you won’t remember most of it. When you sit down to write a self-review, the last month or two comes to mind first, plus whatever went badly. The quiet win from January and the afternoon you spent helping another team don’t make it in. The day you finish something, you know what changed. Three months later you’re guessing.

What should you write down?

Four things per task: what you finished, the result, who asked for it, and the date.

• Name the task so it still makes sense in six months. “Shipped retry queue for failed payments” is useful in July. “Done” is not.
• The result is what changed. Use a number if you have one; otherwise say who can now do something they couldn’t before.
• Who asked shows how far your work reached. Favors for other teams are easy to miss.
• The date keeps the order straight.

The result is the part people skip, and without it you just have a to-do list. If you don’t know the outcome yet, leave it blank and fill it in later. Write the entry when you finish. By Friday, Monday is already fuzzy.

How should you organize the notes?

Group them by project or area of ownership, or by goal if your review form is built around goals. Grouped entries show what built up in each area. Small tasks that fit nowhere go in a catch-all bucket. Keep them: something you did every month for half a year is worth a line of its own.

How do you turn a list into self-review sentences?

Give each sentence three parts, in order: the situation, what you did, and the result. The situation is why the work was needed, what you did is your part specifically, and the result is what changed afterward. Leave one out and your manager fills in the gap, usually not in your favor.

Several log entries often collapse into one sentence. If the result has no number, don’t invent one. Say what became possible.

Example: two self-review sentences from a half-year log

Dana, a backend engineer on the Payments team, grouped her first-half log by workspace:

First half (1/1 ~ 6/30)

[Payments]
2/03  Categorized a month of payment failures
      Result: mostly temporary card issuer errors
3/12  Shipped retry queue for failed payments
      Result: temporary failures retry on their own
4/21  Moved retry settings into config
5/28  Added dead-letter alerts (requested by Jihye)
      Result: manual reprocessing requests down from
      about 20 a week to one or two

[Onboarding]
1/15  Rewrote the local dev setup doc
4/07  Code review for both April hires
      Result: both merged a first PR in week two

[Uncategorized]
6/28  Month-end export for Finance, monthly
      since January (requested by Sam)

From that log, she wrote two sentences:

1. After finding that most payment failures were temporary card issuer errors, I built a retry queue with dead-letter alerts, which cut manual reprocessing requests from about 20 a week to one or two.
2. New hires kept losing their first week to dev setup, so I rewrote the setup doc and reviewed code for both April hires; both merged their first PR in week two.

The first sentence absorbs all four Payments entries; the config change stays in the log in case her manager asks. The Finance export gets its own line under other contributions.

What mistakes should you avoid?

The most common one is listing how busy you were.

Listing how busy you were

Forty meetings took real time, but your manager wants to know what changed. Collapse repeated work into one line and say what would have gone wrong without it.

Process with no result

Sentences ending in “investigated” or “in progress” leave the reader to guess. If there’s no result yet, say how far you got and what comes next. A failed attempt is a result too: say what you learned.

Mixing your work with other people’s

On a team project, spell out the part you owned. With four people on it, your manager reads about the same project four times, and if everyone writes “shipped the retry queue,” nobody stands out.

Overstating it

Claiming you led something you contributed to, or presenting a team number as your own, is easy for a teammate to spot. Once one sentence reads as inflated, the rest get discounted. Stick to what your log supports.

Doing this in DDirong

DDirong is a Korean-language web app for to-dos, schedules, work logs, and weekly reports. You add a task as one line, with # for a workspace and @ for who asked. When you check a task off, a result memo box opens so you can note what happened, or skip it.

At review time, you copy completed tasks as performance review text, grouped by workspace with each task’s title, completion date, and requester. Memos aren’t included, so you read them in the app and write the sentences yourself. Logging is free, and you sign in with Google.