A responsibility describes activity; an outcome describes change
Implementing features, fixing bugs and reviewing code are activities. Without context they do not reveal value, quality or scope.
An outcome may be a metric, but it can also be removed risk, a shorter process, fewer regressions, another team enabled to work or an important capability delivered to users.
What if you do not know the percentages?
Never add numbers you cannot defend. Use other concrete evidence: rollout scale, markets, adopting teams, a technical constraint, a critical process or what became possible after the change.
A precise qualitative result is better than a false percentage.
Responsible for frontend testing and quality.
Added visual tests to the design-system release process so component regressions were detected before packages reached four product teams.
Evidence before a strong verb
Optimised, improved and increased naturally invite the question: by how much or by what mechanism? If measurement is unavailable, explain the change mechanism.
A good impact statement is auditable in an interview: you can explain how you knew the problem existed, what you changed and how the team verified the result.
Not every bullet needs to be an achievement
A role description may include context and core responsibilities. The issue is hierarchy: the strongest outcomes should be easiest to find.
Move specific results to the beginning and shorten supporting information so it does not compete with the strongest evidence.
Check your CV
- Does the bullet say what changed?
- Can you explain the source of every number?
- Without a number, do you show a mechanism, scale or removed risk?
- Are the strongest outcomes first?