Consider an analyst finishing a reporting redesign and deciding what to record. A generic list offers quick prompts such as “improved processes,” while examples of accomplishments from a specific role show what you owned and what changed. An example grounded in the actual work takes longer to write, but may be far more useful at review time. To choose between them, ask whether the entry shows what you owned, what changed, and what proof you can safely keep. Those same questions apply when the work is a product design decision or a software reliability fix.
Generic lists versus examples grounded in the work
Generic accomplishment lists are useful when your mind goes blank. They can remind you to look for improvements, collaboration, and problems solved. Their weakness is that they describe categories of work, not your contribution to a particular result. “Improved reporting” may be true, but it gives your future self little to explain.
Examples grounded in a role should pass the same three tests each time:
- Ownership: Can you identify the decision or piece of work that was yours?
- Change: Can you say what became easier, faster, clearer, or more reliable?
- Proof: Can you point to an appropriate measure, artifact, or observation that supports the claim?
Use a generic list to find a topic. Use the three tests to decide whether you have an accomplishment worth recording.
Reporting work compared on ownership, change, and proof
A quick note might say, “Created a better dashboard.” It names an output but leaves open who defined the problem, how the dashboard was used, and what improved. Six months later, you may remember building it without remembering why anyone needed it.
A stronger entry could say: “Reworked the weekly reporting view after finding that teams used different definitions for the same measure. I aligned the definitions with the stakeholders, documented the agreed calculation, and made the view easier to use in planning discussions.” Add proof you actually have, such as an approved definition or feedback about a decision the new view supported. Do not claim that the dashboard changed a business result unless you can connect the two.
On the three tests, the second note identifies ownership, describes a change in how people use the work, and leaves room for a specific source of proof. Record it soon after the discussion, while the disputed definition and your decision are still clear.
Does a design example survive the same test?
“Improved the onboarding experience” is a reasonable reminder, but a thin review example. Compare it with: “Simplified the account setup flow after research sessions showed where participants hesitated. I proposed a shorter sequence, worked through the constraints with engineering, and checked the revised flow against the original points of confusion.”
Ownership sits in the proposed sequence and the decisions behind it. The change is the revised experience, while proof might come from research observations or a documented comparison of the flows. If later results are unavailable, stop at what the evidence supports. A clear account of your judgment is more useful than an unsupported claim about conversion.
Capture this kind of work when a design decision is accepted or tested. At that point, you can still distinguish your reasoning from the many revisions that followed.
A reliability fix against a generic completion note
“Fixed a recurring issue” tells a software engineer what to search for, but little about why the fix mattered. A more reusable note could read: “Traced repeated job failures to an unhandled retry condition, changed the retry logic, and added a test for the failure path.” The engineer owns a diagnosis and a fix; the change is a failure path the system handles differently; the proof is the test and any appropriate follow-up observation.
The tradeoff is time. Detailed entries take a few more minutes than a list of finished tasks, so reserve them for work involving a meaningful decision, an obstacle, or a visible change. Write one after a fix has been checked rather than waiting for review season to reconstruct the investigation.
Which record should you keep for your next review?
Start with whichever generic prompt helps you remember the work, then replace the prompt with a concrete account of ownership, change, and proof. Before saving it in a personal tool, leave out proprietary code, restricted documents, customer details, and other sensitive company material. You can preserve the reasoning and result without copying the underlying files.
ImpactLogr gives those short accounts a place to remain available when you need examples for a review, promotion discussion, or interview. To put the comparison to work, record one accomplishment with its supporting evidence in ImpactLogr.