Writing a Self Review
This process methodically makes a self review with context for a calibration committee.
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.
Turn into accomplishments with context
Then I put events into buckets and group similar data together into crisp accomplishment bullet points (usually 1-2 sentences each). Use the dimensions of the job ladder as high level buckets but group data into individual bullets based on what the impact was. (If there is no job ladder, use the high level categores “did well” and “room to grow”)
When done, each accomplishment bullet point should likely have several things: - A clear statement of impact that passes the “CFO test” and is ideally backed by a hard numbers: someone who cares about the business but doesn’t do your job should understand that you had an impact - (optional) a statement about what my particular role was / what was particularly challenging about the project. A bunch of useful Proxy measures for the “complexity” of a project:
- Number of teams / people involved, e.g. “project involved coordination of 8 people”
- Number of orgs/execs involved, e.g. “project spanned 3 organizations”
- Number of lines affected, e.g. “1000 LOC” or “42 changes” or “27 page document”
- Number of requirements, e.g X features AND maintain existing performance AND ship quickly
- Number of options prototyped
- Number of supported configurations
- Number of required steps/process/compliance hurdles, e.g. “it required creating a traffic proxy, dark traffic, …”
- Amount of learning involved, e.g. “nobody on team knew iOS app development before”- 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 “in this comment on this design doc, Jojo demonstrated XYZ and convinced XYZ”)
- 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.
Add a narrative
Once I’ve done this categorization, we usually see some pretty obvious high level patterns and takeaways. Boil the whole thing down into 1-4 clear, crisp sentences per ladder section. 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.
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]