How to write a tech CV that shows your impact, even without metrics

Your CV says you attended meetings, managed tickets and supported delivery. All of that may be true, but it leaves the reader guessing about what your contribution actually involved.

Advice to “add numbers” can make this harder. What if nobody measured the change? What if the outcome belonged to a whole team? You can make your work clearer without inventing a percentage or taking credit for someone else’s contribution.

Start with evidence: the problem, your action, the observable result and the part you played. This works for development, product and delivery roles, including when you are changing direction.

Collect evidence before rewriting

Choose three pieces of work you remember well. Use material you are entitled to access, such as your own notes, feedback and records of decisions. Keep confidential details out of your personal documents.

For each example, answer four questions:

• What needed to improve or be decided?
• What did I personally do?
• What changed that I can support with evidence?
• What was the scope, and who else contributed?

Sometimes the result is qualitative: a decision was reached, a confusing process was documented or a recurring support question gained a clear answer. Explain that accurately rather than turning it into a financial claim.

Three illustrative CV rewrites

These examples are fictional wording demonstrations. Use the structure with your own evidence; do not copy an achievement you have not delivered.

1. Show the work inside “supported delivery”

Before: “Supported project delivery and attended stakeholder meetings.”

After: “Coordinated a decision on conflicting reporting requirements, documented the agreed scope and helped development and data colleagues plan the next delivery step.”

The second version identifies a problem and an action. It does not claim that you led the whole programme or improved delivery speed. Add the scale only if you know it, such as which teams or product area were involved.

2. Explain why the technical change mattered

Before: “Built and maintained website features.”

After: “Implemented validation for a booking form and tested missing and invalid entries, giving users a clearer explanation of what to correct before submitting.”

This connects the implementation with its intended benefit and the checks performed. If you observed fewer failed submissions afterwards, add the verified result and its period. If you did not measure that, do not imply that you did.

3. Make facilitation visible

Before: “Ran Agile ceremonies.”

After: “Facilitated team retrospectives, helped colleagues agree improvement actions and followed up on whether those changes addressed the issues raised.”

This describes useful behaviour more clearly than naming a meeting. If there is a specific improvement you can demonstrate, explain it. Avoid claims such as “transformed team culture” without evidence that supports their scope.

Use numbers when they clarify the work

Metrics are helpful when they are reliable and relevant. Check where the number came from, what period it covers and whether you can reasonably connect it to your contribution.

Scope is often easier to substantiate than impact. You may know that you supported two teams or reviewed a particular set of user journeys. These details can help a reader understand the work, even when you cannot measure its overall benefit.

Do not calculate a saving from an informal guess and present it as a measured outcome. Keep approximate claims clearly labelled, or use a factual description instead.

Tailor the evidence to the role

Read the responsibilities and choose examples that show relevant experience. A development application may need implementation and debugging evidence. A Product Owner application may need decisions about user problems, priorities and value.

Keep your official job title accurate. You can describe product-related responsibilities underneath a developer title without claiming you were already a Product Owner.

Use clear headings and readable formatting. Explain an unfamiliar abbreviation if it is important to the role. Follow the employer’s requested file format and check that the exported document retains selectable, correctly ordered text.

Keep career breaks factual

If you choose to explain a break, use a brief description you are comfortable sharing. Include relevant learning or projects only if they happened. You do not need to invent continuous professional activity to make a break acceptable.

The useful question is what evidence connects your experience with the role you want now.

Update one CV bullet today

Choose a vague bullet and replace it with a specific problem, action and supported result. Read it aloud and ask: “Could I explain this honestly in an interview?”

If the answer is yes, you have made your contribution easier to understand. That is the purpose of the rewrite.