Building a Year of Wins
Most of us go through the year solving problems that never get recorded anywhere. A bug was fixed under pressure. A teammate you coached through a tough issue. A small cleanup that removed friction for everyone else. These moments matter, but they disappear as quickly as they happen.
By the time review season rolls around, the work blends together. You remember a few big projects, but the day-to-day impact — the work that actually defines your value — fades into the background.
Here’s the part people underestimate:
Review season rewards clarity, not memory.
Your manager isn’t tracking every improvement you make. They’re juggling priorities, team needs, and business goals. If you don’t surface the work that mattered, it often stays invisible.
A simple system for documenting wins ensures your contributions aren’t lost — and gives you a clearer picture of how much progress you actually made.
What Counts as a Win (More Than You Think)
When people start tracking wins, they gravitate toward big milestones: a major feature, a successful launch, a critical incident you solved. Those absolutely count, but they’re only part of the story.A “win” is any action that moves the team, the system, or the business forward.
That includes work that never makes it into a status update or sprint demo.
Business Wins
- fewer customer escalations
- measurable improvements to response time or throughput
- outcomes tied to KPIs your team cares about
If you want more ideas for thinking in terms of business impact, this pairs well with the idea of small, compounding behaviors in How to Win in the Margins.
System Wins
- stabilizing a recurring failure
- improving observability
- reducing build or deploy friction
These are often the “unseen wins” that prevent future fire drills. If you want a reminder of why these matter, look at how unnoticed friction can quietly derail a workflow in When Is Your Work Actually Complete?
Team Wins
- onboarding a new engineer in a clear, thoughtful way
- documenting tribal knowledge
- smoothing out a cross-team process
Anything that reduces confusion, improves collaboration, or strengthens trust is a win — even if it doesn’t feel big.If someone else’s job got easier because of something you did, write it down.For a broader lens on these kinds of skills, you might point readers to Four Skills Every Engineer Needs to Grow Their Career.
The Common Pitfalls
Once people start writing down wins, a few predictable problems show up. If you know them ahead of time, you can sidestep them.
Pitfall 1: Writing tasks instead of outcomes
Most engineers default to describing what they did, not what changed.
- Task: “Refactored the queue worker.”
- Win: “Refactored the queue worker, reducing processing time from 90s to 15s. Support tickets dropped the following week.”
The work is the same. The framing is different. One sounds like a line item. The other sounds like impact.
If you want more structure for turning work into impact statements, the performance self-review template from Pragmatic Engineer is a good reference point. The Pragmatic Engineer
Pitfall 2: Ignoring quiet, structural work
A lot of important work never looks like a “project” at all:
- cleaning up flaky tests
- making logs usable so on-call isn’t guesswork
- consolidating three slightly-different workflows into one clear path
This is the work that keeps everyone else from tripping. It’s easy to dismiss because it doesn’t ship as a feature, but teams feel the difference.
If you don’t write these down, they’ll vanish from your story.
Pitfall 3: Skipping evidence
You don’t need dashboards and perfect metrics for every win, but you do need some signal that something changed.
Evidence can be:
- a simple before/after number
- a screenshot of a graph
- a customer quote
- a Slack message from a teammate thanking you
Even one line like “incident count went from 5 per month to 1” changes how seriously a win is taken.
If you want a deeper dive on simple ways to collect and present this kind of proof, resources like Julia Evans’ article on brag documents show how a running log of wins and evidence can transform your review conversations.
Pitfall 4: Not tying wins to real priorities
A win lands best when it supports what your team already cares about:
- uptime and reliability
- customer experience
- cycle time and delivery speed
- security, compliance, or cost
You don’t have to force everything into a business case, but you should be able to answer:
“If this hadn’t happened, what would be worse right now?”
If the answer maps cleanly to a current goal or KPI, you’ve got a strong win.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
How to Track Your Wins
If this takes too long, it won’t survive busy weeks. The goal is something you can keep doing all year, not just in January.
Here’s a simple approach that fits on a single page in Notion, a doc, or a spreadsheet.
Once a week, spend ten minutes answering three questions:
- What improved because of me this week?
- Why did it matter?
- How do I know?
Then drop it into a table like this:
- Week: May 10
- Win: Stabilized queue worker
- Result: Processing time dropped from 90s → 15s
- Evidence: Datadog screenshot
That’s all you need. Over a few months, these small entries turn into a clear pattern: how you reduce risk, speed things up, help people grow, and prevent future pain.
For more structure and examples, readers who like templates can also look at Gergely Orosz’s performance self-review templates for engineers. How to Share Your Wins Without Feeling Self-Promotional.
This part makes many engineers uncomfortable. The key is intent. You’re not bragging — you’re helping your manager see the full picture so they can develop you, advocate for you, and plan effectively.
A simple approach:
“I’ve been tracking improvements I contributed to this year. Here are the ones I think mattered most. I’d appreciate your thoughts on where to focus next.”
Putting It All Together: Why Presentation Matters
Two people can do very similar work and be perceived very differently based on how they describe it. Here are a few quick examples that show how to position your achievements so they land.
Example 1
Weak: “Migrated logging system.”
Strong: “Migrated logging system, reducing investigation time for production issues from hours to minutes. On-call load dropped immediately.”
Example 2
Weak: “Helped onboard a new engineer.”
Strong: “Created a two-week onboarding plan. New hire shipped production code on day six and required fewer handoffs.”
Example 3
Weak: “Improved deployments.”
Strong: “Automated key deployment steps. Weekend deploy time fell from three hours to twenty minutes, and the team immediately commented on the relief.”These small shifts turn a task into a contribution.
Most wins don’t feel like an opportunity to promote yourself while you’re doing them. They just feel like solving a problem, helping a teammate, unblocking a workflow, or preventing something from breaking.
But when you track them, a different story emerges — one of steady progress and meaningful impact.
A year of wins isn’t created in December. It’s created one small moment at a time.
A habit of documenting those moments simply helps you see them clearly.