How to Quantify Wins That Don't Have Obvious Numbers

You mentored three junior engineers this quarter. You refactored a gnarly authentication module that everyone was afraid to touch. You spent two weeks coordinating a cross-team migration that kept four different services from breaking each other. And now you're staring at your self-review trying to figure out how to describe any of it with numbers.

You don't have a dashboard for "prevented the team from making a terrible architecture decision." There's no metric for "became the person everyone Slacks when something is confusing." So you write something vague like "improved code quality" or "helped with onboarding," and it disappears into the pile of promotion packets that all sound the same.

This is where most engineers lose. Not because the work wasn't valuable, but because they couldn't put a number on it.

Why numberless wins are often your strongest evidence

Here's what's counterintuitive: the work that's hardest to quantify is frequently the work that demonstrates next-level thinking. Shipping a feature with a clear metric attached is table stakes. Identifying a systemic problem nobody asked you to fix, coordinating across teams, reducing toil that was silently eating hours from your teammates. That's what promotion committees actually look for when they're deciding between "doing the job well" and "operating at the next level."

The problem isn't that this work can't be measured. It's that the measurement isn't handed to you. A feature launch has a built-in metric: users, revenue, latency. But mentoring? Code health? Developer experience? You have to build the number yourself.

And here's the thing calibration committees won't tell you: an approximate number beats a vague adjective every single time. "Reduced onboarding time from three weeks to four days" is more compelling than "significantly improved the onboarding experience," even if the first number came from your rough estimate and the second sounds more modest.

Five ways to put numbers on qualitative work

1. Take a before/after snapshot

The simplest framework. What was true before you did the work? What was true after?

You don't need a monitoring dashboard to do this. You need memory, a timestamp, and sometimes a quick grep through CI logs or Slack history.

• "Before: deploys took 45 minutes and required manual steps. After: 8 minutes, fully automated."
• "Before: new engineers took about 3 weeks to submit their first PR. After the onboarding doc rewrite: 4 days on average."
• "Before: the on-call received 30+ alerts per week, most non-actionable. After tuning the alerting pipeline: 6 per week, all requiring real attention."

None of these required a formal experiment. They required paying attention to the starting state before you changed it. If you didn't capture the "before," ask your teammates. Someone remembers how bad it was.

2. Calculate time saved times people affected

This one turns invisible work into a number anyone can understand.

The formula: hours saved per occurrence, multiplied by how many people it affects, multiplied by how often it happens.

Say you automated a manual release checklist that used to take each engineer 30 minutes. Your team has 8 engineers and releases weekly. That's 30 minutes times 8 engineers times 52 weeks: roughly 200 engineer-hours per year. For a 5-minute script.

Other examples:

• "Created a shared test fixture library. Estimated 15 minutes saved per engineer per week across a team of 12. Over six months, that's around 780 engineer-hours."
• "Built a Slack bot that answers the top 10 recurring questions about our service. Before: I personally fielded about 5 of these per week, each taking 10-15 minutes. After: the bot handles them. That's 4+ hours a week I got back for project work."

The numbers don't need to be precise. Resume Worded puts it directly: approximate numbers are infinitely more persuasive than vague adjectives. "Saved the team roughly 200 hours per year" lands harder than "improved team efficiency."

3. Use frequency as a proxy metric

When the thing you improved doesn't have a dollar amount or a latency chart, count how often something happens. Or stops happening.

Sophie Alpert calls these proxy metrics: you can't always measure the thing you actually want to observe, so you measure something closely correlated that you can count.

• "Reduced flaky test failures from roughly 12 per week to 2 per week by isolating test database state." You find that number in CI logs, not a product dashboard.
• "Fielded 15 questions from other teams about the auth migration in Q3. Wrote a runbook that dropped recurring questions to 2 per quarter." The number came from searching your Slack DMs.
• "Averaged under 4 hours on code review turnaround for the team, down from about a day and a half. Tracked it manually for two sprints." You don't need a DORA metrics tool. A spreadsheet and two weeks of attention works fine.

Almost anything is countable if you decide to count it. Most engineers just never decide.

4. Add scope and scale markers

Sometimes the number isn't about what changed. It's about how big the thing was that you worked on.

Scale markers give a promotion packet reader context without requiring an impact metric:

• "Designed the caching layer serving 2 million daily requests"
• "Coordinated the data migration across 4 teams and 12 services"
• "Owned the on-call rotation for a service processing $3M in daily transactions"
• "Led the RFC process for a system change affecting 40+ engineers"

These aren't impact numbers. They're scope numbers. And scope is one of the primary dimensions promotion committees evaluate when distinguishing between levels. An L4 and an L5 at Google might ship the same number of features. The difference is the L5's work touched more surface area and carried more risk.

You already know the scale of what you work on. You just haven't written it down.

5. Frame the counterfactual

What would have happened if you hadn't done this work? The counterfactual makes invisible prevention visible.

• "Identified the memory leak in staging before it hit production. The affected service handles roughly $50K per hour in transactions. Even a 2-hour outage would have been a six-figure incident."
• "Pushed back on the proposed microservice split during design review. The alternative would have tripled our deployment surface area and required a new on-call rotation for a team already stretched thin."
• "Caught the breaking API change in code review before it shipped to 3 downstream consumers. Estimated rollback cost: half a day per team."

Counterfactual framing works because it answers the question every calibration committee secretly asks: "What would be different if this person weren't on the team?" Give them the answer explicitly.

The real reason engineers skip this

It's not laziness. It's a cognitive blind spot.

Psychologists call it the availability heuristic: we judge importance by what's easy to recall. Features you shipped are visible — they have launch emails, Jira tickets, celebratory Slack threads. The three weeks you spent untangling a dependency mess so the next team could ship cleanly? That lives in your memory as "a frustrating few weeks" rather than "I unblocked a quarter's worth of work for another team."

The wins that don't come with numbers also don't come with fanfare. So you forget them. And when self-review season arrives, you write about the shipped features (because you can remember them and they have metrics) and skip the work that actually demonstrated the most judgment, leadership, and scope.

This is why weekly documentation matters. Five minutes on a Friday, writing down what you did and one rough number attached to each item. After six months, you'll have 25-30 wins captured in the moment, including the ones you would have completely forgotten by review time — and the forgetting is faster than most engineers expect. The frameworks for quantifying engineering impact work best when you capture the baseline at the start of the work — not three months later when dashboards may not retain the history.

What "good enough" looks like

You're not writing an academic paper. You're writing a promotion case. The bar for numbers isn't statistical significance. It's "specific enough that the committee reader can picture the impact in 5 seconds." That's the same bar that applies when framing impact versus output in your promotion case. Committees aren't looking for precision. They're looking for specificity they can defend.

Instead of this	Write this
"Improved developer experience"	"Reduced local build time from 8 minutes to 90 seconds for a team of 14"
"Mentored junior engineers"	"Mentored 3 junior engineers; all 3 shipped their first independent project within 6 weeks of joining"
"Helped with the migration"	"Coordinated the database migration across 4 services, completing 2 weeks ahead of schedule with zero data loss"
"Improved code quality"	"Reduced P0 incidents from 4 per quarter to 1 after refactoring the alerting pipeline"
"Did a lot of code reviews"	"Reviewed 85% of the team's PRs with median turnaround under 4 hours; caught 3 breaking changes before they shipped"

Every row on the right side uses at least one number. None of those numbers required a formal tracking system. They required paying attention and being willing to estimate.

---

CareerClimb's AI coach Summit helps you capture wins in the moment, including the ones that don't come with obvious metrics, and reframes them with the kind of evidence that holds up in calibration. Download CareerClimb