Guide
A brag document is a private, running list of what you accomplished at work and why it mattered. You keep it so reviews, promotion cases and resumes start from evidence instead of memory. Any notes app works. If you forget what you did, Dayflow or Timing can show your Mac day, ActivityWatch suits cross-platform users, and WakaTime suits developers who want coding-time records.
A brag document is a private, running list of the work you did, what changed because of it, and the evidence that it happened. You add to it as you go, so that when a performance review, promotion packet or job search arrives, you are editing notes instead of reconstructing a year from memory.
Most people get it wrong in one of two ways. Some write it the night before a review, which defeats the whole point. Others treat it as a task list, which records effort but not outcomes. The name does not help either. It is less about bragging than about not forgetting.
Disclosure: we make Dayflow, one of the tools covered near the end. The rest of this guide is about the habit, which works with any text file.
It is usually one file where you record what you got done at work, written so that someone who was not there can understand it. A good entry answers three questions:
Julia Evans popularized the term in a widely shared blog post. Her argument was simple: managers forget, reviews squeeze a year into a page, and the work most likely to be forgotten is the quiet kind. Mentoring a new hire, fixing the flaky test everyone ignored, writing the doc that the whole team now links to. None of that shows up on a dashboard, and all of it counts.
Her suggested structure groups work by type, such as projects, collaboration and mentorship, and things you learned, rather than by date. That grouping matters. A chronological list reads like a diary. A themed list reads like a case.
A brag document has four properties that set it apart from other work notes:
These four documents overlap, and people often use one when they need another. Here is how they differ.
| Brag document | Resume | Performance self-review | Daily work log | |
|---|---|---|---|---|
| Main reader | You, then your manager | Recruiters and hiring managers | Your manager and review committee | You |
| When it is written | Continuously, all year | When job hunting | Once per review cycle | Every day |
| What it covers | Outcomes, impact and evidence | Career highlights | One review period, against a rubric | Tasks and time |
| Length | Long privately, trimmed to share | One or two pages | Set by the form | As long as it gets |
| Tone | Factual and specific | Polished and selective | Formal, mapped to criteria | Raw notes |
The brag document sits between the log and the self-review. The log is raw material. The self-review and the resume are finished products. The brag document is the layer in the middle where raw notes become claims you can stand behind.
If you want a log underneath it, a daily work log template works well as the capture layer. If your team already expects weekly updates, a weekly status report template can double as your Friday input, since most of what you report upward is also brag material.
Memory is the problem it solves. Most people remember the last month of work clearly and the rest of the year as a blur. Ask someone in December what they did in March and you will often get a shrug, even if March held their best work.
Managers have the same problem, multiplied by every person who reports to them. Your manager is not ignoring your work. They are holding a dozen people’s years in their head, and the details fade. When they sit down to write your review, they reach for whatever they can recall or find. A brag document gives them something to find.
Promotion decisions add another layer. In many companies, the people deciding on your promotion never worked with you. They read a written case. If the case is thin, the decision is thin. A year of specific entries lets your manager write a case with real examples instead of adjectives.
There is also a quieter benefit. Reading back through a few months of entries shows you patterns you would not otherwise notice: the kind of work you keep getting pulled into, the projects that drained you, the areas where you grew. That makes career conversations easier, because you come in with evidence about yourself.
Finally, some of the most valuable work leaves no trace by design. A fix that prevents an outage produces silence. A process change that stops a recurring mistake produces fewer messages, not more. If you do not write it down, nobody will.
The method below is a weekly loop. It separates capturing from writing, because trying to write polished entries in the moment is why most brag documents die in February.
Set up the file once. Create one document with a section for each theme you want to show. A practical set: projects and results, collaboration and mentoring, process and documentation, learning, and a scratch area at the top for raw notes. If your company publishes a career ladder or review rubric, use its categories as your headings instead.
Capture raw notes as things happen. One line is enough: “helped Sam debug the billing job,” “rewrote onboarding doc,” “led the vendor call when Ana was out.” Drop them in the scratch area. Do not edit. The goal is to not lose the event. If you struggle to recall what you did by the end of a day, read how to remember what you worked on.
On Friday, turn notes into entries. Take each raw note worth keeping and rewrite it in three parts: what you did, what changed, and where the evidence lives. Evidence can be a link to a pull request, a ticket, a design doc, a message thanking you, or a meeting where a decision was made. Delete notes that turn out to be routine.
Once a month, sort and tag. Move entries under the right theme. Mark the strongest ones. Add any results that showed up late, such as a feature you shipped in May that cut support tickets by the time July arrived. Outcomes often lag the work, so this is where entries get their second half.
Before each review, write the summary. Read the whole document. Pick the strongest entries under each theme. Write a short paragraph at the top that says what your year was about. Then share that trimmed version with your manager a few weeks before they have to write anything, and start a fresh section for the next period.
The loop costs little time once it is a habit. The Friday step is the one that matters most. Skip capture for a day and you lose a detail. Skip Friday for a month and the document stops being trusted, including by you.
This is a made-up example to show the process. The person, team and details are invented.
Maya is a backend engineer. On a Tuesday she spends the afternoon helping a teammate figure out why nightly data imports keep failing. Her raw note that day says:
helped with import job, turned out to be timezone thing
On Friday she turns it into an entry:
Fixed recurring nightly import failures (data platform). Traced the failures a teammate was chasing to a timezone mismatch between the scheduler and the source system, wrote the fix, and added a check so the job now alerts instead of failing silently. The on-call channel stopped getting the morning “imports are broken” message. Evidence: pull request and the incident thread where on-call confirmed the fix.
A month later, during her monthly sort, she adds one line under collaboration: “Paired with a newer teammate on the import bug and walked them through the scheduler, so they now own that job.” Same afternoon, two entries, two different kinds of value.
Compare that to how this would look if Maya wrote her brag document the night before her review: “Helped with various data pipeline issues.” True, and useless. Nobody can weigh it, and nobody can check it.
The same structure works outside engineering. A made-up marketing entry might read: “Rebuilt the webinar signup flow so registrations land in the CRM automatically. Sales stopped asking for manual exports each week. Evidence: the CRM workflow and the sales lead’s message in the team channel.” Specific action, visible change, a place to look.
Writing it once a year. This is the most common failure. By review time you are working from memory, which means the document holds the last few weeks and a vague outline of everything else.
Listing tasks instead of outcomes. “Attended planning meetings” and “worked on the dashboard” describe your calendar, not your contribution. Every entry should say what changed.
Using vague verbs. “Helped with,” “was involved in,” “supported” all hide what you actually did. Say whether you designed it, built it, led it, unblocked it or reviewed it.
Leaving out invisible work. Mentoring, interviewing, documentation, cleanup and incident response are often the strongest signals of seniority. They are also the first things people forget to write down.
Skipping evidence. An entry without a link or a pointer is a claim. An entry with one is a fact. Evidence also helps you, because six months later you may need to check the details yourself.
Taking credit for team work. Name the people you worked with and be precise about your part. A manager who knows the project will notice inflation, and it costs you more than modest phrasing ever would.
Making the shared version too long. The full file is for you. The copy your manager reads should be short enough to finish in one sitting.
Not knowing where your time went. If entire weeks feel blank when you sit down to write, the problem is upstream of the document. A quick pass with the where does my week go calculator can show how much of your week goes to meetings and interruptions, which often explains the blank spots and is worth knowing before a review conversation.
Keeping the only copy where you could lose access. If the file lives only on a work account, a job change can take it with you. Keep a personal copy you can reach, written in your own words, and follow your employer’s rules about confidential information.
The document itself needs nothing more than a notes app. Where tools help is the raw material: reminding you what you actually did on a given day so the Friday step has something to work with. The tool details below come from each vendor’s own pages as checked on October 4, 2026. For a wider look at the category, see our guide to choosing a time tracker for Mac.
| Tool | What it does for this | Price |
|---|---|---|
| Dayflow | Records the Mac screen at one frame every 10 seconds and has AI write a readable timeline of the day; export a date range as Markdown | $0 (MIT licensed); optional Pro at $20 a month |
| Timing | Records time automatically across Mac apps, websites and documents, with AI activity summaries on all plans | From $9 per month billed annually, or $11 per month billed monthly; no free tier, 30-day trial with no credit card |
| ActivityWatch | Records the active app, window title and away-from-keyboard time; browser extensions and editor plugins add detail; no AI summaries listed | Free and open source (MPL-2.0) |
| WakaTime | Editor plugins record coding time and AI usage per project, language and editor | Free plan with 1 week of dashboard history; full history needs Premium at $14/mo billed monthly, or $12.83/mo billed $153.96 yearly |
Timing is the strongest fit if you also need billable-hour records alongside your brag notes; we cover the differences in our Timing alternative comparison. ActivityWatch keeps everything on your own device and runs on Windows, Linux and Android as well as Mac; see ActivityWatch vs Dayflow. WakaTime only sees activity inside supported editors and terminals, which makes it narrow but precise for engineers who want a record of which projects took their time.
Again, Dayflow is our product. It fits when your problem is recall: you know you worked hard last Thursday but cannot say on what, and a written timeline plus a Markdown export (see exporting your work history) gives your Friday step real material to work from. It does not write the “what changed” half of an entry, its AI summaries can miss or misinterpret work so you should check anything before it reaches a review, and it has no team reports, invoicing, payroll approvals or website blocking.
If you are not on a Mac running macOS 14 or later, Dayflow is not an option, and ActivityWatch wins: it is free, open source and runs on Windows, Linux, Mac and Android. If your brag document is mostly about engineering work and you want per-project coding history, WakaTime wins, because it records exactly that from inside your editor. If you also bill clients by the hour and need reports and invoicing integrations, Timing wins. And if you already remember your week clearly, you may not need any tool at all. A notes file and a Friday reminder are enough.
A brag document is a running, private record of what you did, what it changed and how to prove it. Its value comes almost entirely from consistency: short notes when things happen, a few minutes every Friday turning them into real entries, and a trimmed version shared with your manager well before review season.
Start with an empty file and five headings today. Write down one thing from this week that would be easy to forget. If recall is the hard part, a tracker can supply the raw history, but the sentence that says why it mattered is yours to write.
The term is widely attributed to Julia Evans, a software engineer and writer, who published a blog post encouraging engineers to write down their accomplishments so their work gets recognized. Her post included a suggested structure and argued that managers cannot remember everything you did. People in many other jobs have since adopted the idea for reviews and promotions.
Usually yes, but share an edited version. Keep the full file private, then send your manager a trimmed copy a few weeks before reviews or promotion discussions. That gives them time to use it when they write about you. Remove anything confidential to other teams and any raw notes that only make sense to you. Some managers ask for one directly, which makes this easy.
The full running file can be as long as it needs to be, because only you read all of it. The version you share should be much shorter: a one-paragraph summary and the strongest entries grouped by theme, short enough that a busy manager reads it in one sitting. Length is not the goal. A few specific entries with evidence beat pages of vague ones.
No. Despite the name, a good brag document is a factual record, not self-promotion. It lists what you did, what changed and where the evidence lives, including credit for the people you worked with. Writing things down privately is not the same as boasting in public. It mostly protects you from your own forgetfulness and gives your manager accurate material to work from.
AI is useful for turning raw notes into cleaner sentences or grouping entries by theme. It is risky as a source of facts. An AI summary of your activity can miss work, misread it or overstate it, and it has no idea which results your manager cares about. Use it to draft, then check every claim against real evidence before anything goes into a review.
Anywhere you will actually open every week: a plain text or Markdown file, a notes app, or a private doc. Keep a copy you can still reach if you change jobs, but follow your employer's rules about confidential information. Describe outcomes in words rather than pasting internal data, so the personal copy stays useful without carrying anything you should not take with you.
Dayflow is Mac only (macOS 14 or later), so it is not an option there. ActivityWatch runs on Windows, Linux, Mac and Android, is free and open source under MPL-2.0, and stores data on your own device. WakaTime records coding time through plugins for 100+ editors and terminals, with a free plan that keeps 1 week of dashboard history.
Yes. The idea came from engineering, but any role with reviews benefits. A marketer can log campaigns and what they changed, a designer can log decisions and the problems they solved, a support lead can log process fixes and training. The structure stays the same: what you did, what changed because of it, and how someone could verify it.
It is one of the best inputs for a resume and interview prep. Each strong entry is a ready-made story: the situation, what you did and the result. When an interviewer asks about a hard problem you solved, you can pick from real, dated examples instead of improvising. Rewrite entries for an outside reader and leave out anything confidential to your current employer.
Dayflow is $0 and open source. Full recordings stay on your Mac, with local AI available for on-device analysis.
Download for MacOS macOS 14+ · MIT licensed · no account required