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.
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.
Enrich - Quantify the Impact
Subjective writing from your raw notes is good, but objective data is better. You need to verify your claims with numbers. Do not do math in your head. Use scripts or AI to parse JIRA data, PRs data, and technical and business metrics. These numbers provide the backbone for your brag document.
If you can’t find data to support your claims, then you may have exaggerated your impact. That happens to all of us.
Create artifact - Using the output
This is the moment to write those entries in your brag doc. You write when someone asks for it, but your memory is your raw log, and the data look up to enrich the entries
We’ve used this information funnel for brag docs, but it has many more use cases.
Step 1 is the same: capture on a regular basis. Then you switch the prompts to refine and enrichment, and you can come up with the topics, blockers, and wins for your next 1:1 with your manager. You can also come up with the entries to update your CV and the anecdotes for your behavioral interviews.
Your manager and your team have availability bias: If you put in front of them the actions you took and the impact they created, you’ll seem more valuable than another engineer who did similar things, but they only provide visibility about their sprint tasks.
Conclusion
A brag document is the destination, but the daily log is the technique that gets you there.
It takes very little time to log and only a few minutes to pull the information into a cohesive statement that shows your impact. This saves you hours of stress in December and sets you up for success.
Your brag doc won’t ever be a blank page again. You’ll have tons of notes to share.
Open a blank text file right now. Write down one thing you did today. Congrats, you have now started your first information funnel.
This is an article inside our system to move from phase 3 to phase 4: Generate career capital. You’re already doing the important work, but you need to show it to others so the career capital keeps increasing and you earn enough for a promotion.
I’m building this system for paid subscribers. Thanks for your continued support!
🗞️ Other articles people like
👏 Weekly applause
Here are some articles I’ve read last week and liked:
Success is Asymmetrical by Kevin Naughton Jr.. Fail fast, ship often. Maximizing your shots on a goal to hit that one big home run.
How to Build Your First ChatGPT App by Jordan Cutler. You can now embed interactive UI tools right inside ChatGPT. This shows you how to hook up backend tools and React components.
Database Scaling and Performance Tips by Saurabh Dashora. A solid cheat sheet on database performance.
My LLM coding workflow going into 2026 by Addy Osmani. AI helps, but you still need to drive. I liked this post to remind me of good AI practices.
P.S. This may interest you:
Are you in doubt whether the paid version of the newsletter is for you? Discover the benefits here
Could you take one minute to answer a quick, anonymous survey to make me improve this newsletter? Take the survey here
Are you a brand looking to advertise to engaged engineers and leaders? Book your slot now
Give a like ❤️ to this post if you found it useful, and share it with a friend to get referral rewards
The fancy images are likely AI-generated, the not so fancy one by me :)
I would add that it’s a good habit to do it once every 1-2 weeks (if not everyday), right before your 1-on-1 meetings with your manager. The benefit is that you can ask for feedback right away. It is also more repeatable, and can be done in small chunks, instead of doing it all at once during the performance review.
Could you give me examples of the metrics you’re talking about? It reads like you’re saying to get the amount of epics closed etc. How do you frame that? Just volume of work done?