How to Quantify Your Work Experience (Even If You Don't Have Numbers)

Why 'improved performance' says nothing

"Improved system performance" is a claim without a size. It could describe a two-week rewrite that halved page load times, or a config change that shaved off nine milliseconds. The reader has no way to tell, so they assume the smaller version — because that is the safer assumption when screening dozens of applicants.

A number does two things at once. It sets the scale of the work, and it signals that you were paying attention to whether your work mattered. The second signal is often the more valuable one.

The four anchors

Every piece of engineering work can be measured along at least one of four dimensions. You rarely need more than one per bullet.

1. 1Scale — how many users, requests, records, or dollars flowed through the thing you built.
2. 2Change — what the state was before you touched it, and what it was afterwards.
3. 3Time — how much faster something ran, shipped, or recovered.
4. 4Scope — how many people, services, or systems you were responsible for.

Scale is the easiest to recover because it rarely changes and you usually still remember it. If you cannot recall what a system improved by, you can almost always recall roughly how big it was.

Recovering numbers you never wrote down

Most of the figures you need were never in a dashboard. They are reconstructable from memory with the right prompts:

1. 1Check your old pull requests, tickets, and commit history if you still have access — descriptions often contain the before-and-after context.
2. 2Recall the complaint that started the work. Someone was unhappy about something measurable: it was slow, it broke, it cost too much.
3. 3Recall what stopped happening afterwards. Fewer pages at night? Fewer support tickets? A meeting that got cancelled because the problem went away?
4. 4Ask a former colleague. A two-line message often recovers a number you both remember differently but can bracket together.

Applying it

Here is the same bullet at three levels of specificity, so you can see where the value comes from.

The second version does not claim more work. It claims the same work, described at a scale the reader can evaluate.

When you genuinely have nothing

Occasionally the work truly resists measurement — a research spike, a migration nobody benchmarked, an early-stage prototype. In those cases, describe the decision and its consequence instead. "Evaluated three message queue options and led the team to Kafka, which has since carried every event in the platform" has no percentage in it, but it establishes judgement and ownership. That is what the number was proxying for anyway.