If you have ever stared at the line "design system migrated from Material to Tailwind" and wondered what number to put next to it, you are not alone. Most jobs do not come with a built-in dashboard. The advice to quantify everything assumes a measurement system that does not exist for most roles. You can still add real numbers. You just have to look for them in the right places.
Numbers you almost always have
Before reaching for a percentage you do not have, count what you actually do. Useful numbers tend to come from one of these sources.
Counts. How many of something did you ship, fix, run, train, support, or own? Tickets resolved per week, features released per quarter, customers onboarded last year, team members you mentored, vendors you managed, codebases you touched.
Time. Cycle time on releases. How long a process took before you got there, and how long it takes now. How many hours per week you saved your team. How many days to first response.
Range and scale. Team size you worked with. Number of stores, sites, languages, regions. Number of users your work reaches. Budget owned. Number of stakeholders coordinated.
Frequency. Standups led per week, reports written per month, audits passed per year, weekly active users for a tool you built.
When you write a bullet, ask three quick questions: how many, how often, how big. If you can answer any one of them, you have a number.
Estimate, but stay defendable
If you do not remember the exact figure, an estimate is fine as long as you can defend it in an interview. Two rules keep you safe.
Round down. If you trained "around fifteen" people, write "trained 12 colleagues" and you will not be wrong. Round-up estimates are how people get caught.
Use ranges when the truth is fuzzy. "Cut average ticket triage from 3 to 4 days down to under 1" is honest and easier to back up than "reduced ticket triage by 75 percent".
Numbers you should never invent
If you cannot answer how many, how often, how big, do not make a number up. AI tools are particularly happy to insert percentages that sound impressive. Recruiters now ask about those numbers in interviews, and a walked-back metric kills a candidacy faster than no metric at all.
If a bullet refuses to give you a number, that is also useful information. Either the work was not yours to measure, or it was a smaller piece than you thought. Both are fine. Lead the bullet with a strong verb, name a tool or a system, and move on.
The pattern that works
Compare:
Improved deployment process.
Cut release cycle from weekly to twice daily by moving us to trunk-based development; team of 9 engineers, zero rollbacks in the first quarter.
The second one is not magic. It just answers the three questions. How often (twice daily). How big (team of 9). What changed (trunk-based, zero rollbacks).
You do not need to quantify every line. You need two or three lines with real numbers per role. That is enough to make the rest of your resume feel grounded.