Reasons why you should keep an impact log

An impact log (also called a “brag doc”) is your track record of accomplishments over a given period of time. I was encouraging someone to start writing an impact log recently and figured I would write up some of the rationale so others can benefit.

My own impact log

I’ve maintained an impact log/document for the last 3+ years. I keep an impact log for every half year: so 2022 H1, 2022 H2, etc. This both lines up well with dev talk seasons, and is long enough to capture accomplishments that have longer time/impact horizons (common if you’re working on multi-team projects). In this log, I’ll jot down (link/screenshot) anything I’ve done that I felt was important: helpful to an individual or team, helpful to the business in dollars or time saved, a strategic document or RFC that I wrote or co-authored that helped us get to an important milestone, or a feature for external or internal customers that has qualitative or quantitative utility.

When I finish something, throughout the course of that half year, I’ll get the thought “oh, I should put this in my log.” You can be more methodical if the inspiration doesn’t strike, and reflect on your contributions every week or two to fuel the content of the document.

If you’re struggling with what to put in there: either you’re too hard on your work and have trouble seeing its impact, or you’re working on low impact things (important to recognize early). If necessary, consider putting all that you finish in there and then revise it down with a trusted mentor to refine your sense of impact or your framing of the impact of your work. The mentor should also be able to curb overselling your work: where you fluff up what’s really a tiny incremental contribution trying to make it seem bigger than it is (this will do more harm than good in the areas I mention below).

When you’ll wish you had in impact log

Dev talks: Development talks are usually periodic checkins of your performance over the last 6 months or year. In those checkins, you directly or indirectly talk about what you’ve accomplished over that period of time. It’s much easier to populate this when you’ve been logging those accomplishments in your impact logs. If you instead try to remember your contributions over the last 6 months with the time crunch of finishing the dev talk self-evaluation, you’ll forget some important contributions. That affects your perceived performance, which affects your compensation and promotion prospects. This mismatch will make you resentful and your actual impact will suffer, when it could have been avoided with an impact log.

Promotion packets: some companies require that you assemble a packet of materials when applying for a promotion. In particular, this includes a self-assessment which asks you to enumerate your contributions across a number of dimensions of impact. This is usually the most taxing and tedious part of the packet. You’ll need to provide many concrete examples of impact spanning the last X months/years that you believe you were acting at that level. This is when you’ll kick yourself for not having an impact log. You have the next level of compensation and a title recognizing the complexity of your contributions at stake. Plus, maintaining an impact log gives you practice on framing/selling your contributions (e.g., Built Y feature that allowed 3 teams to reduce their time to alert resolution from 6 hours to 5 minutes), which is critical in a promotion packet.

When you get a new manager: Before maintaining my own impact log, I felt like every new manager I had was like starting over again: I would have to prove my impact and skills to them by rebuilding my track record, only for them to leave a year or two later. This was demoralizing and frustrating when I was in the heart of building key businesses for the company and wanted to be taken care of (compensated, recognized, and sponsored) for my outsized efforts. Now, for a brand new manager, I would consider sharing my impact log with them (or perhaps a personalized summary gleaned from aggregated impact logs) to seed how they perceive my intentions and contributions, as they increase their own awareness in the business.

1 on 1s: In a perfect managing-up situation, the impactful contributions that you put in an impact log would also be things your manager knows you’re doing ahead of dev talks. Now, saying “I just shipped Y feature that allowed 3 teams…” is a clear managing up play and a bit tasteless. They may have already seen your announcement about the deliverable as well. One possible way to mention the accomplishment without focusing on it could be to focus the discussion on a problem/issue/difficult-situation that arose during the development of that feature. As in, explore a coaching opportunity with your manager and the context of that situation is this feature you were building that was going to help 3 teams with their alert resolution times. Two for one ;)

Capture the great work you’re doing, so you can be fairly recognized and rewarded for those contributions!