When the Numbers Belong to Another Team

A large amount of engineering work is measured by someone else, somewhere you can’t see. You shipped the feature; the product team owns the conversion dashboard. You cut the cluster’s footprint; finance sees the invoice. You fixed the checkout bug; support knows how many tickets stopped arriving.

The standard advice to quantify your impact quietly assumes you have access to the number. Often you don’t, and the result is a resume full of invented figures or no figures at all. There’s a third option, which is to cite the measurements you genuinely own.

The measurements engineers almost always have

Before reaching for a business metric you’d have to guess at, check whether one of these covers it. All of them are things you can see from inside the engineering org, which means all of them are defensible under questioning.

Latency, from your own dashboards. Percentiles at the endpoints you owned, before and after.
Throughput and volume. Requests, events, messages, rows processed. You know these because you sized the system for them.
Data scale. Table sizes, index sizes, partition counts, retention windows.
Error and failure rates, in absolute terms if you’d rather not compute a ratio: “the nightly job stopped failing” is a measurement.
Alert and page volume. Straight out of the paging tool, and among the most credible numbers on any infrastructure resume.
Build, test, and deploy times. Before and after, from CI.
Deploy frequency and lead time, if your team tracked them.
Counts of things you removed. Services, environments, cron jobs, lines, dependencies, database instances.
Adoption of something you built. Teams, services, or consumers using your library, template, or platform.
Team and system counts. How many services in your domain, how many teams depended on your API.

These are not consolation-prize numbers. For most technical readers they’re more informative than a revenue figure, because they describe the system rather than the business, and the reader is being asked to evaluate your engineering.

When the business number exists but isn’t yours

Sometimes the outcome genuinely was commercial and someone else measured it. Two honest constructions:

Attribute the measurement. Say who measured it and what they measured. “The product team’s dashboard showed the drop-off at the payment step falling after the retry change shipped” is a true sentence that doesn’t claim you own the number, and no interviewer will object to it. What they will object to is you presenting it as your metric and then not being able to explain the methodology.

Describe your side of the causal chain and stop. “Removed the timeout that was ending roughly one in fifty checkout attempts, which had been the top support complaint for the quarter” locates the impact without asserting a revenue figure. The reader completes the inference themselves, which is more persuasive than being told.

What to avoid is the reconstructed estimate: taking an average order value you half-remember, multiplying it by a failure rate you’re guessing at, and putting a currency figure on your resume. That number will be asked about, the arithmetic will surface, and the whole document takes the damage. The defensibility test in writing engineering bullets that say something is the right filter: could you explain the measurement in two sentences?

The qualitative bullet is not a downgrade

There is a persistent belief that a bullet without a number is weak. It isn’t; a bullet without specificity is weak, and numbers are only one way to be specific.

Vague: Improved the reliability of the data pipeline.

Specific, no number: Made the nightly pipeline restartable — it had been re-running from the beginning after any failure, so a late-evening error meant no data until the following afternoon. Checkpointing per stage meant a failure cost the failed stage only.

Nobody reading the second version wishes it had a percentage in it. The mechanism is legible, the previous pain is legible, and an interviewer can have a real conversation about it. That’s the whole purpose of the line.

Reconstructing a number you didn’t record

If you’re fairly sure a measurement existed and you no longer have it, there are safe and unsafe ways to handle that.

Safe: round hard and say you’re rounding. “Roughly a fifth of the traffic” and “somewhere around a hundred thousand rows a day” are honest signals about your own precision. Technical readers respect a stated approximation; it reads as someone who knows the difference between a measurement and a memory.

Safe: use the order of magnitude. Whether the queue held thousands or millions of messages changes what the reader imagines, and you’ll be right about which.

Unsafe: inventing the delta. The before-and-after pair is the thing you’re least likely to remember correctly and the thing most likely to be probed. If you can’t recall the baseline, don’t state the improvement.

Unsafe: borrowing the team’s aggregate. If your team halved incidents over a year and you fixed two of the alerts, the halving is not your bullet.

Where the trade-off actually is

The reason this matters more on engineering resumes than others is that the reader is qualified to check. A recruiter may not question a performance figure; the engineer doing your technical screen will ask what the workload was, what the baseline was measured on, and whether the improvement held under production traffic. Those are ordinary curiosity, not a trap — but they only go well if the number was real.

So the calculation is simple. A defensible qualitative bullet costs you nothing. An indefensible quantitative one costs you the interview and the credibility of every other line. The asymmetry is large enough that “no number” should be your default whenever the measurement isn’t in front of you.

The pass to make

Go through every figure on your resume and write, in the margin, where it came from: a dashboard you looked at, a bill you saw, a count you can reconstruct, or a memory.

Everything in the first three categories stays. Everything in the fourth gets converted into a description of the change — which, as the questions a technical reviewer is trying to answer suggests, is what the reader wanted from that line in the first place.