Around this time every year, companies start doing their annual reviews. Coincidentally, software engineers start wondering what their peers and managers will be saying about them. Throughout my career I’ve always watched as colleagues worried about the results of their annual review. Will they get that promotion? Will they get that raise? Or will they be told that they are not performing up to expectations? All of this happens, like clockwork, once a year.

Annual reviews are a reminder that your reputation matters. For most of the year, software engineers don’t care at all what anybody else thinks as long as they’re getting the job done. Then annual reviews come along and we realize we might have rubbed some people the wrong way. I know software engineers who year over year always feel like their review is incorrect and unfair (though I’m sure other occupations have similar issues). What makes it more difficult for software engineers is that we deal so much with code that we sometimes forget how important it is to deal with people. The code isn’t going to give us a negative review so long as it works. Then again, you’re expected to write code that works, so your review only ever reflects when you don’t write code that works.

The rest of the review is based on what people say about you. They are your colleagues and your managers. And you probably didn’t even stop to think about that until around review time. If you’ve ever received a review that has been a complete shock to you, that means you didn’t spend enough time during the year to figure out what kind of the software engineer you want to be known as.

Never be surprised again

It’s been a long time since I had an annual review that surprised me. My last manager even came to expect it from me, as he would usually begin our conversations by saying, “I’m pretty sure you know what this is going to say.” He was right. It was very easy for me to predict what would show up on my annual review for one simple reason: I had already decided what I wanted to show up on the annual review the year before.

This is probably different than the way you’ve ever thought about annual reviews. Most of the time, you meet with your manager and set goals for the next year, and then your annual review is a checkpoint to see if you achieve those goals. Unfortunately, the goals are typically task oriented such as, “learn about Node.js”. It’s relatively easy to see if you’ve achieve those goals. What most people never stop and think about is what you would like to see on your annual review next year.

Stop and think about that. Decide right now what it is that you want your annual review to say next year and then take the steps necessary to make that happen. Keep in mind that your annual review typically reflects your reputation in addition to your technical work. The technical work takes care of itself but the reputation piece is one that you must actively work on.

Your reputation

Do you have any idea what your reputation at work is right now? If not, ask some colleagues that you trust to tell you how they view you as a coworker. Listen closely for adjectives because that’s what makes up your reputation. Then decide, is that a reputation that you want? Or is there one that would serve you better? What kind of a software engineer do you want to be known as?

Do you want to be known as the one who always shows up late and in a bad mood? Do you want to be known as the one who happily takes on complex problems? Do you want to be known as the one who smells badly? All of these things are within your control. You can create the reputation that you want for yourself, it just takes a little bit of planning. Everyone has a professional reputation but not everyone takes the steps to actively evolve that reputation. And believe it or not, as you get more experienced, your reputation starts to matter even more than your actual work.

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren’t improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

An example

The last time I stopped and thought about the kind of software engineer I wanted to be known as, I came up with a list of things that I wanted people to say about me on my annual review. These things reflected not necessarily what I was already doing, but what I would aspire to do in the next year. The things I wanted people to say about me on my annual review were:

• Nicholas is fun to work with.
• Nicholas cares about the career development of his peers.
• I trust Nicholas to work on important projects.
• If Nicholas is working on something, I know that it will get done correctly.
• Nicholas is capable of learning new things quickly.

This is just a sampling of some of the things I wanted to see on my annual review at different points in time. Note that they all have to do with how others perceive me rather than the quality of the code that I wrote.

Next steps

Once you decide what you’d like to see on your annual review, the next step is to figure out how to make that happen. This is a little bit more difficult than other task-oriented goals because it relies on the opinions of other people. That being said, it’s certainly not impossible. You just need to stop and think about how your actions affect how other people see you.

Take the example of being fun to work with. Why would people say that about you? Well first and foremost, you have to be reliable. That means showing up on time, completing tasks that are assigned to you, and being a good team member. It’s not fun to work with someone who is unreliable. Assuming that you are reliable, then “fun” is achieved by having good relationships with those on your team. That means talking about things other than work, getting to know people outside of the code they write in the job that they do. It could also mean that you’re the one who starts Nerf gun wars or helps to plan team activities. The bottom line is that people enjoy working directly with you and would welcome the chance to do it again in the future.

You can take all of your reputation goals and break them down in that way. Almost all of them are reflections on how you interact with other people. As you go through the year, keep an eye out for interactions that run counter to your goals or strengthen them. For example, if you got into an argument with a colleague, how did that argument resolve? Did you both end up feeling resentful and not wanting to work with the other person? Or were you able to reach an understanding that was mutually beneficial? Any time and interaction doesn’t quite go smoothly, that’s a good time to review your reputation goals and see how that interaction affects them.

Conclusion

Your reputation as a software engineer matters. It’s something that you should actively seek to develop throughout your career because that’s what sets you apart from everyone else who can write the same code that you do. As you get more experienced, your reputation matters more and more, and can be the reason that you either get or miss out on new opportunities. As software engineers, we spend so much time thinking about code that we often neglect personal relationships with our colleagues. Yet our colleagues are the ones who contribute to our annual reviews and ultimately to our success. Watch your interactions with others, try to establish personal relationships with people, and frequently review your reputation goals to see if you’re on track. Hopefully at this time next year, your annual review won’t be such a big surprise.