Guides for engineering managers
Brag docs for your whole team: how managers track work between reviews
Brag docs are usually advice for engineers. Here's how managers can keep one for every person on the team in five minutes a week.
- A brag doc is a running list of what someone did and why it mattered. Most advice tells engineers to keep their own.
- Managers need the same thing for every person on the team, or review season becomes an exercise in memory.
- Keep it tiny: one dated line per notable thing, five minutes a week, one note per person.
- Write outcomes and examples, not activity, and share each person's notes with them.
The "brag document" became popular as career advice for engineers: keep a list of what you accomplished, so that when review or promotion time comes you aren't relying on memory. It works. It also puts the whole job on the engineer, and the engineers who most need one (newer people, quieter people, people doing glue work) are the least likely to keep it.
If you manage engineers, the useful move is to keep one for each of them. You are the one who writes the review, makes the promotion case, and decides who gets the next big project. Your memory is the bottleneck.
Why memory fails at review time
Ask any manager to list what a report did in March and they will struggle. What they remember is the recent, the dramatic, and the visible: last month's launch, the incident, the person who talks most in standup. That produces predictable unfairness:
- Recent work outweighs earlier work, so a strong first quarter gets forgotten.
- Visible work outweighs enabling work. The engineer who unblocked three teammates leaves no trail.
- Problems are remembered better than wins. One bad week can colour a whole review.
A running note per person fixes most of this, and costs far less time than reconstructing six months in one evening.
What goes in it
Keep one note per person, newest entries at the top. Each entry is one line: the date, what happened, and why it mattered. Things worth a line:
- Shipped something, or drove a decision that unblocked a project
- A thoughtful design doc, RFC, or code review
- Helped a teammate, onboarded someone, ran an interview loop
- Handled an incident well, or found the root cause
- Feedback from peers, other teams, or customers
- Something that went wrong, and what they did about it
- What they said they want to grow toward, in 1:1s
Example entries
- Oct 3. Found the root cause of the duplicate-webhook bug after two others had given up; wrote a clear postmortem that changed how we do retries.
- Sep 21. Reviewed 14 of the team's PRs this week while I was out; two caught real data-loss bugs.
- Sep 9. Missed the estimate on the export feature by two weeks and didn't flag it until the demo. Talked in 1:1: agreed to raise risks in the channel early.
- Aug 28. Said in 1:1 they want to lead a project end to end next half.
Notice that the third entry is a problem. A useful record is not only praise. It is what you will need to write a fair, specific review.
A five-minute weekly habit
- Block 15 minutes on Friday. Five minutes per three people is about right.
- Skim the week's trail: merged pull requests, closed tickets, launch announcements, your 1:1 notes, Slack threads where someone was thanked.
- Write one or two lines per person. If nothing stands out, write nothing. Empty weeks are fine.
- Once a month, read the whole note. Patterns appear: someone always pulled into incidents, someone who hasn't had a stretch project in months.
The format doesn't matter much. A private doc per person, a notes app, or a section at the top of your 1:1 doc all work. What matters is that it is quick enough that you keep doing it in a bad week.
Share it with them
We recommend keeping each person's notes visible to that person, or at least sharing them every month or so. It makes feedback continuous instead of a surprise at review time. It also gives them the chance to add what you missed, and they will always know about work you didn't see.
It should also go without saying that the note is about work and behaviour, not personality, and never something you'd be uncomfortable for them to read.
Turning it into a review
When review season arrives, you're no longer writing from memory. Read the note top to bottom, group the entries into themes (impact, how they work, growth), and pick the strongest two or three examples for each. Our guide on how to write an engineering performance review walks through that structure, and our performance review examples show what the finished text looks like.