Writing a Self Review

Gather Raw Events and Links

First, I gather raw data forming a list of interesting events.

I systematically search (to avoid recency bias) for data over the time window, gathering the facts, story, and results with a link as relevant:

• I look at every email I sent
• I look at every slack I sent or was tagged in
• I look at every PR
• I look at every notion page I touched
• I look at every google doc I wrote or commented on (search: …)
• I look at every Jira/Linear/etc issue I created or commented on
• I look at my 1:1 notes with my manager
• Anything else the above reminds me of.

I usually follow links in documents and messages etc, including from collaborators. The goal with this phase is to remind myself of all the critical work I did so I don’t forget anything helpful. Often I’ll see some comment/message and it’ll remind me of a whole 2w project that I’d forgotten about.

Turn into accomplishments with context

I turn this list of projects into a list of accomplishments: the impact and my particular contribution.

I start by reading the job ladder, job description, or other statement of what the organization values from my role at my level to ground myself (e.g. what is impactful for an staff engineer role is different than what is impactful for new college grad).

I then go through every work stream referenced by the raw events and answer “how did this affect the organization/customers.” Often, the raw evidence was enough to remind me of a project, but it wasn’t enough to show the result. If I don’t have a measure or clear statement of impact, I spend some time searching for missing evidence and/or a proxy measure of impact. This “search for the impact for every (major) project” is the second systematic search and is the most critical part of this step.

Note that at this stage it is far better for me to overstate an accomplishment a bit than it is for me to omit an important accomplishment or undersell it (for my self review, I am my own advocate). I will not be unprofessional and outright fabricate evidence, but I’m always trying to interpret evidence as “what’s the strongest claim I can reasonably make.” If the evidence I have is too weak for an important contribution, I’ll try search for better evidence if I can (see proxy measures of impact in the CFO test post — I can find some proxy measure >95% of the time), give evidence of the challenge/difficulty/complexity instead, or give the accomplishment without evidence if I must (with no hard evidence of impact, normally I have to be a bit more conservative about how I interpret the evidence).

Then I put events into groups by impact and write crisp accomplishment bullet points (usually 1-2 sentences for each project). Group events by the effect on org or customers and rank them based on the impact (prefer indirect/proxy/weak evidence of genuine higher level impact to concrete/technical/strong evidence of lower level impact). When done, each accomplishment bullet point should likely have several things:

• A clear statement of impact passing the “CFO test”.
• A statement about what my particular role was and (optionally) what was particularly challenging about the role. Avoid the common trap of talking primarily about the complexity/challenge of a project especially when it is easier to measure than impact; it is far better to talk primarily about impact and secondarily mention or imply the complexity/challenge, only if it is relevant.
• A link to an artifact / slack message / etc where someone can learn more (and with the description of what the reader would see if they clicked on the link, like “Jojo demonstrated XYZ in this comment on this design doc and convinced XYZ”) even better: link to verb not the noun: e.g. “JoJo impressed her L6 TL with analysis of FooBar outage.”)
• A list of specific phrases from the job ladder supported by this bullet. Due to word count limits for self reviews, its usually best to format these as tags like [L6_proposes_fixes_and_lands_them] – a ladder level and then an exact quoted phrase from the ladder with the words joined by underscores.

Do not stop until every work stream has been turned into an accomplishment with its impact and my specific contribution, ordered by size of impact.

Add a narrative

As we start to prepare a final document, the most important high level narrative to convey is that “my impact demonstrated I performed at Level during the review period.”

We usually see some pretty obvious high level patterns and takeaways in the accomplishments. Boil the whole thing down into 1-4 clear, crisp sentences per review section/question (or if there are no recommended sections, use “strengths” and “opportunities” or headings that summarize the highest impact accomplishment).

For formatting the narrative text I prefer SEER and SumEx. I will also pick 2-3 of the raw events to embelish and provide as examples.

Note there is sometimes a shadow ladder of critical phrases that managers know are important for each level: like “go-to person” or “multi-team projects.” Make sure the narrative clearly evokes the relevant shadow phrases, but quote tags should only be from the official ladder.

Before I wrap, I ask someone unfamiliar with my work to read the doc without coaching and estimate what someone on the calibration committee would conclude from skimming it. Do they have a clear one sentence summary of my primary accomplishment, and does that convincingly demonstrates level appropriate impact? If they don’t, I revise the narrative until it is clear to someone unfamiliar with my work who just skims it.

Example section

In H1, Jojo demonstrated “top line service impact” when she stabilized the Foobar service, which transitioned from being a top reliability concern for users (weekly outages and monthly escalations to leadership) to a dependable service. Jojo:

• reduced time-to-recovery by ~5x by proposing and landing tools like FoobarAutoFailover [L6_proposes_fixes_and_lands_them]
• decreased outage rates by ~2-3x by encouraging the upstream Bazbat service to adopt postmortem processes via [L6_drives_impact_across_teams]
• reduced the impact of outages by ~2x through scaling Redis instances by building automation
• improved customer support via foobar_support_bundle, onboarding resources, etc. [L6_leaves_documentation_better_than_found_it]

Further reading:

• Manager Tools on Preparing Performance Review
• Manager Tools One Page Performance Review