Brag Documents and Work Logs: Keep Track and Be Your Own Best Advocate

The best advocate for your next performance review, pay raise discussion, or promotion is yourself. Not even the best manager in the world will always have full insight into all of the things you’ve done and the full extent of the impact you created.

This is why you must keep a brag document and ideally an accompanying work log. It will help you actually keep track of everything, organize your achievements, and give you the data you need to advocate for yourself.

This is one of the biggest mistakes people make across all industries. Without writing things down and documenting your achievements, you cannot push for a pay raise or promotion. You will first be shot down (and likely lose motivation to even proceed) and then you will have to spend a lot of time and effort to retroactively document everything. In the process, a lot of data will likely be lost.

After you read this article, I implore you to sit down and start drafting your brag document! Then, add to it every two weeks and do a more extensive review every quarter. Block time in your calendar to do this. It’s a chore – but it will lead to high returns if done correctly!

How to Get Started

There are many different templates and formats. Here’s one Google doc work log template from Gergely Orosz that you can copy. I personally find it too detailed as it goes into the weeds of everything. Depending on your environment and role, this level might be something that you’ll need eventually, but it could also be overkill. Since you’re reading this, you’re probably not doing any tracking right now, so I suggest you start with something smaller than this and build up the discipline to practice it.

So, to start off make it simple:

1. Add an initial dump of all the major things that you did since your last review cycle. Try to keep this down to one page of text.
2. Every two weeks go back to doc and add anything new that deserves to be highlighted.
3. Every quarter, do a more thorough checkup and put in some work in the editing. You will eventually have to share this document with your management. Make sure it fits the writing and communication standards of your company.

Once you develop this discipline you can move to writing a more detailed work log. This log can serve as a dump of everything you’ve done, regardless of how small it might seem. Update it multiple times a week and provide all relevant links and attachments there. Your work log will then become a repository of data that you can pull from to compile the big items in your brag document.

Brag Document Template & Examples

My advice is to simply have one crisp paragraph for every major deliverable. Focus on what you achieved and what the impact was. Two powerful writing methods here could be the STAR method (Situation, Task, Action, Result) or the slightly simpler CAR method (Challenge, Action, Result.)

Here’s an altered example from my own brag document:

In Q4 2022 I lead the design and implementation of project [X] aimed to launch [n] new reporting capabilities and bring in an additional [n] customers to our platform. This involved the creation of a new service to perform [thing] and leading cross-team efforts with [team1, team2] to build a new data pipeline to support this launch. This new service was highlighted extensively in customer demos and workshops, leading to [n%] increase in reporting usage.

It’s straightforward and does not dwell on technical details – which means it can event be shared with a non-technical decision-maker. For them, the most important bit will be to to see the data points that show impact – the increase in the number of customer and reporting usage. You can back this paragraph further with an appendix with graphs that showcase these metrics and another appendix with links to major deliverable artifacts – the design document and the pivotal code reviews.

More Examples of Brag Document Entries

The example above is ideal and pretty easy to come up with because it is a straightforward example of building customer-facing features and there are existing metrics that were measured and compared.

But there are three other common types of (complex and important) work that are not easy to fit into this template:

1. Technical work that "keeps things running" and is not visible to customers. For example, improving your continuous delivery pipeline.
2. Unrelated minor activities – sometimes you work on a lot of different projects and tasks that, individually, cannot fit into a large narrative.
3. Projects where the where the expected outcomes were somewhat vague from the start and/or no metrics exist to demonstrate impact.

While I cannot cover every possible scenario, I can give a few examples that will show a general framework for handling this.

Example #1 – technical work without direct customer impact.

In Q3 2022 I worked on optimizing our build process by migrating from [thing] to [other thing] and reworking our testing framework. On average, a full production build in our pipeline took [n] minutes, but I was able to reduce it by [n%] down to [n] minutes. This has significantly decreased the time it takes for new features to ship to customers, improved developer experience, and made it possible for us to deliver a critical bug fix in under [X] minutes. Additionally, the faster build time has resulted in savings of [$n] per month, a [n%] decrease.

Notice the focus on metrics – always lead with data, don’t just use it as an afterthought. Ideally, you should already know the kinds of metrics you want to look at and what you want to accomplish before you even pick something up.

Example #2 – grouping multiple minor activities.

Throughout 2022 I’ve worked on several initiatives to improve the team’s operational excellence and incident response plans. I’ve restructured 50+ alarms based on real usage (they were based on hypothetical estimates), created a customer-facing status/uptime updates page, and improved our team’s oncall effectiveness by updating over 30+ SOPs. The team is now resolving tickets within a median of 1.2 days (previously 2.4 days) and our customers love the transparency of the updates page. (See testimonial and customer anecdote in appendix 1.)

Example #3 – goals without hard data to provide insights.

In March 2022 I worked with [person] on redesigning [screen] to improve the user experience after numerous customer anecdotes showed that [feature] was slow and unreliable. We’ve redesigned the flow and made it easier for customers to accomplish [goal] in fewer clicks and less wait time. This was a difficult technical challenge due to [reason]. We are not tracking metric [X] to further observe and monitor the performance of this feature and measure improvement, but initial customer feedback has been positive.

How to Share with Leadership

So you have your docs, what now? This depends a lot on the company you are in and the processes that your leadership follows. Here’s what I would do in different environments:

1. Scenario 1: you work at a small company and directly discuss performance/pay with your boss or a director. I recommend you share the doc directly with them during your next performance/pay review meeting. Go over it with them paragraph by paragraph and make sure they fully understand the importance of the hard technical problems that you solved and/or the impact you created.
2. Scenario 2: you work at a big tech company with many different orgs and teams and you report to an engineering manager. I recommend you first talk to your manager and understand how the review process works and what kind of role you can play to help in it. Ask them when these reviews take place and make sure you share the doc with them ahead of time so that all of your points can be included.
3. Scenario 3: you work at a big non-tech company and your report to a manager without an engineering background. This is a tough one – follow advice from #2 and also make sure everything in your sheet is data-driven and impact-orianted so that you manager can understand the importance and value of your work.