How to keep a brag document for review season

A brag document for review season works one way: you write it all year and assemble it in an afternoon. Written the week reviews open, it's just memory with formatting.

The good news is that "all year" costs about five minutes a week.

In short

Keep one running note per year; add a dated line each Friday about what you shipped, fixed or prevented.
At review time, sort the lines into your review form's categories and the draft writes itself.
Most brag documents die in the same predictable month, for the same reason. We'll get to it.

What is a brag document, quickly?

A brag document is a running record of your work accomplishments and their impact, kept so reviews don't depend on memory. Julia Evans' original post made the practice standard in engineering circles, and the core insight travels to any job: nobody remembers your work, including you.

How do you set up a brag document?

Create one document titled with the year, put it somewhere you already look, and give it a recurring five-minute Friday slot. That's the entire infrastructure. In practice:

One file, dated entries. No template needed. "12 Jun: caught the pricing bug before the release went out" is a complete entry.
Log outcomes, not activity. Not "attended migration meetings" but "migration shipped on time; deploy went from 40 minutes to 12."
Record the invisible work. Disasters prevented, people unblocked, the doc rewrite that stopped the repeated questions. Nobody else will ever log these for you.
Numbers when they exist, honesty when they don't. "Support tickets about onboarding stopped" is evidence without a metric.

Why do brag documents die by month two?

Here's the failure we promised: brag documents die in month two, when the novelty wears off and a Friday arrives that feels unremarkable. You skip it, reasonably. Three skips later the file is historical fiction and updating it feels like backfill homework, so you stop.

The fix is lowering the bar, not raising the discipline. An unremarkable week still contains a true line: "kept the release on schedule while two people were out" is a real entry, and the future you assembling a review will thank present you for its existence. If the bar question nags at you, we wrote about what counts as a win; the answer is the same at work.

How do you turn the document into a review?

Open the year's file next to the review form, group your lines under the form's headings, and expand the strongest into short paragraphs. What took a panicked evening last cycle takes an afternoon, and the result covers the actual year instead of a vivid final month.

Compare it with how last cycle probably went: form due Friday, memory offering only the recent past, and a year of work rated by how the last four weeks felt. The document's whole job is making that evening impossible.

One honest limit: a brag document presents your work fairly; it doesn't replace doing the work, and it won't fix a review process that was never going to be fair. It removes one failure mode, the self-inflicted one.

FAQ

What if the year is half over and I haven't started?

Start now and reconstruct what you can: sent email, calendar, commit history and closed tickets are honest memory prostheses. A half-year document still beats the alternative, which is a two-week memory in November.

How long should a brag document be?

As long as the year was. Fifty dated one-liners is a healthy document; you'll compress at review time, and cutting good material is a far better problem than inventing it.

Should I share my brag document with my manager?

A cleaned-up version, yes; most managers are glad to have it, since they're reconstructing eight people's years from even less memory than you have. Keep the raw file private so you never self-censor entries.

The Friday habit is easier if wins get caught the moment they happen instead of reconstructed at the keyboard. Cookie Jar, our free wins app, is the catch-all: one private line per win, on your phone, waiting to be mined when the review form opens.