Before-and-after examples are illustrations. Use a revised description only when the facts match your work.
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.
Collect the facts before rewriting a bullet
Take one task and reconstruct the situation before the change. Identify your action, its users and what became possible afterward. Distinguish a verified result from an intended one: adding a check to catch an error describes a goal; the check catching an error in a later release describes an observation.
- What failed or required manual work?
- Which part did you implement yourself?
- Who used the change, and what could they do differently?
- How was it checked: a test, review or measurement?
Improved team efficiency and data quality.
Added validation to the order-file import. Invalid records identify the row and missing field, and a failed import leaves saved data unchanged. Tested these cases.
The time saved and usage scale are unknown, so the bullet does not invent them. It still identifies the change and the problem it handles.
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?