A Treatise on Brag/Hype Docs (Part 2)

March 16, 2023

workcareerbrag docs

"If you can't brag of knowing something, then brag of not knowing it. At any rate brag."
Ralph Waldo Emerson

At the surface, a brag doc seems like a simple enough technique. In fact, it can be and, even in the cases you don't put much effort, you'll start noticing its benefits, nevertheless – provided you give the method enough time. For optimal experience, though, I urge you to not become complacent. In part 1 of this brag/hype docs series, I've already shared a few things you have to pay attention to, in order to leverage your brag doc right. To continue in this journey, I'd like to proceed by sharing some additional best practices and pro-tips I've compiled:

Use active verbs

For each accomplishment/win bullet point, I start with an active verb in the past tense (e.g., developed, implemented, wrote, organized, led, presented, designed, sorted out, figured out, managed, analyzed, investigated, coordinated, kick-started, bootstrapped, championed). Just like I would, if I were writing bullet points for my CV/LinkedIn. As for my next challenges, I'd just use the same active verbs, but in the present tense. This is stylistic advice, but I find bullet points to be more concise to read when formatted this way.

Finally, run away from verbs like helped, collaborated, contributed, assisted, participated, and so on, which can make your efforts look weaker – diluted among team-wide accomplishments/wins.

Avoid recency bias

Imagine a diary. As the definition implies, it is a daily report, which describes events that are important to you as they happen – not months or weeks afterward. That's the case, because our capacity to retain events is limited and tends to distort as the time passes.

In this sense, one of the most common mistakes when maintaining a brag doc is to leave all the writing to the last minute – before presenting it to your manager. The only thing you guarantee by doing that is to fall into recency bias. That means, if you update your brag doc every month, you'll tend to focus on things that happened in say the last week, since your memory of those happenings is fresher. This situation is non-optimal, though. As you are just as likely to have interesting accomplishments/wins before that. To circumvent the aforementioned issue, my approach is to try to add bullet points to my next brag doc entry as soon as I can. That is what has worked best for me.

About you

Overall, I constantly strive to make my brag doc solely about me. Even when a colleague has collaborated to do something, it doesn't matter. My accomplishments/wins will convey my part only – perhaps by coming from a different angle of the story. Don't get me wrong. I'm not saying I try to get credit for what I haven't done. It would be silly of me to try to fool my manager, who recurrent 1on1s give a bird's-eye view on whom deserves praise for what. Likewise, It's not about avoiding recognizing the collective effort. As I've already mentioned, the goal of the brag doc is to tell the story of an individual – not a diffuse group.

Each one of us, as a protagonist, has a trajectory that deserves to be narrated through our own unique experiences. Besides, if you did X with somebody, saying that you did X still holds true – as long as you are not claiming you did it alone. Therefore, I prefer to leave any attribution matters out of it. The only exception, I'd make, though, is when the collaboration with someone else is per se an achievement/win. Recently, I had one of such when I claimed:

Invited PERSON_B for a couple of new initiatives (i.e., brag doc workshop and streamlining of testing party practices). Curious about how I can further improve my own team-wide impact by similar team ups.

Naturally, the outcomes of the brag doc workshop and standardization of our team's testing party practices above were also mentioned as separate bullet points. That said, this cooperation is aligned with a push I've been making for leadership related initiatives, so it deserved the spot. Remember, the brag doc is about the story you want to tell.

Consider impact, even if aspirational

In an ideal world, it's wonderful when I can say that, provided a given situation, I responded with X and that decreased say load time by Y % – for brag docs and CVs alike. The STAR method or similar, many of us are familiar with, all over again. Sometimes, though, I don't have a shiny metric to claim. Be it because there is no palpable thing to mention yet (e.g., a migration that will take multiple quarters) or because some effort failed (e.g., an A/B experiment, a core library that had no major adoption). The fact is not all tasks (e.g., writing documentation, refactoring code) can correlate well to a positive result (e.g., better, faster, something). And that's fine. Your achievements can still convey a compelling narrative, even if they are just aspirational.

For instance, I've recently started a brag doc workshop, in which part of my team participated. The bullet point in question looked like:

Moderated first Brag Doc workshop, which had an excellent engagement from participants. Everybody brought many points for us to work with, and I’ve commented on each point, in order to ensure they understand how to highlight their impact. Moreover, participants contributed to others’ brag docs by mentioning great things that they did – a neat side effect of participants that had been working together recently. Subsequently, during the days following the workshop. I’ve performed an extra round of reviews to ensure they were as polished as possible. For now, we decided to rerun the meeting in April when I’m back from vacation.

By doing that, I was hoping I could help teammates to learn how to create their own narrative. Narrative that would address two things: teach them how to establish a rewarding dialogue with their future selves and with their own manager. More often than not, I think frustration at work, assuming you're in a good environment and feel valued, stems from lacking the means to do either.

That's my belief, though, as I have no quantitative data to back it up. But you know what? It doesn't matter. My future self is interested in tracking my progress, which in my case includes a broad investment in mentorship initiatives such as a brag docs workshop. As for my manager, I believe it is in my interest for him to be aware of all my pursuits. Lead them to failure or not, so that he can help me do more of what pleases me or voice his opinion when I get to lose focus.

Simple things do matter

Simple accomplishments/wins can still be meaningful. Occasionally, it is obvious why you're doing it, like when you do a service release training that every engineer in your org is supposed to do. In such situations, I'll simply state I finished that particular training, for instance. No need to include a rationale in the text, although it is fine to extend your explanation when presenting the brag doc verbally.

When listing non-mandatory work, though, which has no metric or immediate positive outcome, try to explain why you're seeking it – give your manager a purpose. Proper assistance requires meaningful context.

Finishing a task isn't per se relevant

If you are just starting your career, it might make sense to mention all the small things you accomplish – like finishing milestone A on time or implementing some extra tests. For more experienced folks, individual tasks won't matter as much. It's just expected of you to perform at your current level, so cleaning up a failed A/B experiment doesn't say much.

Your manager will think you are simply doing your job. And after six months, when you read past entries in your brag doc, you will feel like you haven't learned much lately. That's a no win situation you should avoid at all costs. The sole exception I'd make refers to onboarding phases, through which I want to ramp my impact up as soon as possible. For instance, in my first brag doc entry as part of Yelp I wrote among other things that I:

Improved PRODUCT_A acceptance tests.
Watched all ENGINEERING_SERIES_A to get a better grasp of the company's architecture and design choices.
Familiarized myself with key repos (e.g., REPO_A, REPO_B, REPO_C, REPO_D, REPO_E), their processes as well as our products.

Under normal circumstances and due to my seniority, I wouldn't mention them, as I'd likely have more impactful work to claim. During onboarding, that's fine, though, as I want to quickly build trust and won't know enough to make more relevant contributions anyway.

Don't focus on what was expected of you

Accomplishing something sizeable as a senior engineer, such as a larger project involving multiple teams, might be brag doc worthy. That said, many times the grander objective isn't always the most important thing.

Upon reviewing a college's brag doc, I noticed he mentioned a task I knew he did recently. My initial reaction was to ask for more context. The rationale being that often the best stories are forgotten on the sidelines. He then mentioned this fascinating investigation he had to do, in which he interacted with a couple of other teams, in order to decide what to do. That was it. This new angle he showed was way more captivating than just finishing his task. It showed initiative, handling with other teams and capacity to reason over trade-offs. So, I just replied it was fine to say he did task A, but he should shift the angle. The investigation and its results should have the limelight instead, not just something he was again expected to do. We rephrased it together, and it ended up roughly like:

Investigated X as part of TASK_A, which involved negotiating with teams A and B. The investigation allowed …

Do you see how that is significantly better than just: “Finished TASK_A”? After all, anybody could have finished TASK_A. What is important to highlight is how you were able to do it better/differently than perhaps someone else.

Don't be your own veto player

The other day I was reviewing the brag doc of a teammate. It would be his first brag doc entry, so naturally he hasn't developed an eye for the big picture yet. In there, he added many bullet points that were totally valid, but he downplayed others. This person has been closely working on our team's last year transition to Scrum. This year, though, he had investigated a new tool that we started adopting for retrospectives. That was his task. The new tool had very engaging randomly generated icebreakers, which were a great improvement over our previously all the same icebreakers. Unsurprisingly, though, he didn't mention that as an accomplishment/win for the team. Was it because he felt he didn't really plan that to be the case? And, therefore, he didn't deserve praise for it. Perhaps, but honestly, it doesn't matter.

At the end of the day, there are seven billion people out there to veto you. They don't need yet another person's help. So, don't refrain from claiming something positive you managed to accomplish, even if you believe it wasn't that intentional.

There is no merit in mere participation

I see many engineers feeling frustrated because they thought their contributions to project A were essential, but somehow that image doesn't translate well to how their manager or colleagues comprehend it. The thinking process is that their absence would mean that project A wouldn't be delivered on time, or something like this. So, their efforts must have been crucial, right? I've already felt that way, to be honest. What I've soon realized was that, if I wasn't on the project, someone else would be. That someone else would eventually address the problem as well – perhaps worse, perhaps better than me. Hence, if you really think you did an outstanding job, try to put your facts together – beyond the obvious. Never forget this, and you will likely end up with an overall better brag doc.

Be intentional about your trajectory

Your brag doc isn't a list of checkboxes to tick before promotion. No, my friend, it's about your story so far and how it changes over the course of your career. That's how your manager is assessing your growth also, and that's how you should too. A couple of randomly isolated bullet points isn't going to change anyone's perception. So stop now. Reflect about what you want from work. What makes you happy? Do you see yourself continuing in an individual contributor (IC) track, or must you give management a try?

It's fine if you don't know where you want to be in the proverbial five years, but it is a huge mistake not to have a medium term vision at least. Why? Because the bullet points in your brag doc should reflect that story you are pursuing. Otherwise, you will end up looking just random – shooting in all directions. There needs to be a focus at some point. Oh, but I focus on everything, you might say. All those levelling criteria established by my company. No, you're not. Focusing on everything is the same as having no focus.

Not just about work

Since your brag doc is about your career and how it changes, at least in my opinion, it can also mention outside of work challenges/accomplishments. For instance, this very blog post you are reading, will end up as an accomplishment in my brag doc. Why is this relevant? I've recently been focusing a lot on mentoring initiatives, as aforementioned. Therefore, both me and my manager should be able to remember this fact. This is one of many things I did, which fits the umbrella of mentoring, just as the previously mentioned brag doc workshop.

What else? I've long communicated my intention to go after the next level as an individual contributor (IC) to my manager. For reasons, I won't be citing today. As a consequence, I've added a bullet point, in the next challenges section of my brag doc, stating that I'm currently reading “The Staff Engineer's Path” by Tanya Reilly. The precise bullet point is:

(outside work hours) Reading The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly, in order to continue growing leadership skills and figure out my own way.

Similarly, I was also interested in reviving my blog last year, but felt my writing lacking some soul. For that reason, I've also challenged myself by:

(outside work hours) Reading On Writing Well: The Classic Guide to Writing Nonfiction by William Zinsser, in order to further improve my writing and documentation skills.

Are you surprised I mentioned books I was reading outside working hours? If so, you shouldn't. That's completely aligned with my goals and is, therefore, noteworthy.

Keep an appendix

Your brag doc should make it easy to find relevant stuff on the things you're claiming. Your manager will thank you whenever the case for a promotion is being made. Moreover, I, personally, love the fact that I can find about just everything written/recorded that I ever produced in a single place. It just makes my life easier before performance rounds, when I'm preparing my argument for a level/sublevel advancement. So, if you have a bullet point referencing a project, which has a wiki page for instance, then hyperlink it. You are welcome to add all your deliverables (e.g., wiki pages, design documents, presentations, recordings, postmortems, documents) to your brag doc – in the form of a deliverable appendix. I do keep a deliverable appendix as well, by the end of my brag doc, and find it quite handy.

Connect the dots

In my opinion, the holy grail of brag docs occurs when you manage to connect your accomplishments/wins and next challenges, even when they refer to a different period. That shows thoroughness and intentionality – two indispensable senior qualities in my opinion. See the following bullet point of mine from the beginning of February 2023:

Handled the THIRD_PARTY_A incident, which required not only sorting out things with security, but also interacting with THIRD_PARTY_A representatives. Through the process, I’ve made THIRD_PARTY_A uploads more consistent with THIRD_PARTY_B approach, which favors AWS role reusability. To ensure the team was aware of the changes, the respective runbook was updated, and a deep dive was presented on the incident. AWS work was done in line with AWS permission work carried out as part of 2022 Q4’s FORMER_EVENT_TO_TACKLE_TECH_DEBT.

This allows you to attest a couple of things about me. I handled an issue, which involved interacting with a third-party and other internal teams. In the process, I've improved our setup to be more consistent. Then, I've updated the documentation on the matter and did a team-wide presentation to share my learnings. To put the cherry on top, I've ensured that our setup for the third party was made consistent with similar work I've pushed for in the past – as part of a team event in which we were tackling our tech debt. That's what I mean by connecting the dots.

Be engaging

When the time comes for you to present your brag doc to your manager, don't just recite the bullet points like a robot. Remember, you want to somehow imprint your positive outcomes in your manager's brain. So make it a dialogue. Do pauses and ask if everything is clear so far, after say reading a couple of bullet points out loud. Ask what's their opinion regarding one of the bullet points. Do they think it is worth putting some extra effort into a technology change you seem to be convinced about? Request them to keep you informed on how an aspirational outcome you've claimed was received by the team. Are there followups (i.e., possible next challenges) that could ensure a smoother adoption, for instance? Ultimately, your relationship with your manager is a powerful resource, so leverage it right.

Lucas' Refuge