I spent a year measuring myself by tickets closed. The metric was easy to game and impossible to be proud of. Here is what I changed and why output is not the same as outcome.
The first year of my engineering career, I had a number I cared about more than anything else: tickets closed per sprint. I tracked it in a personal note. I tried to beat the previous sprint. When the number went up, I felt good. When it dropped, I felt like I was slipping.
The number went up a lot. By the end of that year, I was the most "productive" person in my team by that metric. I was also responsible for, by my own count, three of the four worst design decisions in the codebase. The connection between those facts took me longer than I would like to admit to understand.
The output trap, explained without pretending I figured it out fast
Output is easy to measure. Outcome is hard. When you are new and trying to prove yourself, the easy metric is hypnotic. You can close tickets all day. You can pick the easy ones first, batch the small ones into sprints, and watch the count go up.
The problem is that ticket count rewards behavior that has nothing to do with whether the product gets better. Closing a ticket by adding a workaround instead of fixing the root cause counts the same as closing it with a real fix. Closing a ticket that nobody actually needed counts the same as closing one that unblocked three other people. The metric does not see any of that.
The second problem is that the easy tickets are easy precisely because someone else already figured out the hard part. The PM wrote the spec, the designer made the screen, the senior on the team identified the right approach. You executed. You closed the ticket. The credit is real, but the skill development is shallow.
I noticed I was stuck when I tried to lead a small feature end-to-end and could not. I knew how to implement what someone else specified. I did not know how to figure out what to specify. A year of "productivity" had taught me to be a fast executor and almost nothing else.
The conversation that broke the pattern
In a one-on-one, my tech lead asked me what I had shipped that month that I was proud of. I rattled off a list. He listened, then asked a different question: "Of those things, which ones changed how a customer uses the product?"
I had no answer for most of them. A few bug fixes, sure. But the features? The refactors? The "improvements"? Half of them I could not connect to anything a real user would notice. I had been busy and I had been useful in the narrow sense of executing assigned work, but I had not been impactful in any sense I could defend.
That conversation reframed what I was supposed to be doing. The job stopped being "close tickets" and started being "make the product better for the people who use it". Those sound the same. They are not.
What outcome-driven work actually looks like day to day
The shift is harder to describe than it sounds because most of the changes are small. Here is what changed in concrete terms.
I started asking "why" before "how" on every ticket. Not in a confrontational way — in a curious one. A ticket asking for a new filter on the leads page used to be "ok, I will add the filter". Now it is "what are you trying to find that you cannot find today? is a filter the right answer? would saved views work better?". Half the time the ticket gets implemented as written. The other half, it gets reshaped into something better or dropped entirely.
I started measuring myself by what changed, not by what I touched. At the end of each sprint, I ask: what is different now for a user of the product? If the answer is "nothing visible", then either the work was infrastructure that enables future visible work, or I spent the sprint on the wrong things. Both are valid answers, but the question forces honesty.
I started pushing back on volume. When a sprint plan had 12 tickets and they were all small, I asked whether we were doing the right work or whether we were just doing easy work. Easy work piles up in sprint plans because it is comfortable to commit to. Hard work resists planning, which is exactly why it gets postponed.
I started writing fewer tickets and more docs. A ticket says "do X". A short doc says "here is what we are trying to achieve, here are the options, here is the one I am leaning toward and why". The doc forces me to defend the choice before I write code. Two-thirds of the docs I started writing ended up changing direction before any code was committed. That is two-thirds of bad code I never wrote.
The measurement that actually works for me now
I keep a list. It has three columns: what I shipped, what changed for users or for the team, and how I would know if I was wrong. The third column is the hardest and the most useful.
For example: "Shipped the new caching layer on the leads endpoint" -> "P95 latency went from 1.2s to 180ms during peak" -> "I would be wrong if cache invalidation caused stale data complaints; tracking support tickets weekly". Three months later I can look at that row and see whether the outcome held.
Most rows do not hold the way I expected. The wins are smaller than I hoped; the side effects are bigger. The point of the column is not to be right. The point is to keep me honest about the gap between what I intended and what actually happened. That gap is where most of my learning lives.
Impacto em números
I close fewer tickets and that is the point
Was 0 a year ago
Was hard to count before because I did not track
What this is not
This is not an argument against being productive. It is an argument against confusing productivity with the easiest-to-measure proxy for it.
It is also not a call to stop closing tickets. Tickets are a coordination tool. The team needs to know what is in flight, who is doing it, and what is blocked. The ticket count is fine as a coordination signal. It is a bad performance metric and a worse personal goal.
The shift I made is small in description and large in effect. I stopped measuring myself by what I did and started measuring myself by what changed. Some weeks the answer is humbling. Most weeks it is more accurate than the count of closed tickets ever was.
If you are early in your career and reading this
You will be tempted to optimize for legible output. Closed tickets, pull requests merged, lines of code committed. These metrics are visible. They are easy to brag about. They are also the metrics that experienced engineers have stopped caring about.
The senior engineers I work with are not the ones who ship the most. They are the ones who ship the right things and refuse to ship the wrong ones. Sometimes their best week of work is convincing the team not to build something. That contribution does not fit on a sprint board, and they are fine with that.
If you want to grow faster than your output suggests, start asking the second question. Not "what did I do this week" but "what is different in the world because of it". The honest answer will sting at first. It is also the only answer that compounds.