Watch this article as a short video on my YouTube channel.

Performance reviews are coming up. I've always found this period nerve-wracking, despite having gone through it so many times, both as an engineer, and later as an engineering manager. Will my manager give me fair feedback? Or will I be in for some unexpected surprises?

The best way to not have a surprise on your review is to prepare your own self-review, and send it to your manager, ahead of time.

Why is this a good idea? Managers will try to gather as much information as they can on your work, when writing your performance review: this is how I do performance reviews for engineers on my team. However, managers will not know about everything you do. They will also often fall victim of the recency bias: weighing recent work more than that in the past.

If you put in the work to write your own appraisal or self-review, you not only make your manager's job easier: you'll also set yourself up for a more fair review.

A possible structure for your self-review

If your company has an evaluation or self-review template, it's a good idea to use that one. For other cases, I've put a template and an example performance self-review together for inspiration. Here's the structure I'd suggest.

1. State the goals/expectations for the period

Instead of jumping in to your achievements, set the stage. In your interpretation, what expectations or goals did you set out to achieve? If your role has expectations defined, those might well be the expectations. If you had previously set goals with your manager, list those.

If you have neither of them, summarize your understanding of your expectation. It's already a problem if expectations are not clear: after the review, it might be worth having a follow-up with your manager to clarify what baseline expectations mean for you, and for them.

Here's this section in the example performance review - one of the goals was to be more involved in the engineering planning / RFC process:

2. List your accomplishments

List out your main results, and larger work efforts. Try to do this in priority order. Use numbers to make things more specifics, where you can - and where they add more context.

Numbers could be things related to the code the code (number of changes, number of languages worked with, number of services worked on and so on), to people (number of people collaborated with, number of teams, number of stakeholders), to business impact (revenue impact, reliability improvements, efficiency changes and others). The self-review is an opportunity to put your work in context: not just the effort, but the result of this work.

For work that has not yet been shipped, using the estimated impact should work just as well. For example, assuming you are playing a key role for an in-progress project, you could say “On track to save $500,000/year by shipping Project Pluto, where I am owning the Luna and Titan components end-to-end.”

Link to specifics where it makes sense, but don't go overboard. The specifics might be design documents, notable code changes or code reviews, or other artefacts. Linking these could give additional context to your manager, and an opportunity for them to spot check some of your most impactful work.

If you have a "work log document", add a link to it at the bottom - here's an example and template for this. It's a helpful practice to keep a document where you keep track of the work you do week-on-week. Julia Evans calls this a brag document:it has other benefits on having your work recognized, like you having a better grip on all the work you do. If you started doing this beforehand, it also makes creating your self-review much faster!

Here's an example of listing out accomplishments using the above principles in this example:

3. Talk about the "how"

Most people would stop by listing their accomplishments. I suggest adding another section where you can list more of the qualitative details on your work: things that might have not had huge business impact, but show the small, but important things. Things like teamwork, collaboration and helping others.

List examples of you helping people within and outside the team. This is a great place to mention thank yous you've gotten from people - even quoting chat messages or emails you've received. Mention names of people and teams who you have helped, or whom you've gotten positive feedback from.

This section is important, as your manager probably doesn't see even half of the positive interactions you've had with people. Show it to them. From  the example review:

4. Reflect on levels and competencies

Your manager will need to give you some kind of rating against expectations and competencies. Get ahead of this, and make their job easier, while giving indication of what you think about your own rating.

List expectations and competencies, and give examples on the work that reflects these competencies.

If you have good trust with your manager, you could provide self-ratings for competencies or expectations. If you have less of this, you could just mention areas you have paid special attention to: areas of focus. This is what is shown in this example:

Time well worth spending

Before every performance review period, I'd ask my directs to spend time on their self-review. Many people would leave it until last minute, prioritizing other work, including peer reviews ahead of this one. Some didn't even do a self-review.

Be sure to spend time on your self review, ahead of the performance review process kicking off. If you don't spend time here, you'll have little reason to complain if your manager is unaware of some of your key achievements, and your feedback is more negative than it would have been - had you put in the work. You are also missing an opportunity to reflect on all the things you've done.

Of all the "admin" work you do, this one will have an outsized impact on your career. So put in the work.

I'm writing a book: The Software Engineer's Guidebook on growing as a software engineer: from a junior, through senior to staff and principal levels at tech companies and startups. Subscribe here to get notified when it's out.

Enjoyed this article? Subscribe to my newsletter or read some other popular articles I wrote.