"My impact is hard to quantify" is one of the most common things engineers say at review time — and almost always, it's not true.
The real problem is that engineers aren't taught to track impact incrementally. By review season, the numbers that would have been easy to capture six months ago are now buried in old dashboards, inaccessible Datadog graphs, or simply forgotten.
This guide covers how to find, frame, and present the metrics behind your engineering work — even when your company doesn't have a formal system for tracking them.
Why quantification matters for engineering reviews
Numbers do something that prose can't: they remove ambiguity. "Improved performance" is dismissible. "Reduced p99 API latency from 4.2s to 340ms" is not.
More importantly, numbers make it easier for your reviewer to advocate for you. When a manager writes a calibration justification for a promotion, they need specific evidence that stands up to scrutiny from other managers who don't know you or your work. Concrete numbers are far easier to defend than qualitative descriptions.
The four categories of engineering impact
Most engineering impact falls into one of four categories. For each, there are usually metrics available if you know where to look.
1. Performance and reliability
These are the easiest to quantify because the numbers are usually already being collected somewhere.
- Latency: p50, p95, p99 response times — before and after your change. Available in Datadog, New Relic, Grafana, or CloudWatch.
- Error rates: Request error rate or exception count. Sentry, Datadog, and most logging platforms track this historically.
- Uptime / availability: If you worked on an incident or reliability improvement, what did uptime look like before versus after?
- Throughput: Requests per second, jobs processed per minute — useful if you worked on a high-volume system.
2. Developer experience and productivity
These are harder to measure but still quantifiable.
- Build time: If you optimised CI, how long did builds take before? After? Minutes per run times runs per week times engineers is real time saved.
- Deploy frequency: Did you improve the deployment pipeline? Track how many deploys per week before and after.
- Time to first review: If you worked on review culture or tooling, PR turnaround time is often measurable via GitHub or GitLab analytics.
- Test coverage: A percentage point increase isn't inherently meaningful, but "added the first test suite for the billing module" or "increased coverage on the auth service from 12% to 68%" gives a concrete before/after.
3. Business outcomes
Engineers often think business impact is their PM's domain. It isn't — your code enabled whatever the business outcome was.
- Revenue unlocked: Did the feature you shipped unlock a pricing tier, enable enterprise deals, or remove a blocker for sales?
- User adoption: How many users or accounts used the feature you built in its first month?
- Conversion impact: Did a performance improvement, checkout refactor, or onboarding change affect conversion rate? Your growth or product team will know.
- Cost reduction: Infrastructure optimisations, caching improvements, or query efficiency gains often reduce cloud spend. Ask your infra team for before/after costs.
4. Scale of work
When direct outcome metrics aren't available, scale metrics can still convey meaningful signal.
- Lines changed: A migration that touched 50 files across 12 repos is inherently different from a three-line bug fix. Both might be important, but the scale context matters.
- Code removed: Deleting code is often harder than writing it. "Removed 8,000 lines of legacy authentication code" is a credible signal of meaningful work.
- Commits and PRs: Commit volume across a period isn't a direct impact metric, but it's a proxy for sustained, consistent output.
- Review throughput: If you're a thorough reviewer, the number of PRs you reviewed in a period is a real collaboration metric.
How to find numbers you didn't track at the time
You didn't track them in the moment — that's fine. Here's where to look retrospectively:
- Datadog / Grafana / CloudWatch: Most observability platforms retain 13–15 months of metric history. You can pull before/after charts for any deployment by looking at the timeline around your commit dates.
- Sentry / error tracking: Error volumes are typically retained for 90 days at minimum. Filter by the timeframe of a bug fix and you'll see the before/after error rate clearly.
- GitHub / GitLab analytics: PR merge times, CI pipeline durations, and commit frequency are often available under group or organisation-level analytics.
- Your PM or EM: Ask directly. "I'm writing my self-review — do you have any data on how the feature we shipped in Q3 performed?" Most product managers have this at their fingertips and are happy to share it.
- Slack: Search for reactions or comments from stakeholders around the time a project shipped. Positive signals ("this is great", "this unblocked us") are qualitative evidence you can cite.
Framing metrics that don't have a baseline
Sometimes you don't have a before state — you built something new where nothing existed before. In that case, frame around:
- Adoption rate: "Shipped the internal metrics dashboard. 14 of 18 engineers use it weekly within the first month."
- Problem eliminated: "Automated the weekly release notes process. Eliminated approximately 3 hours of manual work per sprint."
- Risk reduced: "Added integration tests for the payment webhook handler. Caught a double-charge edge case in staging before it reached production."
Avoid inflating or hedging
Two failure modes to avoid:
- Inflating: Don't round up aggressively or claim full credit for a team effort. "Our team shipped X" is fine — just be clear about your specific role within it. Reviewers who know the project will notice if numbers don't add up.
- Hedging: Don't bury your best metrics in qualifications. "The latency improvement was roughly around 70-80% or so" is less convincing than "p95 latency dropped from 4.2s to 1.1s." If you have the number, use it precisely.
Build the habit for next time
The engineers who write the most compelling reviews aren't necessarily the ones who did the most work. They're the ones who captured evidence as they went.
A simple habit: when something you built ships and moves a metric, screenshot it. When a stakeholder gives you positive feedback, save the message. When you see an error rate drop after your fix, note the before and after.
Even a basic running doc called "wins" updated once a week takes five minutes and pays back hours at review time.
For the commit-level evidence — which project you worked on, when, and how much — tools like Gitsprout handle the retrospective analysis automatically. Connect your GitHub, GitLab, or Azure DevOps account and it'll surface your commit history as structured review evidence across every standard category, ready to drop into your review doc.
The point isn't to game your review. It's to make sure the work you actually did gets seen — clearly, specifically, and credibly.