How to show engineering impact when you do not have perfect metrics

Your self-review asks for impact.

You have a migration, a design decision, a production problem you prevented, and several weeks of helping other engineers get unstuck; but you do not have a neat percentage for everything.

So you start doing the dangerous thing: trying to turn every accomplishment into a number that sounds impressive enough.

That is how engineers end up with bullets like this:

Improved team efficiency by 37% through better collaboration.

Where did the 37% come from?

If you cannot explain the measurement, it weakens the whole statement.

You do not need a percentage for every piece of work. You need a credible chain between what you changed and what became different.

Start with the change, not the metric

When the number is missing, do not start by asking, “What metric can I add?”

Start with:

1. What was different before I started?
2. What did I personally change?
3. What became possible, safer, faster, clearer, or easier afterward?
4. What evidence would let another person verify that change?

That gives you a better starting point than a blank “impact” field.

Consider this illustrative example.

This version does not claim a made-up productivity percentage. It tells the reader what changed, what you did, and why the change mattered.

If you can later verify that first independent change moved from day 10 to day 6, add it. If you cannot, keep the truthful version.

Use an evidence ladder

Metrics are one kind of evidence. They are not the entire ladder.

Use the strongest layer you actually have.

1. Direct results

Use a measured result when you have one:

Reduced checkout-related regressions from 6 to 1 in the next release cycle by separating payment, tax, and confirmation logic and adding targeted regression coverage.

This is strong because the before state, after state, mechanism, and measurement are all visible.

Direct results can include:

• latency or build time;
• incident or rollback count;
• support volume;
• infrastructure cost;
• adoption or usage;
• time to complete a workflow;
• number of teams or services using the change.

Do not delay writing the accomplishment until you have the perfect dashboard. Save the source material while the context is still available, then add a result when the system makes one visible.

2. Reliable proxies

Sometimes the exact business outcome is unavailable, but the scope is clear.

For example:

Created a shared deployment checklist adopted by 4 engineering teams, replacing four slightly different release paths and giving incident responders one current rollback procedure.

The number of teams is not the same as a revenue metric. It still tells the reader that the work travelled beyond your own branch or squad.

Other useful proxies include:

• the number of engineers who used the guide;
• the number of services covered by a migration;
• the number of teams aligned by a design decision;
• the number of repeated manual steps removed;
• the number of incidents, reviews, or releases affected.

Label the proxy honestly. Do not present reach as proof of business success when it only proves adoption or reuse.

3. Before-and-after states

You can show impact without a metric when the change is concrete enough to compare.

The evidence here is not “documentation improved by 42%.” It is the artifact, the missing states you addressed, and the teams that could now work from the same contract.

Before-and-after evidence works particularly well for:

• confusing setup paths;
• fragile deployment processes;
• repeated review feedback;
• unclear ownership;
• noisy alerts;
• competing implementations;
• systems that depended on one person’s memory.

Write down the before state in plain language. What was slow, risky, unclear, blocked, repeated, or fragile?

4. Risk reduction and prevention

Prevention is easy to under-report because the best incident is the one that does not happen.

That does not mean you should claim that your work prevented every possible failure. It means you should describe the failure mode you addressed and the evidence that the system became safer or easier to operate.

If you have a later signal, include it:

The next 3 on-call investigations used the new trace and runbook instead of escalating to the payments team.

If you do not have that signal, do not invent one. Keep the evidence at the level you can support: the failure mode, the control you added, and the artifact that another engineer can inspect.

5. Decisions and leverage

Some engineering impact happens before code is written.

For example:

Compared three notification designs, made the event ownership tradeoff explicit, and aligned product, backend, and mobile on one model before implementation. This avoided three teams building separate delivery rules for the same customer event.

The evidence is the decision record, the options considered, the people aligned, and the work that no longer needed to happen.

This matters more as your scope grows. Dropbox’s public engineering framework describes impact through customer value, operational reliability, efficiency, technical leadership, and mentorship. Its framework does not reduce impact to one universal score. Read the framework’s definition of impact.

For a promotion conversation, save:

• the problem statement;
• the options and tradeoffs;
• the decision you recommended;
• who needed to align;
• what the decision unblocked;
• what risk or duplicate work it removed.

6. Reuse and specific feedback

Reuse is evidence that an idea travelled. Feedback is evidence that somebody noticed a change.

Neither is enough when it stays vague.

Save the original message, review comment, or document link when you can. Future-you will not remember the wording as accurately as you think.

Separate the team outcome from your contribution

This is where many impact statements become inflated.

Your team may have reduced incident volume. That does not automatically mean you personally reduced it by the full amount.

Use a structure that keeps the boundary clear:

Team outcome: what changed for the product, service, or group.

My contribution: the decision, implementation, coordination, or mechanism I owned.

Evidence: the artifact, measurement, feedback, adoption, or observable change that supports the connection.

For example:

The platform team reduced deployment failures from 8 to 3 per month. I isolated the shared configuration problem, added validation before release, and documented the rollback path used by the team.

That is more credible than saying:

Reduced deployment failures by 62%.

The second statement may be technically true as a team result, but it hides the contribution boundary. A manager or calibration committee needs both the outcome and your role in creating it.

DORA makes a similar distinction from another direction. Its software delivery metrics are designed to help teams deliver safely, quickly, and efficiently, with shared ownership across development, operations, and release teams. They are useful system signals, not a complete personal accomplishment ledger. Read DORA’s guidance.

Do not turn missing metrics into a measurement project

There is a trap on the other side too.

You can spend so long reconstructing numbers that the evidence work becomes another project you never finish.

Use this order:

1. Save the concrete change.
2. Attach the strongest evidence already available.
3. Add a metric later if it becomes easy to verify.
4. Stop when the statement is accurate and useful.

Do not use these as standalone proof:

• lines of code;
• number of commits;
• number of tickets closed;
• hours spent online;
• vague adjectives such as “significantly” or “dramatically.”

Activity can provide context. It rarely explains value by itself.

Turn the evidence into an X-Y-Z statement

Once you have the evidence, the X-Y-Z structure becomes useful:

Accomplished X, as measured by Y, by doing Z.

When Y is a number:

Reduced p95 report-generation latency from 4.8 seconds to 1.6 seconds by replacing repeated client-side aggregation with a cached API response.

When Y is an observable change:

Improved deployment handoffs by giving 3 teams one rollback checklist and a shared ownership map, reducing the number of releases that required an escalation to the original service owner.

When Y is a decision or reuse signal:

Clarified the event model before implementation by writing the tradeoff document that aligned product, backend, and mobile and prevented three competing delivery paths.

The formula is not asking you to force a number into every sentence. It is asking you to connect the result to evidence and the evidence to your mechanism.

Capture evidence before you need the sentence

The easiest time to find a metric is usually close to the work.

The easiest time to remember the decision is before the next project replaces it.

That is why a weekly capture habit matters. The weekly career-capture loop gives you a short way to preserve source material before review season turns the work into a reconstruction exercise.

You do not need to polish every note immediately. Save:

Context:
What changed:
What I did:
Evidence:
Who or what was affected:
Follow-up:

Later, you can use the engineering accomplishment examples to decide whether the note is a task, an accomplishment, or a stronger piece of promotion evidence.

Keep your evidence ready for the next career conversation

You can do this with a document, a spreadsheet, or a note in the system you already use.

The important thing is the evidence boundary. Your career record should preserve what happened without copying confidential implementation details, customer data, credentials, or numbers you are not allowed to share.

careercraft.ing is built for that evidence layer. You choose what to capture, keep the raw contribution reviewable, and shape it later for a self-review, promotion packet, manager update, or resume.

The writing step comes last.

Frequently asked questions

The number is not the whole story

Metrics help people understand change quickly.

But a missing percentage does not erase the work.

Save what changed, what you did, who or what it affected, and how somebody else could verify it. Use a number when you have a trustworthy one. Use a before-and-after state, a risk reduction, a decision record, a reuse signal, or specific feedback when you do not.

That is enough to make the work legible.

And legible evidence gives your future self something much better than an impressive number: a claim you can actually defend.

Career Notes

Get better at proving your work.

A short newsletter for engineers who want clearer career stories, stronger self reviews, and better evidence before the next big conversation.

Email address Subscribe

No spam. Just useful notes on career evidence and growth conversations.

You’re subscribed.

Check your inbox for the first note.