Brag document for software engineers
Track what you shipped as system impact — latency cut, reliability gained, incidents resolved, teams unblocked — so a committee sees impact and scope, not closed tickets.
An engineer's brag document records what you shipped and what changed because of it — latency cut, reliability gained, incidents resolved, teams unblocked. It exists so a promotion committee sees impact and scope instead of a list of closed tickets, because that is the only thing they can actually act on.
Why engineers especially lose credit
Engineering produces an artifact trail — commits, PRs, tickets — which is a trap, because it tempts you to describe your work as volume. But volume isn't what gets you promoted. You reach the next level by doing qualitatively different work: more ambiguous, more cross-cutting, more strategic — not twice as much of your current level's work. A committee reads for impact and scope; "closed 200 tickets" tells them nothing they can use.
The other quiet loss is glue work. Code review, mentoring, design docs, incident response, the on-call save at 2am — none of it leaves a clean artifact, so unless you write it down, it's invisible exactly when it would help you most.
What to include — and what to cut
- Shipped features and the metric each one moved
- Performance: "cut p99 latency from 800ms to 180ms on the core API"
- Reliability and incidents: what you fixed and what it prevented
- Glue work: reviews, mentoring, design docs, on-call saves — and their impact
- Cross-team work that lifted other engineers, not just your own output
- Merged-PR counts and lines of code — output, not impact
- Ticket-closed tallies with no outcome attached
- "Worked on the platform" with nothing concrete
- Jargon a cross-functional committee can't read
- More of your current level's work, just more of it
How to prioritize
- System-level impact first — the metric you moved, stated plainly.
- Scope and ambiguity second — the undefined problems you owned end to end.
- Leverage third — the engineers you made better and the glue that held things together.
- Artifacts last, and only as links to design docs or dashboards.
Make it concrete
The reframe is always the same: name the change and its scope. "Reduced on-call pages 40% by fixing the flaky retry logic" is evidence a committee can defend. "Improved reliability" is not. A latency or error-rate number with one line of plain context beats a paragraph of jargon every time.
How Workfied helps here
Workfied turns a ten-second note — "shipped the caching layer, p99 down to 180ms" — into a dated, impact-framed entry, and quietly keeps the glue work you'd otherwise forget. So your engineering record is a running case, not a reconstruction from old commits. Workfied never reads from GitHub, Jira, or Slack — only what you send it. Encrypted in transit and at rest.
Evidence
Include vs cut
Cut merged-PR and ticket counts. Keep the metric each change moved — that's what a committee can act on.
Workfied house view
The quiet loss
Reviews, mentoring, incident response leave no artifact. Unlogged, they're invisible exactly when they'd help.
Source: Larson, Staff Engineer
The axis
You reach the next level with qualitatively different work — more ambiguous and cross-cutting — not more of the same.
Source: How to Get Promoted in Tech, 2026