How to Use Your Brag Sheet to Ace Your Performance Review

You kept a brag doc this cycle. Maybe you used a Google Doc, a Notion page, or even a Notes app file. You have a list of things you did. Good.

But now review season is here, and you are realizing that a brag doc and a self-review are not the same thing. Your brag doc says "Shipped the new onboarding flow" and "Fixed the auth token bug." Your self-review needs to say something that makes decision-makers understand why those things mattered.

The gap between "here is what I did" and "here is the impact I had" is where most engineers get stuck. A brag doc is raw material. A self-review is a finished product. This guide shows you how to turn one into the other.

Step 1: Export and scan your brag sheet

Pull up your entire brag doc for the review period. Read through it without editing. Just get familiar with the full list. (If your brag doc is thin or you never started one, set up a low-friction tracking system now so next cycle is different.)

As you scan, mentally (or with a highlighter) mark items in three categories:

• High impact: Things that moved a metric, unblocked a team, prevented a major problem, or were visible to people outside your immediate team.
• Medium impact: Solid work that your manager would recognize but that did not change the trajectory of anything.
• Low impact: Tasks you completed that were part of your normal responsibilities. Bug fixes, routine code reviews, attending meetings.

Most brag docs are 70% medium and low impact items. That is fine. You do not need to include everything in your self-review. You need to include the right things.

Step 2: Select your top five to seven wins

Your self-review should focus on five to seven accomplishments. More than that and you dilute the strongest items. Fewer and you risk looking like you did not do enough.

Selection criteria:

1. Impact visibility. Did anyone outside your team notice this? If yes, it is probably worth including.
2. Alignment with level expectations. Does this accomplishment demonstrate skills at your current level or the next level? Prioritize next-level work.
3. Uniqueness. Would this accomplishment be on anyone else's self-review? If not, it shows your specific contribution.
4. Story quality. Can you explain why this mattered in two sentences? If the "so what" is hard to articulate, it might not belong in your top five.

Pull the top five to seven items from your brag doc. These become the backbone of your self-review.

Step 3: Rewrite each win in impact language

This is the most important step. Your brag doc probably says what you did. Your self-review needs to say what changed because of what you did.

The formula: Action + Context + Outcome

Brag doc entry: "Migrated the notification service to webhooks."

Self-review version: "Led the migration of the notification service from polling to webhooks, reducing notification delivery latency from 30 seconds to under 2 seconds and eliminating the daily timeout errors that affected approximately 12,000 users."

Brag doc entry: "Mentored the new hire."

Self-review version: "Mentored [name] during their first three months on the team. By the end of the cycle, they were independently handling production deploys and had shipped their first feature with minimal guidance."

Brag doc entry: "On-call for two weeks."

Self-review version: "Handled a two-week on-call rotation that included the March 8 database outage. Diagnosed and resolved the issue within 45 minutes, preventing extended downtime for 30,000 active users."

Notice the pattern: the brag doc version is an activity. The self-review version is a story with a measurable ending. If you struggle with the "measurable" part, the guide on how to quantify your impact for self-reviews breaks down exactly how to attach numbers to work that feels hard to measure.

Step 4: Organize by category, not chronology

Your self-review should not read like a timeline. It should read like a case for your impact.

Group your wins into the categories your review form uses. Common categories:

• Technical impact: Features shipped, systems improved, problems solved
• Leadership: Projects you owned, decisions you drove, people you mentored
• Collaboration: Cross-team work, communication improvements, unblocking others
• Growth: New skills, expanded scope, stretch assignments

Put your strongest wins first within each category. Reviewers are human. They pay the most attention to the first item in each section.

Step 5: Add the wins your brag doc missed

Brag docs tend to capture project work but miss other types of contributions. Before you finalize your self-review, check for these commonly overlooked items:

• Interviews you conducted. Hiring is a significant time investment and most companies value it.
• Documentation you wrote. Design docs, runbooks, onboarding guides. These have outsized impact relative to the time they take.
• Process improvements. Did you improve the team's CI pipeline? Introduce a testing practice? Fix the on-call runbook? These count.
• Informal leadership. Did you facilitate a design discussion? Resolve a disagreement between teammates? Step up when your team lead was out? These count too.
• Mentorship and support. Time spent helping others is easy to forget but often highly valued in calibration.

If any of these were significant, add them to your self-review even if they are not in your brag doc.

Step 6: Share your brag sheet with your manager

This is the move most engineers skip, and it is one of the most effective things you can do before review season.

Send your manager a curated version of your brag doc one to two weeks before reviews are due. Frame it as: "Here is a summary of my key contributions this cycle. I want to make sure you have the full picture as you write your assessment."

This does three things:

1. It reminds your manager of work they may have forgotten. Managers have five to ten direct reports. They cannot remember everything you did.
2. It gives your manager language to use in calibration. When your manager advocates for you, they will use the framing you provided.
3. It signals professionalism. Managers respect engineers who take ownership of their career narrative. Sharing your brag doc is not bragging. It is communication.

Common mistakes when translating brag docs to self-reviews

Listing everything. Your brag doc might have 40 items. Your self-review should have five to seven. More items at lower quality is worse than fewer items at high quality. Be selective.

Copying and pasting without rewriting. Brag doc language ("Fixed the auth bug") is not self-review language ("Identified and resolved a security vulnerability in the auth service that had been exposing session tokens for three months"). Every item needs the transformation from activity to impact.

Ignoring growth areas. Your brag doc is all positive. Your self-review needs at least one growth area. A self-review with no self-identified weaknesses reads as either lacking self-awareness or hiding something. Be honest about one area you want to improve.

Forgetting the team context. Your wins happened in a team setting. Acknowledge collaboration where appropriate. "Led the migration" does not mean you did it alone, and reviewers respect engineers who give credit to others while still owning their contribution.

The brag doc habit that makes all of this easier

If this process felt hard, it is because translating raw brag doc entries into impact language requires effort. The fix: write your brag doc entries in impact language from the start.

Every Friday, instead of writing "Shipped feature X," write "Shipped feature X, which [outcome]. This matters because [context]." It takes 30 extra seconds and saves you hours during review season. If you need a system for tracking wins without it feeling like homework, start there before your next cycle.