Brag Doc Template for Software Engineers (Copy-Ready Format)
Need a brag doc template?
Start logging wins in 30 seconds — no formatting needed.
Review season hits and you're scrambling to remember what you did six months ago. You know you shipped important work. You know there were late nights and hard problems. But when you open a blank Google Doc to write your self-review, all you can recall is your last two sprints and a vague sense that Q1 was busy.
This is the most common way engineers lose at promotion time. Not because the work wasn't there, but because they didn't write it down while it was fresh.
A brag doc fixes that. It's a running document where you record your wins, contributions, and growth as they happen. Not a polished self-review. Not a formal report for your manager. Just a raw, honest list of what you did and why it mattered.
Below is a copy-ready template you can paste into Google Docs, Notion, or any tool you already use. After the template, you'll find instructions for filling it out, real examples, and the mistakes that make most brag docs useless.
What a brag doc actually is
A brag doc is a personal record of your work accomplishments. Julia Evans popularized the term in the engineering world, and it's now standard advice across big tech. The idea is simple: write down what you did before you forget.
The reason it works comes down to how memory functions. Your brain is actively working to erase your wins faster than your failures. The production incident from March? Crystal clear. The architecture review where you caught a flaw that would have caused months of rework? Already gone. A brag doc fights that asymmetry by giving you a place to capture wins before they disappear.
A brag doc is not your self-review. It's the raw material your self-review is built from. The polishing happens later. The capturing happens now.
The template (copy this into Google Docs)
Copy everything below the line into a new Google Doc. Replace the bracketed placeholders with your own content. Delete the example entries once you understand the format.
BRAG DOC — [Your Name] — [Year]
Role: [Your title, team, company] Review period: [e.g., Jan 2026 - June 2026] Last updated: [Date]
Impact & Delivery
What you shipped, fixed, or improved. Focus on outcomes, not tasks.
| Date | What I Did | Why It Mattered |
|---|---|---|
| Feb 12 | Redesigned the retry logic in the payment service | Reduced duplicate charges from ~12/week to 0. On-call pages for this service dropped by 60%. |
| Mar 3 | Shipped the new user onboarding flow | Activation rate increased from 34% to 41% in the first two weeks after launch. |
| Apr 18 | Identified and fixed a memory leak in the recommendations service | P95 latency dropped from 800ms to 220ms. Saved the team from a planned capacity expansion. |
Technical Leadership
Design docs you wrote, architecture decisions you drove, code reviews where you caught real issues, standards you set.
| Date | What I Did | Why It Mattered |
|---|---|---|
| Jan 22 | Wrote the RFC for migrating from REST to gRPC on internal services | Approved by the architecture council. Three teams are now using it as reference. |
| Mar 15 | Pushed back on adding a fourth microservice in the payments design review | Team adopted my proposal to extend the existing API instead. Avoided 3+ months of unnecessary infra work. |
| Apr 5 | Created the team's on-call runbook for the new alerting pipeline | Reduced average incident response time from 25 minutes to 8 minutes for the next on-call rotation. |
Collaboration & Mentorship
People you unblocked, engineers you helped grow, cross-team work you coordinated.
| Date | What I Did | Why It Mattered |
|---|---|---|
| Feb 8 | Paired with Priya on her first production deploy | She deployed independently the following week. Her manager mentioned it in their 1:1. |
| Mar 20 | Coordinated the caching migration across three teams | All three teams shipped on schedule. No rollbacks. |
| Apr 10 | Ran two knowledge-sharing sessions on observability tooling | 15+ engineers attended. Two other teams adopted our monitoring patterns afterward. |
Growth & Learning
New skills, areas you stretched into, feedback you acted on.
| Date | What I Did | Why It Mattered |
|---|---|---|
| Jan-Mar | Took ownership of the team's CI/CD pipeline (first time owning infra) | Build times dropped from 18 min to 7 min. Learned Terraform and GitHub Actions at production scale. |
| Feb | Got feedback that I don't speak up enough in design reviews | Started preparing written opinions before every review. Manager noted the change in our March 1:1. |
Wins I Almost Forgot
The small stuff that doesn't feel like a "win" but adds up. Glue work, context you provided, fires you put out.
- Answered 30+ questions in the team Slack channel about the new auth library (Feb-Apr)
- Stayed late to debug a prod incident on a Friday. Found the root cause in 45 minutes. The previous on-call had been investigating for two days.
- Wrote three pages of context for the new hire so they could onboard to our service without shadowing anyone for a week.
What I Want to Work On Next
Skills to build, types of projects to take on, gaps to close.
- Lead a cross-team project end-to-end (not just the technical execution)
- Get more comfortable presenting to leadership audiences
- Go deeper on distributed systems design
How to fill out each section
The template has six sections. Here's what belongs in each one and what to leave out.
Impact & Delivery — Your core engineering output. Features you shipped, bugs you fixed, performance you improved. Every entry should answer: "What changed because I did this?" If you can attach a number, attach a number. If you can't, there are ways to construct one from the context you already have.
Technical Leadership — Work that shaped how your team builds software. Design docs, RFCs, architecture decisions, code review feedback that prevented real problems, standards or processes you introduced. This section matters most for engineers targeting senior and staff promotions.
Collaboration & Mentorship — People-oriented work. Mentoring, pairing, cross-team coordination, unblocking teammates, running knowledge-sharing sessions. This is the "glue work" that promotion committees care about but engineers rarely document.
Growth & Learning — New skills you picked up, areas where you stretched beyond your comfort zone, feedback you received and acted on. This section shows self-awareness, which is one of the strongest signals in a promotion case.
Wins I Almost Forgot — The catch-all for small contributions that don't fit neatly into the other sections. Answering questions, providing context, debugging someone else's issue, writing documentation. These add up. They also demonstrate scope and ownership beyond your assigned tickets.
What I Want to Work On Next — Forward-looking goals. This section is useful for 1:1s with your manager, mid-cycle check-ins, and framing your growth trajectory. It's not part of your self-review, but it keeps your brag doc connected to where you're heading.
Examples: raw vs. useless entries
The difference between a useful brag doc entry and a useless one is specificity. Here's what that looks like.
Useless: "Improved performance of the API."
Useful: "Identified a query bottleneck in the product search endpoint. Rewrote the query to use a covering index. P99 response time dropped from 1.2s to 180ms."
Useless: "Helped with onboarding."
Useful: "Paired with two new hires during their first two weeks. Both submitted their first production PRs within 10 days, compared to the team average of 21 days."
Useless: "Worked on the migration project."
Useful: "Owned the data validation layer for the payments migration. Wrote 14 integration tests that caught three critical edge cases before they reached production."
The pattern is always the same. What you did (specific action) + why it mattered (outcome, number, or consequence). You don't need both halves to be perfect every time. But "improved performance" with no detail is worth nothing in a self-review.
How often to update it
The short answer: every week or two. The long answer depends on what system works for your brain.
Weekly (Friday ritual) — Spend 5-10 minutes every Friday adding entries from the past week. This is the most popular method. Your calendar and recent Slack messages are good memory triggers. Most engineers who stick with a brag doc use this cadence.
Biweekly (sprint boundary) — If weekly feels like too much, update at the end of each sprint. You'll lose some detail on smaller wins, but you'll still capture the big ones. Better than monthly.
In the moment — Some engineers add entries right after a notable event: a deploy, a design review, a mentoring session. This captures the most detail but requires the habit of having the doc accessible. It works well if you keep the doc pinned in a browser tab or bookmarked on your phone.
The method matters less than the consistency. A messy brag doc updated every Friday beats a beautifully organized one that hasn't been touched since February. The key is making it feel low-effort enough that you actually do it, not turning it into a writing project.
What a brag doc feeds into
Your brag doc isn't just for self-reviews. It's the source material for multiple career conversations.
- Self-reviews — Instead of staring at a blank doc during review season, you scan your brag doc, pick the 8-10 strongest entries, and polish them. One afternoon of work instead of a week of anxiety.
- 1:1s with your manager — Pull two or three recent entries into your next 1:1. This is how your manager learns what you've been doing. They have 6-10 direct reports. They're not tracking your wins more carefully than you are.
- Promotion packets — A promo packet needs specific evidence organized by rubric dimension. Your brag doc is the evidence bank. Without it, you're reconstructing six to twelve months of work from memory.
- Skip-level meetings — When your skip-level asks what you're working on, you want concrete answers ready. Your brag doc gives you those in seconds.
- Job interviews — The "tell me about a time when..." questions are dramatically easier when you have 50+ documented examples to pull from.
Five mistakes that make brag docs useless
Most engineers who start a brag doc abandon it within a month. Here's why.
Only tracking big wins. If you only write down launches and major milestones, you'll have 3-4 entries after six months. That's not enough. The small stuff, the debugging sessions, mentoring conversations, design review feedback, adds up. Document it.
Writing too vaguely. "Worked on the API refactor" tells you nothing six months later. Force yourself to include one specific detail: a number, a name, a before-and-after comparison. Future you will thank present you.
Polishing entries as you write them. Your brag doc is not a performance review. It's a raw capture tool. Write ugly, incomplete sentences. Fix them later when you actually need them for something. If each entry takes more than 60 seconds, you've set the bar too high.
Forgetting collaboration and mentorship. Engineers default to tracking code they shipped. But promotion committees at most companies evaluate collaboration, mentoring, and cross-team influence just as heavily. If your brag doc is 100% technical delivery, it's missing half the picture.
Not including context for "why it mattered." "Fixed a bug" is a task. "Fixed a bug that was causing 200 customer-facing errors per day and was the top support ticket for three consecutive weeks" is a win. The context is what makes the entry useful. Without it, you'll read your own brag doc in November and have no idea why you wrote it down.
Start today, not next Monday
The best time to start a brag doc was six months ago. The second best time is right now.
Copy the template above into a Google Doc. Spend 10 minutes filling in what you can remember from the past month. Set a recurring calendar event for Friday afternoons. That's the whole system.
You don't need a perfect document. You need a running list of evidence that proves you did the work, so that when review season arrives, you're assembling a case instead of trying to remember one.
CareerClimb captures your wins as they happen, so you never scramble for examples at review time. Your evidence, always ready. Download CareerClimb
