May 23, 2026

How to track your accomplishments at work (before you forget them)

You already did the work. The hard part is proving it six months from now.

The standard approach is to reconstruct your year the night before your self-review is due. You open a blank document, stare at your calendar, and try to remember what you did. Some things come back. Most don't. What you end up with is a lopsided account of the last two months, with a few big wins from earlier in the year if you're lucky. This is not a personal failure -- it's just how memory works. The fix is not to try harder to remember. It's to stop relying on memory.

Some people use their commit history. Others use their email sent folder or their "done" column in Jira. These work for visible work that left a digital artifact. They don't capture the conversation that saved a project, the decision that avoided a bad migration, the afternoon you spent with a teammate who was about to quit. The most valuable work rarely leaves a clear trace in any system your employer already has.

The other thing these tools miss is framing. A commit is a commit. It doesn't record why it mattered, who was blocked before you fixed it, or what would have gone wrong if you hadn't caught it. An accomplishments log isn't just a list of outputs -- it's a layer of context that you're the only person positioned to write.

What's worth capturing: shipped work, yes -- but also decisions you made and why, risks you caught before they landed, people you unblocked or mentored, processes you improved, and influence you had without formal authority. The last two categories are consistently underrepresented in self-reviews, not because they're less valuable but because they're the hardest to reconstruct later.

The only system that works is capturing at the moment, not in retrospect. A two-sentence note at the end of a productive day costs thirty seconds. Reconstructing that same day six months later costs an hour and produces a worse result. The trigger that works best: end-of-day, or right after you finish something that took real effort or involved a real decision.

The goal isn't polish -- it's raw material with enough detail to answer a follow-up question months later. "Reviewed PR for payment service, caught the race condition in the retry logic before it hit prod" is perfect. "Did code review" is worthless. You're writing for your future self who needs to translate this into performance review language, not for an audience reading it today.

When review season comes, you're not reconstructing -- you're selecting. You read through months of entries, pick the strongest evidence for each competency your company cares about, and translate it into impact language: scope, effect, and what would have happened otherwise. The review writes itself because the raw material is already there.

Meritbook is built around this system: a private log where you capture as you go, then generate a review from your entries when you need one. Timestamps are tamper-evident so nothing looks backdated. But the system works with any tool -- a text file, a notes app, a private journal. The discipline is the same. Capture when it's fresh; select and translate when it matters.