Brag Doc Template

    Senior Software Engineer Brag Doc

    A brag doc is a private running list of everything you've shipped, owned, and influenced — kept current so you don't have to reconstruct a year of work from memory at promo time. For senior engineers, the bar is no longer execution alone. Scope, technical judgment, and your multiplier effect on the people around you matter as much as the code you wrote. This template is structured against the criteria most engineering ladders actually grade on.

    Fill it in below. Saves to your browser automatically. Download when you're done.

    What to include

    At the Senior level, promotion packets are built on four things: technical impact (what shipped, with numbers), scope of influence (whose work did you change, beyond your own team), technical judgment (design decisions, tradeoffs, RFCs), and reliability ownership (on-call, incidents, durability of what you built). Each section below maps to one of these. Fill in 3–5 specific bullets per section. Be specific. Numbers, names, dates.

    Personalize

    Optional · Appears in download

    The template

    01

    Technical Impact

    Projects you shipped or substantially moved forward. The output, not the activity. Lead each bullet with the impact, then the work.

    • ·What did you ship that made a measurable difference (latency, scale, revenue, reliability)?
    • ·What broken thing did you fix that nobody else was going to?
    • ·What system did you build that other teams now depend on?
    • ·What did you deprecate or simplify (often more valuable than building new)?
    02

    Scope & Cross-Team Influence

    Work that reached beyond your own team — design reviews you shaped, RFCs you led, decisions that affected other org units.

    • ·Which RFCs or design docs did you author, and what did they change?
    • ·Whose architecture did you influence in a design review or pull request?
    • ·What cross-team initiative did you lead or unblock?
    • ·Where did you push back productively on a direction and change the outcome?
    03

    Multiplier Effect

    How you made other engineers more effective. Mentorship, code review patterns, onboarding, knowledge transfer.

    • ·Who did you onboard, and what's their trajectory since?
    • ·Which engineers cite you in their own self-reviews? Ask them.
    • ·What review comments or pairing sessions changed someone's approach?
    • ·What internal docs, runbooks, or talks did you produce that others now use?
    04

    Reliability & On-Call

    Incidents you owned, on-call rotations, the post-mortems and durability work you drove.

    • ·Which incidents did you lead or substantially debug? Link to post-mortems.
    • ·What durability work did you ship (alerts, runbooks, capacity headroom)?
    • ·On-call: what did you change to make the next rotation quieter?
    • ·What proactive risk did you flag and address before it became an incident?
    05

    Technical Judgment & Tradeoffs

    Decisions where the easy path was wrong. Build vs buy, refactor vs rewrite, scope cuts, dependency choices.

    • ·What did you choose NOT to build, and why was that the right call?
    • ·What tradeoff did you make explicit that others would have left ambiguous?
    • ·Which 'rewrite the world' temptation did you resist, and what shipped instead?
    • ·What dependency did you remove, replace, or refuse to add?
    06

    External Visibility

    Optional, but counts. Talks, posts, open source, community involvement.

    • ·Conference talks, lunch-and-learns, or recorded sessions given.
    • ·Blog posts, RFCs published externally, open source contributions.
    • ·Recruiting interviews conducted, candidates you championed who joined.

    Your entries save automatically in your browser. Nothing is sent anywhere.

    Opens your browser's print dialog · Choose "Save as PDF"

    Weak vs. strong bullets

    The format does the easy part. The bullets carry the weight. A few examples to set the bar.

    Weak

    Worked on the search service.

    Strong

    Led the search service rewrite: cut p95 latency from 850ms to 180ms (-79%) across team queries. Authored the design doc, ran 3 RFCs, mentored 2 engineers through migration. Zero customer-visible incidents during rollout.

    Weak

    Improved code review process.

    Strong

    Wrote the team's review guidelines after seeing 4 review threads stall for over a week. Drafted, reviewed by tech lead, adopted across team in Q2. Average PR cycle time dropped from 3.2 days to 1.6 days the following quarter.

    Weak

    Mentored junior engineers.

    Strong

    Onboarded Priya (joined Q1) — paired daily for 3 weeks, then weekly. She shipped her first production change in week 4 (team median: 7 weeks) and led her own RFC in Q3.

    Weak

    Was on-call.

    Strong

    Led debug of the Aug 14 ingestion incident (3hr partial outage). Wrote the post-mortem, shipped 2 of the 3 corrective actions personally — alert coverage on consumer lag (caught the same class of issue twice since) and a runbook for the on-call rotation.

    Manual template vs. Bloom generated report

    Manual brag doc

    • Works when you already remember the right examples.
    • Requires manual sorting, rewriting, and evidence cleanup.
    • Best for a one-time draft or printable structure.

    Bloom generated report

    • Starts from the work you captured when it happened.
    • Organizes entries by goals, skills, impact, and review period.
    • Turns daily evidence into shareable summaries and PDF reports.

    You don't fill out a Bloom report. Bloom writes it.

    The template above is the manual version. Bloom is the generated version. Thirty seconds when something good happens — speak it or type it — and at review time the entire document is in your share sheet. Same shape as the template. Your numbers, your names, your dates. Already written.

    Get Bloom for iPhone

    Free to start · iPhone · iOS 17+

    Build the evidence before you need the template

    Templates help with format. A career journal helps with memory. Use these pages together: learn the structure, generate a quick outline, then keep the source material current in Bloom.

    Brag document guide

    What to include and how to write stronger bullets.

    Brag doc generator

    Turn role, goals, and wins into an outline.

    Bloom career journal

    Capture the evidence that feeds your brag doc.

    Frequently asked questions

    Can I use this as a Senior Software Engineer brag doc app replacement?▾

    You can use the template manually, but it will only stay useful if you update it consistently. Bloom is the app version: capture wins daily, then generate reports when you need them.

    What should a brag doc include?▾

    A strong brag doc includes dated wins, measurable impact, collaborators, skills, feedback, decisions, evidence links, and review-category alignment.

    Is Bloom a brag doc app?▾

    Yes. Bloom is a brag doc app and career journal that keeps the source material current, then turns entries into performance reports, recaps, and reusable career stories.

    More engineering templates

    Engineering Manager

    Brag Doc