It’s performance review season! I recently wrote mine, and I had to refresh myself on “how to do it right,” especially since you need to adapt to the process at your company.
Today, I’ll share common mistakes I’ve made and have seen, along with a template to make writing your review easier.
If you already submitted your review, I’m sorry for not sending this earlier 😬 . Still, these are good lessons regardless and you can apply them for the next review if it’s too late for this one. Let’s dive in!
Caveat: I’m an engineer in Big Tech. Performance reviews are different in every company, but my hope is these tips will be helpful to read about even if not 100% applicable.
1) Don’t start with a blank page
Instead of opening your performance review and writing from scratch, make a separate “Work Summary” doc. I learned this from my mentor recently, and it was so valuable when writing my actual review.
The doc should include all the key highlights in an organized, factual, and concise manner. After you make this doc, write your review.
This has 3 benefits:
You’ll learn which narrative makes the most sense for your performance review and how to write it effectively.
You can quickly write the “Work Summary” doc, then share that with your peer reviewers to help them remember what you did and what they can talk about.
You can link to this doc as a “Full explanation of all your work” at the end of your actual performance review.
My Work Summary Doc was only 1-2 pages and heavily bullet-pointed. My structure was this:
Each “Area” was an area I made a significant impact and each “Project” was a specific project in that area. You can structure it however you’d like, but this was what was most helpful for me. The high-level idea is to give an overview of everything you did.
You might wonder, at this point, why not just submit this as your performance review? The key differences are the context required, narrative, and content.
Context required: Your performance review might be reviewed by senior leaders who have no idea what you worked on. When you write your performance review, you need to weave together more context and assume less knowledge. The Work Summary is for you and your peer reviewers who know your work.
Narrative: Similarly, in your review, you need a succinct “narrative” in paragraph format of what you did throughout the year. This doc is meant only to document your key accomplishments exhaustively.
Content: The performance review should be shorter than this doc. It shouldn’t include everything. It should be an even more filtered-down version of the impact. If you overwhelm the reader with statements in the real review, it might be unclear what the actual key pieces of impact you shipped. That’s why it’s helpful to link to this doc as an exhaustive list at the end of your review.
Here’s how the information flows based on size and content:
I write what I did each week, but this is way too much information, so it first gets summarized into the Work Summary, then that gets summarized into the final performance review.
2) Avoid assuming context
On how much context to include, write your review as if it’s an executive report or resume to your CTO. The CTO has little time for understanding low-level details, all the various acronyms specific to your team, and translating what you did to what the impact was on the business.
While it’s unlikely the CTO will be reading your review, this is helpful for understanding how to frame your bullets and the amount of context you provide because it will be similar to the senior leaders like Directors and VPs who actually will read your review.
The two mistakes here I see the most are the overuse of unexplained acronyms and jumping into specifics without framing the project’s impact.
For example:
❌ Upgraded all our GBB permissions as part of the HLP project
Even if this was an amazing accomplishment, anyone without context will have no idea what was done or the impact.
✅ Enabled onboarding of Asana by upgrading our permissions as part of the High-level Permissions (HLP) project. The permissions were out of date for 3 years and it was technically challenging because we coordinated across 5 teams to safely roll out the upgrade.
In the updated version, even if you’ve never heard of HLP, it doesn’t matter because you can see the impact of onboarding Asana, the challenge of coordinating across multiple teams, and the goal of safely rolling out.
There’s not necessarily a formula here but one trick you can do is have a mentor on another team review your doc before you submit it. Ask them for each bullet, “Is there anything that makes barely any sense to you that I need to explain more?”
Similarly, you can ask yourself on review if you have unexplained acronyms or didn’t frame the project impact before jumping into the specifics.
3) Avoid weasel words. Use clear deltas
Weasel words don’t explicitly quantify what you’re trying to explain.
For example,
❌ “Impact: Significantly reduced home page load time.”
Avoid phrases like these without numbers:
“Increased significantly”
“Reduced <something>”
“Made <x> easier”
Often, this gets tricky when you do a refactor that impacts developer productivity because it’s hard to measure or get actual metrics for how much it improves things.
For example, it’s easy to get into the trap of writing something like this:
❌ “Impact: Made debugging significantly easier by converting poor logging usages to use our new helpers.”
Below are four approaches that make situations like this easier. We’ll gradually improve the statement above one step at a time.
👍 1) Quantify the change itself. “Impact: Made debugging significantly easier by converting over 70% of the usages to our new model.”
Instead of quantifying the impact, you can quantify the change itself so it’s easier to visualize. “Debugging helpers” is hard to visualize. It could be 2 helpers, it could be 20. Even if it is 20, it’s not clear how good that is. Instead, using percentages communicates the magnitude.
👍 2) Use the strongest word possible. “Impact: Made debugging significantly easier by converting over 70% of the poor logging usages to our new infrastructure.”
In this example, we used the word “infrastructure” to get out of the weeds of functions, helpers, and models. It’s something everyone knows as a foundation for everything else. Infrastructure is still accurate and uses a stronger word to communicate the change.
✅ 3) Include testimonials. “Impact: Made debugging significantly easier by converting over 70% of the usages to our new infrastructure.
From our Tech Lead: “This change solved a huge problem we had with debugging why customers were receiving invalid responses. It was technically challenging and <your name> found an innovative solution which led to us delivering on time.”
For Developer Experience/Productivity changes, you can inline testimonials below it to communicate impact. Above, you can see the sample snippet from a tech lead. These can lend credibility where it’s hard to communicate the impact.
⭐ 4) Include how it associated with a team/company goal. “Impact: Made debugging significantly easier by converting over 70% of the usages to our new model. This exceeded our Q4 target by 2x, enabling us to work on <other high priority initiative> 3 months sooner than expected.”
Here, we added an additional sentence to connect it to the team goals. Without this, the statement results in a “so what?” question to senior leaders. Yes, it’s nice that debugging is easier, but they want to know how it connects to the business. If it was an OKR target, then say so! This tells them that you’re someone whose work is directly aligned with the business.
Final pro-tip: For any impact you quantify, add hypertext links that link to a graph or a launch doc that also calls out the impact. This adds credibility to your statements and a paper trail to the full work while keeping your performance review succinct.
Check the full article on “Using clear deltas” here. It was in the top 5 all-time High Growth Engineer articles.
👋 Over to you
Before parting, I’m curious if you’d find a tool for writing your performance review valuable as part of WriteEdge. Respond to the poll and let me know! Also, if you’re interested in an early access invite, respond to this email and I’ll send you an invite.
That’s not all… below, subscribers can view a full performance review example and 30+ strong verbs to use in your performance review, plus the ones to avoid.
Become a subscriber to see!