Get Your Work Recognized

Get Your Work Recognized

August 27, 2024·Christopher Tyler,Julia Evans

Reading Julia Evans’ article was a good reminder to document your work to help you get recognized. The rest of the article are my notes and additions after reading Julia’s excellent article.

You Don’t Remember Everything You Did

It is easy to document instead of trying to remember what you did 6 months ago. Sometimes it can be something significant but it could be something that was small but was on an important project. I currently use my weekly/monthly reviews.

Your Manager Doesn’t Remember Everything You Did

You manager won’t remember everything important you did either. I usually end up using my Performance Review but I feel that is far too late.

Write a Document Listing Your Accomplishments

Maintain a “brag document” that lists everything so you can refer to it when you get to performance review season. While I do a weekly/monthly list of my accomplishments, I think it would be helpful to put those in one running document. Also my list of accomplishments in my reviews is really just a simple bulleted list.

Share Your Brag Document with Your Manager

Giving your manager the document will help your manager advocate for you in discussions about your performance and come to any meetings they need to have prepared. A brag document can really help when you get a new manager especially when it comes close to a performance review.

Share it with Your Peer Reviewers

If you company uses peer feedback during performance reviews, it can be very helpful similar to how it can be helpful for your manager. While I have had previous companies that did peer reviews (aka 360 reviews), I don’t now.

Explain the Big Picture

Besides just listing your accomplishments, you can write the narrative explaining the big picture of your work. For example, I like how you do this by making a section for areas that I have been focused on (like “data management”) and listing all the work that I have done in that area there. This is the one main area I need to incorporate into my workflow. My reviews don’t help as I am mainly trying to capture what I did in that week.

Use Your Brag Document to Notice Patterns

Some questions it can you help with:

  • What work do I feel most proud of?
  • Are there themes in these projects I should be thinking about?
  • What is the big picture of what I am working on?
  • What do I wish I was doing more/less of?
  • Which of my projects had the effect I wanted and which didn’t? Why?
  • What could have gone better with project X? What might I do differently next time?

All are good questions. I also do lessons learned weekly as well as I attempt to do them after I do a software release. As you can notice a pattern, my current method there are many locations for the information and not one location for these for at least yearly.

You can Write it All at Once or Update it Every 2 Weeks

Try updating every 2 weeks but it may make more sense for you to do it every quarter or every 6 months. My plan is to basically do this instead of my monthly reviews.

Don’t Forget to Include the Fuzzy Work

For example:

  • Improving code quality on the team/making code reviews a little more in depth.
  • Making on call easier.
  • Building a more fair interview process.
  • Refactoring/driving down technical debt.

Don’t leave this out just because you are unsure how to explain why it is important.

  1. Explain your goal for the work (why do you think it is important to refactor X piece of code?).
  2. List some things you have done towards that goal.
  3. List any effects you have seen of the work, even if they are a little indirect.

If you tell your coworkers this kind of work is important to you and tell them what you have 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! This is also very important. I have done this multiple times where I have done major release that the final product for the users is basically the same. However, I streamline the code, increased code coverage, etc. Well verbally letting your manager/co-workers know is good, having this documented is better.

Encourage each Other to Celebrate Accomplishments

When you and maybe your coworkers maintain a brag document and share it with each other, is that everyone will encourage each other. Like Julia, I believe that cheering on your co-workers is mostly good.

The Brag Workshop

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.

Write the Document (1-2hrs)

Start going through your notes, commits, etc. the last 6 months and list the important items.

Pair up and Mark the Impact of Your Work Clearer (1hr)

The goal of this part is to pair up and review each other’s documents and identify places where people haven’t bragged enough.

Biweekly Brag Document Writing Session

Another approach to helping people remember their accomplishments is to get some friends together every couple of weeks or so for every one to update their brag documents. It is a nice way for people to talk about work that they are happy about and celebrate it a little bit and updating your brag document as you can go can be easier than trying to remember everything you did all at once at the end of the year.

Keep in mind you don’t have to all work at the same company or even in the same city (video chats).

Appendix: Brag Document Template

Usually I make one brag document per year. In the past (prior to seeing Julia’s article), I basically mimic whatever the Performance Review format would be and basically was filling it out as the year progressed. The problem with this method is that while I can basically copy-paste at the end of the year, it is also quite limiting.

It is 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 are including some graphs/charts/screenshots to show the effects of what you did.

Don’t try to make it 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 is 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! Note this should be similar to SMART Goals.

Goals for next year

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

Projects

For each on, 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 as 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 is 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 are an expert in.
  • Mentoring interns/helping new team members get started.
  • Writing really clear emails/meeting notes.
  • Foundation code that other people built on top of.
  • Improving monitoring/dashboards/on call.
  • Any code review that you spend a particularly long time on/that you think was especially important.
  • Important questions you answered.
  • Mentoring someone on a 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”.
  • Improving important processes, like the interview process or writing better on boarding materials.

What You Learned

Try listing important things you learned or skills you have acquired recently.

  • How to do performance analysis & make code run faster.
  • Internals of an important piece of software (ex. PostgreSQL).
  • How to use a library.
  • How to use an important tool.
  • About a specific area of programming (ex localization or time zones).
  • An area like product management/UX design.
  • How to write a clear design doc.
  • A new programming language.

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

Outside of Work

It is also often useful to track accomplishments outside of work:

  • Blog post
  • Talks/panels
  • Open source work
  • Industry recognition

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

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

Next Steps

While Q3 is nearly done, I plan on doing this in the next few months. My plan initially is to look at my monthly reviews and see what I put for my accomplishments and lessons learned and start there. I also want to create a personal and work brag document. My thinking is the work brag document is basically related to my actual job. My personal one can be career and non-career related stuff. That way I can easily share my work one with my co-workers and mangers without needing to review it first. Then I can use this to update my resume.