It's that time of the year. Managers started the preparations and scheduled events on calendars. Today, I will share some tips for better and strong preparation for your annual review. I had many reviews, some good and some bad, as a software engineer. Now that I'm a manager, I experience both sides and clearly see how things work behind closed doors.
You may think that you don't need any preparation because your manager will do their job perfectly. Once, I had a manager who took care of everything and just told me the raise I got in the end. He missed so many points, and the whole situation was inhumane. We didn't have a conversation; he had a monologue. Even if you have a similar manager like mine, and you know that preparation won't impact the result, you still have to prepare. You deserve this for yourself. Think of it as a reflection of the entire year.
It is easier to prepare if you're taking notes during the year about what you've done and achieved. If not, set an hour aside and scroll back Jira tickets, Slack messages, calendar invitations, or any other tool that you use. While doing that, open a new document and start writing them down. Before starting this whole preparation, get Julia Evans' Brag Document. This document is what I use myself and recommend to my team members.
Julia structured the document in a way that forces you to think at different levels about your work. You group your work under Projects, Collaboration & Mentorship, Design & Documentation, What you learned, and Outside of Work. I won't go into details that Julia already covered. But I will share a few tweaks and highlights. Even if you don't use the Brag Document, these tips will be highly beneficial in your own style.
Measure Business Impact
If you can identify the business impact of your specific work, add it to your document. Many people say they improved Continues Integration(Cl)/Continuous Deployment(CD) pipelines and reduced the deployment time from 40 minutes to 20. While it's a good measurement, you can showcase it even better. If you want to impress, measure business impact.
Let's imagine your project/company makes $10 per minute, and you had a system failure that took the whole system down. Once you found the problem, you pushed the code. If Cl had run in 40 minutes, your company could have lost $400 in revenue. Thanks to your improvement, it was $200. On top of the saved hours from developers and release times, $200 is an additional and literal business impact.
Why is this important? Because the result of your compensation discussion may need approval from higher-level managers and Human Resources, and they always ask one question: Why? Adding a $ presentation to your document makes your case strong to get better compensation and easier approval (more about the compensation below).
Add the user impact
Besides business impact, think about how you impacted your users. Did the work you have done change users' lives? Not all of us work on projects that reach millions of users. However, whatever we do, we impact some people's lives.
The user definitions are different depending on the team (e.g., product teams vs. platform teams) you work on. Find out how and how much you impacted your users. Did you improve performance by X%, and that improvement sole saved Y seconds every day in each user's life? If you have 10k users, Y second becomes Yx10kY seconds (probably some hours per day).
Attach the feedback
If your manager doesn't ask your peers for feedback, talk with your manager and ask them to collect feedback. If they won't, collect peer feedback yourself. Try asking three simple questions to your peers:
- What should I continue doing?
- What should I start doing?
- What should I stop doing?
Add "Why?" to each of these questions if you'd like to.
Additionally, add screenshots of the praise you got in public or private channels. If you think these praises are obvious, still add them. Your manager can neither see nor capture all of them.
Share the document with your manager in advance
Send the document to your manager at least a week or two before the meeting and ask for feedback. Your manager needs time to read and digest it. Let them know that you're open to any questions about the document.
The next thing you should do is prepare for the expected compensation change. I know that many people don't negotiate it at all, especially people from underrepresented groups. But you're giving service, and it hopefully has a lot of return to the company. On top of that, the market for software engineers is so high right now; companies and managers are doing whatever they can to keep people in.
Money might not be your primary motivator. However, money is what you get in return for labor, and if your value is higher than before, you should get more.
Be mindful of negotiation. It doesn't always have to be about salary increase; approach holistically. If you can't get the salary you wish for, what would you prefer instead? More vacation days (paid time-off)? Less working hours? One-time bonus? Extra training allowance? Stock options? Equity? Make a plan with possible scenarios, and make another backup plan if some scenarios don't work. Whatever you do, don't go to the review meeting without thinking about it.
Don't let your manager decide anything alone. The annual review is not a monologue. It's about you, your impact, the company's options, and the market. The meeting should be a bidirectional communication. Better communication requires both parties to know what you have done, what both sides want, and what everyone needs.
Thanks a lot!
Two Topics From Me
I've recently finished the book Worth Doing Wrong by Arnie S. Malham. I found out about this book when I was searching for books related to changing the culture at work. After keeping it on my wish list on Amazon, my manager bought it as a job anniversary gift.
In our conversation on the season finale episode, Jesper talks about the differences between Machine Learning and Data Science, how to enter the field, how and why life scientists shift their focus to Data Science.
We talk about how businesses should approach data as the processes and methodologies are completely different from software engineering.
One Topic from Others
Gergely is one of the people I have been following for a long time. Based on his experience in Uber, Skype, Skyscanner, and more, he wrote pieces of advice for software engineers to get the most out of the current heated market. Read it to learn more about how you can turn this opportunity to your advantage, whether you stay in your job or leave.
One Question for You
Think about this question to reflect and learn more about your skills.
Why is the team stronger because you’re part of it? (Credit)
If you enjoyed this letter, consider forwarding it to one of your friends or colleagues!