A Treatise on Brag/Hype Docs (Part 1)

"It’s not bragging if you can back it up."
Muhammad Ali

For the vast majority of my career, I had no formal way of tracking my progress – an unfortunate mistake. During yearly performance rounds at my previous company, I'd try to reflect on all the noteworthy things I had accomplished and write all the most relevant facts down. The intent being to show the best possible version of me to leadership. By doing that, I hoped it would translate into perhaps better raises, eventually a promotion and possibly more responsibilities.

At some point, after being dissatisfied with the outcome of performance rounds, I've realized something had to change – though I had no idea what. As I recall, my reaction at the time was one of frustration. There were two reasonable explanations for this mismatch in expectations: either I was underperforming/being average, or the perception of my performance was just poorly represented by myself. No need to say I chose to believe in the latter. Some time later, a former manager presented to me by chance the notion of keeping a brag doc (aka hype doc) for the first time – thanks Mike. The way I understood it at the time was as a shared document, which both of us had access to, in which I'd keep a bullet point list of things I did.

As far as I know, he pushed that for everyone who was doing 1on1s with him. Initially, I kept doing updates, but overall, it took me a while to have faith in the method. It seemed like my manager was delegating to me that which was his responsibility – how wrong was I. Nevertheless, there was one thing, I've felt very positive from the get go. That was the shorter iterations in which we ended up discussing my progress – a couple of weeks instead of a year. Waiting for performance rounds to have a systematic discussion on historical accomplishments/wins had only disappointed me so far.

That was just about the time when I had yet another change of management. By then I was already dead set on moving companies and had the fortunate opportunity to land a role at Yelp. Starting afresh was truly relieving. But there was one thing I wanted to do right this time. That was to ensure I got to be the best advocate of my interests – not my manager, not my team, no one, but me. Like in the poem, “The Road Not Taken” by Robert Frost: “Two roads diverged in a wood, and I— I took the one less traveled by”. And that has made all the difference.

Since then, I've been diligently keeping my brag doc and couldn't be gladder that I continued doing so. It has been a vital ally for building trust with my new manager rapidly and to adjust my career in its new work environment. Like a compass, guiding me through terrains I was previously unfamiliar with. On the other hand, being serious about maintaining a brag doc required significant effort and time, but certainly an amount that, I think, is well justified.

Naturally, one could push for having performance discussions without a brag doc, but experience tells me most of us developers aren't inherently comfortable in taking the lead in this matter – even though we should. In this sense, the brag doc forces us to stick to a healthy routine.

If you are interested in brag docs and consider starting one, you might be questioning yourself what yours should look like. Let me start by telling you that here is no ultimate format for your brag doc. It can look any way you want as long as it serves its purpose – imparting a narrative that is accurate to your trajectory. Mine, for instance, is akin to:

Thursday, 9th March 2023 (1 year+)**

Wins/Accomplishments
* …

Next challenges
* …

Tuesday, 7th February 2023 (1 year+)

Wins/Accomplishments
* …

Next challenges
* …

Even the most simple of brag docs must obviously have a bullet point list of accomplishments/wins for every given entry. An entry can be understood as a period, from the last time you presented it to your manager until now (i.e., the next presentation round) – a snapshot of your last work commit. Every month is my frequency of choice. I find a month granular enough that I have time to adapt in between quarterly performance evaluations at my current company. In that sense, I'd present the entry to my manager during a routine 1on1 meeting. Examples of accomplishments/wins I've previously mentioned are:

• Postmortems/documents/wiki pages I have written
• Projects I have led
• Presentations that I've produced
• Relevant trainings I've finished
• Situations I’ve gone above & beyond (e.g., hard bugs, status quo improvements, figured out something involving many moving pieces)
• Team process improvements I’ve championed
• Nonwork related things that make sense to be mentioned (e.g., presentations/talks/panels outside work, open-source contributions, blog posts you’ve written, interesting books that are worthy mentioning and are related)
• Relevant social activities I’ve organized
• Recruiting/mentoring related activities I've engaged into (e.g., interviewing, mentoring, social buddy)

Those accomplishments/wins are how I and my manager can backtrack through my story, whenever assessing my progress. It is also how you will be able to reflect on how work has been working for you. Are you proud of the things you have done? If so, perhaps you just need to double down on what you have been doing so far – with little optimizations here and there. Otherwise, something must change. It's time to think about how that can happen and, subsequently, speak with your manager for feedback.

Moreover, you will notice that I also keep track of my next challenges for each entry. Without it, I feel like I'd be telling only half my story. Although wins/accomplishments are important, doing things alone is no great feat. The Infinite Monkey Theorem is there to prove me right. By tracking my next challenges, which will likely become accomplishments/wins in my next entry, I ensure my accomplishments/wins are fitting a theme (e.g., a promotion I'm after, a career change, a focus on a new skill).

You do not have to overthink your next challenges. They might be some extra documentation you decided to write, since discussions during the last tech roadmap sync revealed your team had no consensus on how to best conduct a testing party – something I addressed recently. Alternatively, it can be about a design document you need to write for your next assigned project. In fact, even writing a blog post outside work hours might fit the criteria, provided it is related to the story you're telling. Furthermore, It is fine if you don't get to work on individual items before the next entry. Next challenges are, after all, just the current ideas that you think are worth pursuing – aspirations, not a must.

The greatest thing about sharing your next challenges with your manager is that they can help you to figure out a couple of things. First, your manager can identify if they make sense, provided the goals you've previously shared – ensuring you stay on track that way. Second, you'll show your manager that you are really putting the effort – not just throwing some empty words around. For all that matters, any reasonable person will feel more inclined to take you seriously if that's the case. Third, your manager might give you ideas about new or more impactful challenges you haven't thought about – this happened to me a few times already.

Finally, this is part of a two piece series on the topic of brag/hype docs. At this point, I believe you are genuinely interested in brag docs and might have all you need to start yours. That said, the difference between an average brag doc and a great one can be huge. Therefore, I've compiled a few additional best practices and pro-tips in part 2. They stem from my multi-year experience maintaining my brag doc and should spare you from perpetrating the same mistakes I did.