There’s this idea that, if you do great work at your job, people will (or should!) automatically
recognize that work and reward you for it with promotions / increased pay. In practice, it’s often
more complicated than that – some kinds of important work are more visible/memorable than others.
It’s frustrating to have done something really important and later realize that you didn’t get
rewarded for it just because the people making the decision didn’t understand or remember what you
did. So I want to talk about a tactic that I and lots of people I work with have used!

This blog post isn’t just about being promoted or getting raises though. The ideas here have
actually been more useful to me to help me reflect on themes in my work, what’s important to me,
what I’m learning, and what I’d like to be doing differently. But they’ve definitely helped with
promotions!

You can also skip to the brag document template at the end.

you don’t remember everything you did

One thing I’m always struck by when it comes to performance review time is a feeling of “wait, what
did I do in the last 6 months?“. This is a kind of demoralizing feeling and it’s usually not based
in reality, more in “I forgot what cool stuff I actually did”.

I invariably end up having to spend a bunch of time looking through my pull requests, tickets,
launch emails, design documents, and more. I always end up finding small (and sometimes
not-so-small) things that I completely forgot I did, like:

• mentored an intern 5 months ago
• did a small-but-important security project
• spent a few weeks helping get an important migration over the line
• helped X put together this design doc
• etcetera!

your manager doesn’t remember everything you did

And if you don’t remember everything important you did, your manager (no matter how great they are!)
probably doesn’t either. And they need to explain to other people why you should be promoted or
given an evaluation like “exceeds expectations” (“X’s work is so awesome!!!!” doesn’t fly).

So if your manager is going to effectively advocate for you, they need help.

here’s the tactic: write a document listing your accomplishments

The tactic is pretty simple! Instead of trying to remember everything you did with your brain,
maintain a “brag document” that lists everything so you can refer to it when you get to performance
review season! This is a pretty common tactic – when I started doing this I mentioned it to more
experienced people and they were like “oh yeah, I’ve been doing that for a long time, it really
helps”.

Where I work we call this a “brag document” but I’ve heard other names for the same concept like
“hype document” or “list of stuff I did” :).

There’s a basic template for a brag document at the end of this post.

share your brag document with your manager

When I first wrote a brag document I was kind of nervous about sharing it with my manager. It felt
weird to be like “hey, uh, look at all the awesome stuff I did this year, I wrote a long document
listing everything”. But my manager was really thankful for it – I think his perspective was “this
makes my job way easier, now I can look at the document when writing your perf review instead of
trying to remember what happened”.

Giving them a document that explains your accomplishments will really help your manager advocate for
you in discussions about your performance and come to any meetings they need to have prepared.

Brag documents also really help with manager transitions – if you get a new manager 3 months
before an important performance review that you want to do well on, giving them a brag document
outlining your most important work & its impact will help them understand what you’ve been doing
even though they may not have been aware of any of your work before.

share it with your peer reviewers

Similarly, if your company does peer feedback as part of the promotion/perf process – share your
brag document with your peer reviewers!! Every time someone shares their doc with me I find it SO
HELPFUL with writing their review for much the same reasons it’s helpful to share it with your
manager – it reminds me of all the amazing things they did, and when they list their goals in their
brag document it also helps me see what areas they might be most interested in feedback on.

On some teams at work it’s a team norm to share a brag document with peer reviewers to make it
easier for them.

explain the big picture

In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?

In my brag document, I like to do this by making a section for areas that I’ve been focused on (like “security”) and listing all the work I’ve done in that area there. This is especially good if you’re working on something fuzzy like “building a stronger culture of code review” where all the individual actions you do towards that might be relatively small and there isn’t a big shiny ship.

use your brag document to notice patterns

In the past I’ve found the brag document useful not just to hype my accomplishments, but also to reflect on the work I’ve done. Some questions it’s helped me with:

• What work do I feel most proud of?
• Are there themes in these projects I should be thinking about? What’s the big picture of what I’m working on? (am I working a lot on security? localization?).
• What do I wish I was doing more / less of?
• Which of my projects had the effect I wanted, and which didn’t? Why might that have been?
• What could have gone better with project X? What might I want to do differently next time?

you can write it all at once or update it every 2 weeks

Many people have told me that it works best for them if they take a few minutes to update their brag document every 2 weeks ago. For me it actually works better to do a single marathon session every 6 months or every year where I look through everything I did and reflect on it all at once. Try out different approaches and see what works for you!

don’t forget to include the fuzzy work

A lot of us work on fuzzy projects that can feel hard to quantify, like:

• improving code quality on the team / making code reviews a little more in depth
• making on call easier
• building a more fair interview process / performance review system
• refactoring / driving down technical debt

A lot of people will leave this kind of work out because they don’t know how to explain why it’s important. But I think this kind of work is especially important to put into your brag document because it’s the most likely to fall under the radar! One way to approach this is to, for each goal:

1. explain your goal for the work (why do you think it’s important to refactor X piece of code?)
2. list some things you’ve done towards that goal
3. list any effects you’ve seen of the work, even if they’re a little indirect

If you tell your coworkers this kind of work is important to you and tell them what you’ve been
doing, maybe they can also give you ideas about how to do it more effectively or make the effects of
that work more obvious!

encourage each other to celebrate accomplishments

One nice side effect of having a shared idea that it’s normal/good to maintain a brag document at
work is that I sometimes see people encouraging each other to record & celebrate their
accomplishments (“hey, you should put that in your brag doc, that was really good!”). It can be hard
to see the value of your work sometimes, especially when you’re working on something hard, and an
outside perspective from a friend or colleague can really help you see why what you’re doing is
important.

Brag documents are good when you use them on your own to advocate for yourself, but I think they’re
better as a collaborative effort to recognize where people are excelling.

Next, I want to talk about a couple of structures that we’ve used to help people recognize their accomplishments.

the brag workshop: help people list their accomplishments

The way this “brag document” practice started in the first place is that my coworker Karla and I wanted to help other women in engineering advocate for themselves more in the performance review process. The idea is that some people undersell their accomplishments more than they should, so we wanted to encourage those people to “brag” a little bit and write down what they did that was important.

We did this by running a “brag workshop” just before performance review season. The format of the workshop is like this:

Part 1: write the document: 1-2 hours. Everybody sits down with their laptop, starts looking
through their pull requests, tickets they resolved, design docs, etc, and puts together a list of
important things they did in the last 6 months.

Part 2: pair up and make the impact of your work clearer: 1 hour. The goal of this part is to
pair up, review each other’s documents, and identify places where people haven’t bragged “enough” –
maybe they worked on an extremely critical project to the company but didn’t highlight how important
it was, maybe they improved test performance but didn’t say that they made the tests 3 times faster
and that it improved everyone’s developer experience. It’s easy to accidentally write “I shipped
$feature” and miss the follow up (“… which caused $thing to happen”). Another person reading
through your document can help you catch the places where you need to clarify the impact.

biweekly brag document writing session

Another approach to helping people remember their accomplishments: my friend Dave gets some friends
together every couple of weeks or so for everyone to update their brag documents. It’s a nice way
for people to talk about work that they’re happy about & celebrate it a little bit, and updating
your brag document as you go can be easier than trying to remember everything you did all at once at
the end of the year.

These don’t have to be people in the same company or even in the same city – that group meets over
video chat and has people from many different companies doing this together from Portland, Toronto,
New York, and Montreal.

In general, especially if you’re someone who really cares about your work, I think it’s really
positive to share your goals & accomplishments (and the things that haven’t gone so well too!) with
your friends and coworkers. It makes it feel less like you’re working alone and more like
everyone is supporting each other in helping them accomplish what they want.

thanks

Thanks to Karla Burnett who I worked with on spreading this idea at work, to Dave Vasilevsky for
running brag doc writing sessions, to Will Larson who encouraged me to start one of these in the
first place, to my manager Jay Shirley for always being encouraging & showing me that this is a
useful way to work with a manager, and to Allie, Dan, Laura, Julian, Kamal, Stanley, and Vaibhav for
reading a draft of this.

I’d also recommend the blog post Hype Yourself! You’re Worth It! by Aashni Shah which talks about a similar approach.

Here’s a template for a brag document! Usually I make one brag document per year. (“Julia’s
2017 brag document”). I think it’s okay to make it quite long / comprehensive – 5-10 pages or more
for a year of work doesn’t seem like too much to me, especially if you’re including some
graphs/charts / screenshots to show the effects of what you did.

One thing I want to emphasize, for people who don’t like to brag, is – you don’t have to try to
make your work sound better than it is. Just make it sound exactly as good as it is! For
example “was the primary contributor to X new feature that’s now used by 60% of our customers and
has gotten Y positive feedback”.

Goals for this year:

• List your major goals here! Sharing your goals with your manager & coworkers is really nice because it helps them see how they can support you in accomplishing those goals!

Goals for next year

• If it’s getting towards the end of the year, maybe start writing down what you think your goals for next year might be.

Projects

For each one, go through:

• What your contributions were (did you come up with the design? Which components did you build? Was there some useful insight like “wait, we can cut scope and do what we want by doing way less work” that you came up with?)
• The impact of the project – who was it for? Are there numbers you can attach to it? (saved X dollars? shipped new feature that has helped sell Y big deals? Improved performance by X%? Used by X internal users every day?). Did it support some important non-numeric company goal (required to pass an audit? helped retain an important user?)

Remember: don’t forget to explain what the results of you work actually were! It’s often important to go back a few months later and fill in what actually happened after you launched the project.

Collaboration & mentorship

Examples of things in this category:

• Helping others in an area you’re an expert in (like “other engineers regularly ask me for one-off help
  solving weird bugs in their CSS” or “quoting from the C standard at just the right moment”)
• Mentoring interns / helping new team members get started
• Writing really clear emails/meeting notes
• Foundational code that other people built on top of
• Improving monitoring / dashboards / on call
• Any code review that you spent a particularly long time on / that you think was especially important
• Important questions you answered (“helped Risha from OTHER_TEAM with a lot of questions related to Y”)
• Mentoring someone on a project (“gave Ben advice from time to time on leading his first big project”)
• Giving an internal talk or workshop

Design & documentation

List design docs & documentation that you worked on

• Design docs: I usually just say “wrote design for X” or “reviewed design for X”
• Documentation: maybe briefly explain the goal behind this documentation (for example “we were getting a lot of questions about X, so I documented it and now we can answer the questions more quickly”)

Company building

This is a category we have at work – it basically means “things you did to help the company overall, not just your project / team”. Some things that go in here:

• Going above & beyond with interviewing or recruiting (doing campus recruiting, etc)
• Improving important processes, like the interview process or writing better onboarding materials

What you learned

My friend Julian suggested this section and I think it’s a great idea – try listing important
things you learned or skills you’ve acquired recently! Some examples of skills you might be
learning or improving:

• how to do performance analysis & make code run faster
• internals of an important piece of software (like the JVM or Postgres or Linux)
• how to use a library (like React)
• how to use an important tool (like the command line or Firefox dev tools)
• about a specific area of programming (like localization or timezones)
• an area like product management / UX design
• how to write a clear design doc
• a new programming language

It’s really easy to lose track of what skills you’re learning, and usually when I reflect on this I
realize I learned a lot more than I thought and also notice things that I’m not learning that I
wish I was.

Outside of work

It’s also often useful to track accomplishments outside of work, like:

• blog posts
• talks/panels
• open source work
• Industry recognition

I think this can be a nice way to highlight how you’re thinking about your career outside of strictly what you’re doing at work.

This can also include other non-career-related things you’re proud of, if that feels good to you! Some people like to keep a combined personal + work brag document.

General prompts

If you’re feeling stuck for things to mention, try:

• If you were trying to convince a friend to come join your company/team, what would you tell them about your work?
• Did anybody tell you you did something well recently?