🔱 3+1 strategies to track your achievements

Discover expert strategies for software engineers to get promoted at work. Learn how to create a public page, work log, and brag doc to boost your career. Unlock the path to becoming a senior software

How do you track your achievements?

At the beginning of my career, I had one document where I listed all my achievements.

At first, I wrote down everything I did.

Later on, I realized not everything was important enough to add it.

It was hard to decide if something should go to the document or not.

I had trouble removing work from the past. In the end, it’s my hard work.

Needless to say, that document was a Frankenstein without a storyline.

But that’s not my process now.

⭐ In this post, you’ll learn:

• The strategy to validate your intentions

• The strategy to record periodically your achievements

• The strategy to socialize your achievements and make them stand the test of time.

• Extra strategy: How to prepare 1:1s without effort

🪷 #1 Validate your intentions

Strategy: The public page.

In software engineering, we talk about planning and designing before we jump into code

The same applies to our priorities.

The first time I found this idea was from Stephen Wan in an interview shown in Will Larson’s book “Staff Engineer: Leadership Beyond the Management Track”. Another example is Thomas Frank’s public page (outdated)

Your priorities on your public page determine what you say “yes” and “no” to. Having them public, you can validate them with your managers. And you don’t need excuses to say “no” to some piece of work. Just share this page.

Also, you write your milestones for each week.

You can visualize if you are overcommitted or not working on your priorities. And you can keep validating them from the planning phase, not once you are committed to them.

I do this document but I keep it private. Writing this post I realized that I’d benefit from socializing it for validation

📆 #2 Record periodically your achievements

Strategy: The work log

Everybody fears the blank page.

With a work log, the structure is clear: One entry per week, record any relevant thing you did that week.

It doesn’t matter how it fits in the big picture, just write and capture your actions, their impact, and links to artifacts.

Here’s an example of my last couple of weeks.

Notice that I lack impact, all these proposals have not yet been implemented.

But that’s why this works. I don’t have to wait until a project finishes to write about it. By the time the project finishes, I’ll have forgotten about the details of the start.

The bigger your scope, the longer the feedback loop of your actions.

📕 #3 Communicate a narrative

Strategy: Work summaries and a brag doc

The brag doc is this document where you write entries like “I did <> and created <> impact”.

You highlight your achievements and relate them to:

1. Criteria in your role guidelines for the next level.

2. Business impact and company/org goals.

This is the doc you share with your manager before a performance review or the doc you share to build your promo package.

When you work on big initiatives, there are a lot of entries around the same topic.

You wouldn’t want to mix <Project A> technical design with an improvement in your team meetings and then <Project A> again…

That’s where work summaries come in. They are essentially a brag doc but with a cohesive narrative.

I have a brag doc where I write impact I have in isolated situations

And I aim to build work summaries from the work that spans months.

To write such a narrative, you need the finish the project and see the big picture. After you read your work log, you can give a proper structure.

I wrote one of these work summaries last year:

1. I collected all the work (inputs) I did.

   1. Technical design of a new service and integration with Amazon’s Search services.

   2. Technical design for the migration to the new service for AddToCart button.

2. I related them to multiple criteria to move to the next level. Here are a few of the ones on my list:

   1. [SCOPE & INFLUENCE] Influence the team’s long-term technical investment

   2. [EXECUTION / AMBIGUITY] Work efficiently, delivering frequently and incrementally. This work brings clarity to problems where the solution was originally ambiguous, technology strategy not yet defined

   3. [EXECUTION] Seek diverse perspectives and feedback

3. I explained how my actions created the outcomes of the project and how they relate to business goals. Some of the metrics I collected were:

   1. Increased coverage of search queries that showed AddToCart from 10% to 80%

   2. Generated a cumulative yearly revenue increase of $ <> after all expansion phases.

   3. Reduced Infrastructure yearly cost by $ <> thanks to the re-architecture.

It’s not enough with the bullet points. You have to wire them together into a story.

But under the hood, all good story has a structure. That’s what creates a good signal-to-noise ratio.

🎯 Conclusion

As you can see, having a work log helps in writing a narrative in a separate doc.

I learned the hard way this lesson: The information you capture is not the same information you should present.

Otherwise:

• You’ll overthink what to capture and what to leave out.

• You’ll overload your audience with useless information

I’m a firm believer in studying every day instead of rushing the day before the exam.

Do the same with your career. Put your systems in place to work in the right direction and capture the impact.

---

🎁 Here’s a free Extra strategy:

In your 1:1s it’s typical to do a brief status update of what you have been doing.

To avoid dedicating the entire time to status updates, I keep pointers in my work log to know what to base my update on.

This is a very low-effort way to prepare that part of the 1:1. After just 5 minutes of status update, I have the rest of the meeting for the 1:1 conversation.

---

👏 Weekly applause

• Guide to Leading Meetings for Software Engineers by

  High Growth Engineer
  . If you want to be an effective engineer you need your meetings not to slip through your hands. Jordan gives very valuable tips on this one.

• How Zapier Automates Billions of Tasks by

  System Design Newsletter
  . Interesting to see how Zapier models each zap for different purposes: Storing in a MySQL database, storing the id in a queue for async processing, and indexing in an ElasticSearch

• Hungry Minds by Alex Zajac. Alex curates news and articles in a weekly issue of his newsletter. It’s the best way I know to keep myself up to date!

• Processing millions of messages with Queues and Event Hubs by

  Byte-Sized Design
  . A very brief article covering the ordering problems you may find with queues

🗞️ Other articles people like

😎 My strategy to become a TOP 1% engineer

🔍 Track your growth as an engineer

🐲 How to prepare the system design interview

😲 How to write great feedback in 360 reviews (every year)