A brag doc is a place where you keep track of (and ideally show off) the work you’re proud of. You can call it what you want - A brag doc, personal wins, and impact list, whatever makes you feel the most comfortable sharing. Brag documents are helpful in any knowledge work career, but especially important in software engineering roles where career progress is largely connected to how well you demonstrate impact on the business.
How a brag doc helps software engineers
Maintaining a brag doc takes time, so many people are hesitant to start. There are plenty of reasons why a brag doc is worth the work. Most of these reasons point towards ways for you and your manager to avoid recency bias when thinking about your performance.
For starters, a brag document helps you remember what you did at work. This is a huge benefit to your career for a number of reasons, but a little-appreciated reason is that it gives you visibility into your time spent.
You can work ten times harder than anyone around you and it still not matter for your growth or career if you spent that energy working on the wrong things. A brag doc helps you retrospect on whether you’re actually executing on things that push you towards you goals.
The second benefit is that a brag doc helps your manager (and maybe even their manager) appreciate the value you bring to the business. Whether they’re thinking about your performance for review season or trying to justify a promotion, a brag document helps your leadership avoid recency bias. An organized list (we’ll get to that later) of what you did and why it matters gives clear visibility into your impact, which can only help you in performance reviews and promotion committees.
How to make a brag doc as a software engineer
If you’re still reading, maybe you’re convinced to make and maintain a brag document. You could start by just keeping a note of all the work you’ve done, but putting in a little extra effort goes a long way.
As a software engineer, you can start by going to your issue tracker or version control system like Jira or Github and copying work you’ve completed recently. Each item should have a “what you did” along with a “why it matters”. Something like “shipped this linked pr that fulfilled my team’s xyz OKR” is a great general format. Half an hour spent doing this ought to yield at least a quarter’s worth of work, which should give you enough space to start organizing.
The way you format your brag doc is largely dependent on your primary goal or audience, so there isn’t a one-size-fits all template. Most recently, the primary purpose of my brag doc was to make it easier for my manager to advocate for my promotion. I wanted to grow faster as a developer, and I wanted to get recognized for that growth.
Because of my goal, the format of my brag doc looked a lot like a promotion justification. I started tracking how the work I did aligned with the expectations outlined for the level above mine. After a year or so, I had a dense document that outlined how I was fulfilling the expectations of the role above mine, supported with links to design documents, code reviews, and pull requests.
These days I’m still sorting out the format of my brag doc, but I’m leaning towards aligning work under headers that represent goals I’m working towards for both my performance and areas I’d like to improve in.
It’s just as important to track work that isn’t explicitly found in a pull request or Jira ticket. Glue work like helping peers and responding to incidents is all valuable to the business, so it belongs on your brag doc. This is the hardest work to remember, so you may have to ask your peers or leadership if any work you did comes to mind as particularly helpful to them.
Conclusion
A brag doc is best done when updated regularly. Trying to do this on a yearly or even quarterly basis is playing life on hard mode. I have a regular calendar reminder to update my document every 2 weeks, which makes it pretty painless.
It’s up to you to shamelessly advocate for yourself. Keeping a running list of the impact you have definitely isn’t the most fulfilling work you’ll do as a developer, but it might be the most valuable for your career.