It’s this time of the year again! Maybe it’s called “review”, maybe it’s called “check-in”: the moment in the year where you and your manager sit down together to look at the past period, review the work you’ve done, and discuss directions for the future.
In this article, we’ll see how to optimize this process, especially the “self-assessment” part of the review.
Why you should optimize
Not everyone has done a review before: maybe you’re a new grad, or you’ve switched to tech from a different career.
Maybe, like me, you come from a different culture with little insight as to what is expected at a US corp like CRL.
We also know that there are qualitative differences in the way men and women talk about their achievements, and this can influence the opinion of managers.
Or maybe you are part of an under-represented minority with internalized discrimination, with the risk that your work is less visible.
How can you make your achievements more visible? How can you effectively help your manager assess your performance? How to optimize your evaluation towards a promotion?
How can you do this as effectively as your more senior peers, who have either more experience or more privilege?
The most important aspect to keep in mind is that the review is a collaborative effort, between you and your manager.
It is tempting to just “wait and see” what the manager has to say. After all, the manager has decided/validated the past work already before, so they surely know what you did and how well you did? NOT! A manager might be very busy and not be able to give full attention to your review. Or they may not be aware of certain things that you worked on “on the side”. They may also make genuine mistakes. Generally, your manager wants to help you, but they don’t know everything.
Your first role during the review to help your manager by seeding the review with your own perspective and being assertive about your own achievements.
Here are some possible risks of not driving the review yourself:
Manager is not aware of some of your work. It will not be considered during the review.
(Your work will be ignored and you will miss out on some possible rewards.)
Manager is aware of certain work activities but does not fully understand the impact of your work.
(Your work will not be properly valued and you will miss out on some possible rewards.)
Manager only sees a cloud of small work projects and does not see that you have an overall plan/strategy.
(Your work will not be properly valued, you will miss out on some possible rewards, and your manager will be unable to help you optimize your overall strategy.)
Manager is missing a connection between your work and the rest of your team’s projects.
(Your work will be considered “secondary”, and you will not be rewarded for contributing to the team’s roadmap.)
Break the mold!
Source: Julia Evans, Help, I have a manager!
Your review form might suggest to put only “3 to 5 sentences” in the box about your achievements.
This is a lie!
As a good manager once told me:
It doesn’t seem like a hard limit, more of a guideline, and most people went over it as far as I saw. I’m guessing the guideline is to encourage people to think of and summarize their most significant accomplishments. I’ve also seen people linking to other documents which provide more detail.
How to optimize the self-assessment part of your performance review
In a nutshell:
In advance (preferably, throughout the review period): write a brag document. This contains all the things that you would like to see considered for your evaluation.
If you don’t have one yet, don’t panic! See the section below.
Prepare a summary of your brag document.
Try to organize the summary into max 3-5 broad categories. But feel free to include hyperlinks from the summary to parts of your brag document that contains more details, to explain what you mean.
Get input from your more senior peers!
Your coworkers, especially those more senior than you are, can talk about your achievements in a different way than you, or perhaps they will perceive value in your work that you don’t. You can use this input to enhance your brag document.
Cross-check your brag document with the career ladder at your level.
Your org should have a career ladder for your role. If not, search for public career ladders online at similar organizations.
Order your brag document summary so that the achievements (or categories) that fit squarely in the responsibilities defined by the career ladder appear first.
Think a bit about what you’d like your next work period to look like.
Then try to explain to your manager how your current achievements put you in a good place to get started on the new period. Remember that new responsibilities are assigned in reaction to your actions and requests, not as a reward. For example:
You want to deepen your technical expertise.
Then explain how you tackled a technical project thoroughly in the “achievements” section.
Then argue you want to do this more, and request support from more senior engineers to teach you in the “next steps” section.
You want to broaden your technical expertise.
Then explain how you learned something new and applied it in a project in the “achievements” section.
Then request to be assigned projects that need new technical skills or knowledge in the “next steps” section.
You want to increase your leadership skills.
Then explain how you influenced a project with your ideas/visions or how you helped coordinate a project in the “achievements” section.
Then request involvement in projects where you can become better in this role in the “next steps” section.
Consider trading notes with your coworkers, especially folk who have a position similar to yours. You may be able to mutually enhance your self-assessments.
How to make a brag document
The “brag document” (terminology from Julia Evans) is a list of things you did that have value for your employer.
Ideally, the best way to build a brag document is as follows:
week over week throughout the entire work period, you maintain a “work log” of your tasks and achievements.
In addition to writing down “what” you do, also try to write about: “who does this help?” and “why is this important?” (The latter can sometimes be hard to answer, in which case you can try “what bad things would happen if I did not do this?”)
Remember, it’s not just your customers/users that your work may help. You could be helping your teammates, a coworker in a different department, future hires, etc. All these can be grateful for your work.
Also, don’t focus just on the technical work! Things like culture, taking meeting minutes, moderating discussions etc all are part of “work” and deserve to be rewarded.
month over month (or quarter to quarter), you “roll up” your work log into summaries of overall “projects” that matter to you and your employer. In these periodic roll-ups, you can add information about:
Who did you work with?
What are things they couldn’t do without you? What are things you couldn’t do without them?
Are there things you did that ended up not being valuable/useful in the end?
In that case, be very careful to explain (to yourself first, then to your manager) that the work was still valuable, if only to help build experience and provide input for the decisions that came afterwards.
at least a week or two before the periodic performance review, restructure your brag document so it is easier to consume.
You can choose to collaborate on this with your manager during the entire work period and discuss it periodically during your one-on-one meetings, but this is not strictly required.
Help! It is time for my review and I don’t have a brag document yet!
Maybe you’ve just received an e-mail to “complete your self-reflection” and you don’t know how to fill it in. You don’t have a brag document yet, either because you didn’t know it was important, or you’ve procrastinated.
How to ensure you are not left behind, and can still shine in your manager’s eyes?
Don’t panic!
The following strategy might help. Note that it will take you a couple of hours to do this, so don’t wait until the last minute! But the effort will pay off handsomely.
Note
Don’t take the prompts below as a suggestion that “You need to show something in every of these categories”. Some folk are very successful by focusing on just one topic and doing that well.
The prompts below are there more as a reminder to reflect and make yourself (and then your manager) realize that your work has value in more dimensions than just “the core engineering work” i.e. programming.
Collect and structure your implementation work. This will also take care of ensuring your manager is not missing anything important.
- Extract and sort the list of your code PRs over the period. Group them by project, sort them by impact (who did it help, what did it enable, what bad thing would have happened if you didn’t do it)
- If you have them, review your own text notes. Try and identify the areas where you had the most struggle and identify what you did to overcome them.
Collect and structure marks of your influence:
- What are the Slack conversations, or other conversations that you
were part of, where something important happened? “Important”
includes but is not limited to:
- A problem got a solution.
- A decision was taken.
- A coworker learned something they didn’t know before.
- Someone became aware of something they were missing before.
- Ditto with e-mail conversations, if you were involved in any.
- Ditto with RFC and design reviews.
- Ditto with discussions around brainstorms.
- Ditto with discussions around documentation pages.
- Also, collect a list of documents you’ve written (or similar artifacts) which have been used by other people. Try to explain: Who needed this? Why was it important? What bad things would have happened if you didn’t write these docs?
- What are the Slack conversations, or other conversations that you
were part of, where something important happened? “Important”
includes but is not limited to:
Did you make any non-technical contributions?
Think about blog posts, culture (events you’ve organized or participated in), coordinated/moderated discussions or meetings, etc.
What did you bring to the table? What did you learn? How did it help?
All these are potentially valuable and can be talked about.
Collect and structure previous recognition for your work.
Extract your list of mentions from your team’s milestone/sprint docs and any other teams’ docs where you might have been mentioned too.
Group these mentions by project, sort them by impact.
Ditto with e-mails sent to the group mailing lists.
Did you mentor anyone? Did you help anyone else in the company feel better or perform better in their work? Write about that too.
Ask input from your peers.
Approach your co-workers and ask them: “I’m currently doing a self-assessment and I’d like your help: from your perspective, what are the most notable things you know I did last period?”
You can ask fellow engineers, but also your product manager, other folk in the organization you talked to before, or your mentors/mentee if you have them.
Ask your coworkers “why?” and write down the answers (i.e “why do you think this was important?”)
With all this content, you can then prepare a “brag document” organized as follows:
- Top level sections correspond to overall areas of responsibility (technical contributions, leadership, etc)
- 2nd level corresponds to projects or topics.
- 3rd level (paragraphs) corresponds to important tasks under the project/topic, sorted in decreasing order of impact.
Then you can make a summary of the brag document: select 3-5 overall points that you find most important.
Of course, doing this collection at the last minute carries some risk: that you will forget something important! This is why it is beneficial to work on your brag document continuously.
How to choose which points are the most important in the summary?
Think about your own feelings about the work that you were involved in:
- It was impactful and you liked it: mention this work first in your summary.
- It was impactful, but you didn’t like it: mention this second.
- You liked it, and you’re not sure about impact: mention this third.
- You didn’t like it and you’re not sure about impact: don’t mention it in the summary.
In any case, you can (and should!) include a link to your brag document at the end of the summary.
Advanced topic: jockeying towards a role change
You should read “Negotiating your next job” from the Harvard Business Review:
Career negotiations fall into three buckets. In asking negotiations, you propose something that’s standard for someone in your role or at your level. In bending negotiations, you request a personal exception or an unusual arrangement that runs counter to typical organizational practice or norms (for example, a remote work setup or a promotion to a position for which you lack the conventional qualifications). And in shaping negotiations, you propose ways to play a role in changing your organizational environment or creating a new initiative (such as revamping the way a project is run or launching a new business unit). Depending on whether you are in an asking, a bending, or a shaping negotiation, you will need to vary your arguments to win your counterparts’ support.
Also for tech career progression, this article from this site:
You have developed new behaviors, skills, and supported your team with certain responsibilities. Now what?
Usually, the organization will notice: your manager or a co-worker will refer/defer to you increasingly in that role, and the management team eventually acknowledges the change and approach you to re-label your job with your approval.
However, this may not happen on its own! […] Instead, take action: approach your manager and your co-workers and be explicit:
“as you may have noticed, I have been doing more of this and that lately. I’d like to be recognized in that role.”
References
- Julia Evans, Get your Work Recognized.
- Julia Evans, Help, I have a manager! (paid zine).
- Gergely Orosz, Writing a Performance Self-Review.
- Hannah Riley Bowles and Bobbi Thomason, Negotiating your next job, Harvard Business Review.
- Marcus Buckingham, Annual Reviews are a Terrible Way to Evaluate Employees, Wall Street Journal.
- Zach Lloyd, The Google Incentive Mismatch: Problems with Promotion-Oriented Cultures.
- This site, Tech Career Progression for Beginners.
- This site, Levels of Technical Leadership.