I created a system to automate performance reviews
Ace your performance review as a software engineer. Beat recency bias with this 3-step brag doc system to track, refine, and quantify your daily impact.
Get the free AI Agent Building Blocks ebook when you subscribe:
It’s this time of the year again, and I’m not talking about Christmas.
Performance review season often brings what writers know as the fear of the blank page.
Your manager asked you to provide a list of highlights of your work this last year. You stare at a blank doc and try to recall what you worked on eight months ago. Your memory is not reliable. You suffer from recency bias and only remember the tasks from the last three weeks. You also suffer from hindsight bias: You overlook the difficult engineering work on projects that got canceled because they did not launch, or had unsuccessful business metrics.
We have to shift from viewing the brag document as a static chore to do when talent reviews are coming.
Some other people fight against this by introducing new entries in the brag doc upon project completion, or when important milestones happen. The problem here is not knowing when it’s the right moment. Take a look at this brag doc entry:
I led the design and implementation of [Feature Name] within the new [System Name]. I onboarded 3 mid-level engineers to the new stack and managed API dependencies with [Team X]. We delivered on time despite the high technical learning curve, enabling [Business Outcome, e.g., increase from 50 to 500 new daily users].
If I wait until I have the results of the project, I won’t remember what was complex at the beginning of the project. If I write when I’m starting or in the middle, I can’t tell if we’ll deliver on time, or if I will miss that I did a good job on the second half of the project, coordinating with a dependency.
Each entry should also be a living thing while the project is active and the information keeps flowing. I see this situation as an information funnel. You must separate the act of gathering information from the act of refining and presenting it.
In this post, you’ll learn:
That’s why I created this system to:
Capture daily actions
Refine
Enrich
Produce outputs that live longer than your memory.
Capture — The Daily/Weekly Raw Log
Another problem I saw when writing brag docs was that I’d often downplay my work. Even if a bug was complex to debug, when I found the root cause, it’d seem easy to fix, so I’d think it’s not worth an entry in the brag doc.
If you adopt this information funnel system, you won’t judge the data or try to make it look impressive yet. You simply need to record it. This approach solves writer’s block because you are not trying to write perfect prose or perfect numbers for your projects. Just use bullet points. Keep it under a few minutes per day.
You need to log more than just your wins. Record the long hours of debugging a complex race condition. Record the time you unblocked a junior developer on their environment setup. Record the decision to choose one library over another due to a technical tradeoff. Write the work on canceled projects. The business outcome might be zero, but the engineering output remains valid.
If you’ve been here for a long time, you know that I capture what I work on in my calendar, using time-blocking. At the end of the day, I go through my calendar and capture what I worked on in text. I don’t focus on what will look good or not. In the end, these are private notes, so I can write whatever I want.
What matters in this system is consistency in writing the work you’ve been doing. You can even dictate it, whatever works best for you.
Refine — Processing the information
This is your translation layer. You filter out the noise of routine tasks. You translate the signal into a language your manager understands. You turn a note about fixing a bug into a statement about resolving a critical latency issue that reduced page load times.
For brag docs, follow the standard of who, what, and when:
State when the work happened.
Describe what the context and result were.
Tag the peers and stakeholders involved.
This context is critical when you look back at your notes months later.
Recently, I processed my notes for the second half of 2025. I asked AI to port that into a brag doc, grouping by project and by certain criteria regarding the evaluation criteria of software engineers at Amazon.
Nowadays, with AI, this translation layer is pretty much automated. You only need to copy-paste from one place to another and give it a light read.