Writing my own performance review honestly, for once

TL;DR#

For four years my self-review was a list of what I shipped. Features, migrations, incidents resolved, pull requests merged. It read well, it was accurate, and it produced the same feedback every year: strong delivery, would like to see more impact beyond your own work.

I read that as a request for more output, so I shipped more, and the feedback did not change.

The fifth year I wrote two lists: what I built, and what changed for other people because of me. The second list had four items, two of which I had not thought of as work. It was also the only list that mattered — and writing it changed what I chose to do the following year more than any feedback had.

The case this post is about#

My year-four self-review, abridged, and genuinely representative:

## What I delivered
- Led the KMP migration of the data and domain layers (14 weeks, on schedule)
- Shipped offline sync (queue, conflict resolution, retry) — 0 P1 incidents since
- Resolved 3 production incidents as on-call, median MTTR 22 min
- 184 pull requests merged, 311 reviewed
- Reduced the Android build from 4m10s to 1m50s

Everything true, with numbers. Every item is something I did.

The feedback:

"Consistently strong delivery. For the next level we'd want to see impact
 beyond your own output — raising the team, not just your own throughput."

The same sentence, more or less, as years two and three.

The symptom#

I read "more impact" as "more output" and acted on it:

            PRs merged   PRs reviewed   features shipped   feedback
year 2            141            206                  4   "more impact beyond your own work"
year 3            167            268                  5   "more impact beyond your own work"
year 4            184            311                  6   "more impact beyond your own work"

Thirty percent more output across three years and the same sentence each time. At some point the problem stops being the feedback's clarity.

And the thing I had actually been doing well was invisible in my own review. Three examples I had not written down:

- I had written the KMP migration playbook as a 6-page doc because I was
  explaining it to two people repeatedly. Three other teams then used it
  for their own migrations. I had never mentioned this.
- I had spent ~1 day/week for 4 months pairing with a junior engineer who
  was struggling with the build system. She now owns it. Not in the review.
- I had pushed for the ADR practice after a decision was re-litigated four
  times. 23 ADRs existed by year end. I listed this as "process work" in
  one bullet, under "other".

Three things with effects well beyond my own throughput, and I had recorded them as nothing, a nothing, and a footnote — because they did not look like engineering output.

Meanwhile the items I led with had limited reach:

"184 pull requests merged"
  → a measure of my own hands. True, and it says nothing about anyone else.
"reduced the build from 4m10s to 1m50s"
  → actually the highest-impact thing on the list: 2m20s × ~40 builds/day × 9 people
    ≈ 2.3 engineer-hours per day saved. I had buried it last and framed it
    as a personal achievement rather than a team one.

Why the obvious thing did not work#

"Ask for clearer feedback." I did, twice. I got useful examples — "mentor someone", "write things down for the team" — and acted on them, and then did not report having done so, because they still did not feel like the body of the work. The gap was in what I considered reviewable.

"Shipping more will demonstrate impact." Three years of testing this. Output and impact are correlated and not the same thing, and more of the first does not produce the second.

"It's a promotion-process problem, not mine." Partly fair, and it does not help. The committee reads what is in front of them, and what was in front of them was a list of my hands.

"Keep a brag document." I started one in year three. It was a list of the same kind of thing — shipped items — just more complete. A better record of the wrong category.

The actual mechanism#

Two different questions, and I was only answering one:

"What did I do?" — a list of my own actions. Easy to recall, easy to quantify, and bounded by one person's hours. This is a measure of throughput.

"What is different for other people because of me?" — a list of changes in others' capability, speed, or decisions. Harder to recall, because the work often does not feel like work, and the effect is visible in someone else's output rather than mine. This is a measure of leverage.

Three reasons the second list is hard to write:

The work does not look like work. Writing a doc because you are tired of explaining something is not an achievement in the moment; it is avoidance of a chore.

The two lists are separable by a mechanical test — whose output changed — which is what let me re-sort a year of notes rather than try to remember differently:

def classify(entry):
    """entry: one line from the year's notes. Returns (kind, restated)."""
    others = entry.people_affected - {entry.author}

    if not others:
        # Throughput. Real work, and bounded by one person's hours — which is the
        # ceiling the whole review was unknowingly reporting against.
        return "throughput", f"I {entry.verb} {entry.object}"

    # Leverage, and the restatement is the point: the sentence has to end in someone
    # ELSE's changed output, or it collapses back into a description of my own effort.
    if entry.measured_effect is None:
        return "leverage-unquantified", (
            f"{len(others)} people affected, no measured effect — "
            f"find the number or drop the claim")

    return "leverage", (
        f"{len(others)} people now {entry.measured_effect} "
        f"(because I {entry.verb} {entry.object})")

Run over the year's notes, the counts came out:

throughput                 31 entries
leverage                    4 entries
leverage-unquantified       9 entries

Thirty-one against four is the finding, and the nine in the middle are where the hour actually went. "Wrote the deploy runbook" sat in leverage-unquantified until I checked the chat history and found that deploy questions in #eng-help went from roughly six a week to under one — at which point it restates as "four engineers now deploy without asking, because I wrote the runbook", which is a different sentence about the same afternoon.

The leverage-unquantified branch exists because the alternative is worse in both directions: claiming the effect without the number is unfalsifiable, and dropping the entry loses the most valuable work in the file.

The effect is deferred and happens elsewhere. The junior engineer now owning the build system shows up in her review, not mine, and six months later.

And nothing prompts you to look. My pull requests are in a list I can query. "Three other teams used my playbook" is a fact I only learned because someone mentioned it in passing.

throughput:  bounded by my hours, visible immediately, easy to count
leverage:    multiplies other people's hours, visible later, has to be sought out

"What did I ship" measures throughput and is bounded by my hours. "What is different for other people" measures leverage and is not. The second list is harder to write and is the one the feedback was asking for.

The fix#

Two lists, with the second one written from evidence rather than memory.

1. The year-five review, restructured:

## What changed for other people

1. The KMP migration playbook (docs/kmp-migration.md)
   Written because I was explaining the same thing to two people. Used by
   3 other teams for their own migrations (Payments, Identity, Growth).
   Payments' lead estimated it saved them "about two weeks of false starts".
   → 3 teams, ~2 weeks each, from 6 pages written in a day.

2. Build time: 4m10s → 1m50s
   2m20s × ~40 builds/day × 9 engineers ≈ 2.3 engineer-hours/day saved,
   ~460 engineer-hours/year. Measured, not estimated — build-scan data attached.

3. Sarah now owns the build system
   ~1 day/week for 4 months pairing. She has since made two improvements I
   would not have thought of, and I am no longer the only person who can
   debug a Gradle configuration failure. (Previously: bus factor 1.)

4. The ADR practice
   Proposed after a decision was re-litigated 4 times (~11 engineer-hours).
   23 ADRs by year end. Decisions re-opened: 1 in 6 months, vs 8 in the
   previous 6. ~20 engineer-hours/period avoided.

## What I built
[the old list, now second and shorter]

2. The evidence-gathering, which is the part that made it writable:

## Quarterly, 30 minutes
- Search my own name in other people's docs and PRs. Who referenced something I wrote?
- Ask 3 people: "has anything I did this quarter made your work easier or harder?"
- Check: is there anything I used to be the only person able to do, that
  someone else can now do?
- Any doc I wrote because I was tired of explaining something? Who has used it?

The third question is the most useful one I have found. Bus factor going from 1 to 2 on something is a concrete, checkable, high-value change that never appears in a delivery list.

3. And the question I now ask before starting work:

"Is this a thing only I will benefit from doing, or will it change what
 someone else can do?"

Not to avoid the first kind — most work is the first kind and has to be. But asking it surfaced three opportunities in year five that I would previously have walked past, including the playbook, which cost a day and saved three teams two weeks each.

How this turned out#

The feedback:

year 4:  "strong delivery, would like to see more impact beyond your own work"
year 5:  "clear evidence of leverage — the migration playbook and the ADR
          practice are referenced by teams you don't work with. Promoted."

My output in year five was lower:

            PRs merged   PRs reviewed   features shipped
year 4            184            311                  6
year 5            142            289                  4

Forty-two fewer pull requests and two fewer features. The day spent on the playbook and the four months of one-day-a-week pairing came out of my own throughput, which is the trade — and it is a trade I had been avoiding for three years because the first list was the one I knew how to write.

And the second list changed what I chose to do, which matters more than the promotion:

year 5 decisions I made differently because of the framing
  - wrote the playbook instead of explaining it a third time        1 day → 3 teams
  - paired rather than fixing the build issues myself               bus factor 1 → 2
  - proposed the ADR practice rather than just writing my own ADRs  1 → 23 records
  - declined to own a second service, recommending Sarah instead    (she wanted it)

That last one is the clearest change: previously I would have taken it, because ownership looked like impact. Handing it to someone who wanted it was the higher-leverage choice and it reduced my visible footprint.

One honest limit, and it matters: this worked because my organisation's criteria genuinely reward leverage and because I had four years of solid delivery behind me. Writing a leverage-first review with weak delivery would have read as deflection — and in an organisation that rewards output, this reframing will not help and the honest answer is that the organisation is the thing to change or leave. I cannot claim the reframing is universal; I can claim that the two lists are genuinely different, and that I had never written the second one.

What this generalizes to#

Throughput is bounded by your hours; leverage is not. A day spent writing something three teams use is not comparable to a day spent shipping a feature, and the two are measured in the same unit only by accident. Knowing which you are doing is the whole distinction.

The highest-leverage work often does not feel like work. Writing a doc out of impatience, pairing instead of fixing, proposing a practice. None of it resembles delivery in the moment, which is exactly why it goes unrecorded.

Leverage is visible in other people's output, so you have to go and look. Your own contributions are queryable; the effects are not. Thirty minutes a quarter of asking people and searching for your name in their work is the entire data-collection method.

Ask "bus factor 1 → 2" explicitly. It is the most concrete leverage question available, it is checkable, and it never appears on a delivery list. If you are the only person who can do something, changing that is high-value work that looks like nothing.

Related#

• The handover that actually worked, and the four I botched first — transferring capability rather than information
• The architecture decision nobody wrote down, re-litigated four times — the ADR practice from this review
• The most valuable pull request that quarter deleted 4,000 lines — work that does not look like output

Keep reading#

This is part of 100 practices of senior engineers — the habits that separate five years of experience from one year five times. Follow MobileByteSensei for the rest.