Things I Learned at Google: Writing Your Perf

This is part four of a multi-part series on lessons I learned while working as a software engineer at Google. If you’d like to start at the beginning, check out part zero.

Like many companies, Google has a semi-annual performance review cycle. Also like many companies, this process begins with SWEs documenting their achievements over the last six months (or sometimes year).

I’ve gone through this process myself about sixteen times and reviewed many more of others’ writeups in both a formal and informal capacity. This is a collection of the advice I give most often when pre-reviewing the writeups of junior SWEs, generalized for a non-Google audience.

You need to try

The first thing to understand is that performance reviews are important. They are the mechanism by which your performance rating is determined which directly affects your compensation and future promotion. Every day you come to work, make decisions, and apply effort in service of certain objectives. Your performance review is the last step in a complex process that makes that daily work legible to your employer – even if you are doing a great job, this legibility is required for your employer to recognize your performance (and reward you for it).

Therefore, do not half-ass this process! Lots of SWEs seem to find it toilsome to write their own performance review. Unlike most programming work which has clear success and failure conditions (the code compiles or doesn’t, the tests pass or don’t) writing exists on a quality continuum.

When confronted with ambiguous success criteria and diminishing marginal returns in an unpleasant task (writing), many SWEs opt to do a quick, bad job in order to return to the activity they actually enjoy (programming)[0]. This is a terrible mistake for people who care at all about money, job security, or career progression.

Your objectives as a talented, motivated, effective software engineer should be to 1) do great work and 2) get appropriately recognized for it. This second step is the weak link for many people; they work hard and effectively for months and then do a mediocre job writing their performance review, effectively devaluing their own work. Performance review writing is a high-leverage activity: often, a few extra hours of focus is all it takes to turn a middling writeup into a great one. Therefore, persevere!

Now that the question of effort is squared away, let’s talk about some of the most common mistakes I see:

Mistake: lack of organization and focus

Organize your review with the most impactful work first, regardless of when it occurred. Within paragraphs or project sections, organize the details in the same way. Do not put your most important project third out of five because that’s the order it happened in; do not ‘conclude’ your paragraph with how your work saved the company a million dollars, put that first!

Concision and flow are critical – the experience your readers have consuming your review will affect how they feel about your work (this is the reality of a human process, even for well-intentioned people). Eliminate unnecessary words and flowery language to tighten up each sentence. Be diligent in preventing grammatical mistakes that interrupt the flow of reading.

Cut content ruthlessly in order to raise the impactfulness of the average sentence. Your review should read like a bang-bang-bang greatest hits of your work, without a down moment.

Your readers have a limited attention span and will subconsciously discount important work if it is surrounded by irrelevant or unimportant details. Often this means removing sentences from paragraphs that are dragging down the average impact of each sentence in the paragraph. Sometimes this means removing whole projects that are dragging down the review[1].

Mistake: not enough artifacts

Substantially every piece of work that you mention in your review should include a link to something that substantiates your representation of what happened. Artifacts can take many forms: they may be PRs, issues, documents, monitoring screenshots, etc.

Depending on your organization’s process, your performance review may be reviewed by people who have little familiarity with your work. They may naturally wonder, ‘is what I’m reading true?’ Make it easy for them to accept the (truthful!) narrative you are providing by supplying evidence for every claim you make.

In practice, this often means an average links-per-sentence slightly above one. If you have no artifact to link to for a sentence then that is a strong signal that it should be cut (see above).

Mistake: talking about other people

Focus exclusively on your own contributions unless someone else’s work is critical context for readers. Your performance review is not the time to share credit or highlight the job done by others; they will do that in their own reviews. Do not take credit for work you did not do but do not waste precious words (i.e. reader attention) on others’ accomplishments.

How to do better, easier

Writing an excellent performance review can be challenging, especially in the case of annual reviews. Often, the two most difficult tasks are identifying which projects should be included and retrieving the (typically) dozens of artifacts associated with the work. Unfortunately, these are also the most critical tasks: failure to complete them thoroughly will greatly limit the quality of the resulting review.

Fortunately there is a simple solution: do your performance review more frequently than required. Every quarter, write an abridged version of your performance review for only those thirteen weeks. Organize your projects by importance, spell out the impact of your recent work, and gather any relevant artifacts.

Then, when your real review comes around, 80% of your work is already done. Merge your last 2-4 self-reviews into a single document, merge any long-running projects into larger sections, and cut the least-important projects as necessary to fit any prescribed limits. Do a little wordsmithing, and you’re done!

Splitting this work across more sessions is not only psychologically easier, it also reduces the total work by organizing artifacts when they are readily accessible (some evidence, especially monitoring graphs, tends to become inaccessible over time).

Don’t let your manager do it

Do not leave the writing of your performance review to your manager. Your manager may offer to write it for you or they may ask you for ‘notes’ or a summary of your projects for them to refine. Regardless, your goal should be to supply them with as close to a finished product as possible.

There are a couple of simple reasons for this:

Your manager is balancing their time and energy across all of their reports. Whatever ability they have to improve your review, the end result will be better if they start from a better place. Give them your best effort to work with!

[0] Sometimes this is rationalized by the thought that ‘doing the work is my actual job, not writing performance reviews’. This is correct in spirit, but presumes an omniscience that all our employers lack.

[1] Most often I see this when someone includes a project whose work is ‘below’ their job level. There’s nothing wrong with doing projects like this, but for more senior SWEs they should manifest as minor details in sections that highlight your leadership or stewardship rather than on their own.