Aug 16, 2026
We wanted to make recognition fair. It wasn't that simple.
What I learned while trying to build a recognition system that didn't just reward the most visible work.
When we introduced a formal recognition program, the response was encouraging.
People had been asking for more ways to recognize engineers, so we created a structured way to do it.
It looked simple.
It wasn’t.
The first version
The initial process was fairly straightforward.
Leadership would identify people who had performed particularly well, and we would vote on the nominations.
It worked for a while.
Then I started hearing a different kind of feedback in 1:1s.
Some engineers felt that the same few people were being recognized repeatedly.
The interesting part was that the people being recognized were not necessarily undeserving.
The problem was that some kinds of work were much easier to see than others.
Visibility is not the same as contribution
A major feature is easy to talk about.
It has a launch date. It has a customer. It has a visible outcome.
Other contributions are much harder to spot from a leadership meeting.
Someone who quietly helps three engineers get unstuck.
Someone who improves a process nobody notices because it simply starts working better.
Someone who prevents a production issue that never happens.
Someone who consistently makes the team around them better.
Those contributions can be significant without producing a headline.
I realized that our process was naturally biased toward the work we could see most easily.
We changed where the information came from
The next version tried to get closer to the people doing the work.
Instead of relying only on leadership’s view, managers gathered nominations from their teams and brought those names into the wider discussion.
This gave us information that wasn’t always visible at the leadership level.
It helped.
But it didn’t solve everything.
There were still people who disagreed with the outcome.
And that was useful to understand too.
Fair process doesn’t mean universal agreement
I had initially thought that if we made the process transparent enough, people would feel it was fair.
It turns out those are different things.
A transparent process can explain how a decision was made.
It cannot guarantee that everyone will agree with the decision.
Recognition is particularly difficult because people are comparing things that aren’t always comparable.
The engineer who delivered a critical feature and the engineer who spent weeks helping others may both have made an important contribution.
There isn’t always a clean formula that tells you which one deserves an award.
Feedback became part of the system
The most useful part of the process wasn’t the voting mechanism.
It was the feedback around it.
Each round told us something about what the previous version was missing.
We started with a leadership view.
Then we brought in information from closer to the teams.
That didn’t produce a perfect system, but it made the system better informed.
It also changed how I thought about organizational processes in general.
The part I still think about
Recognition systems are often treated as if the main problem is choosing the right winner.
I think the harder problem is making sure the people making the decision can actually see enough of the work.
The further away you are from the day-to-day work, the more you depend on visible outcomes as a proxy for contribution.
That doesn’t mean leadership should stop making recognition decisions.
It means leadership needs better inputs.
I’ve come to think of recognition less as a voting problem and more as an information problem.
The goal isn’t to create a system where nobody is disappointed.
The goal is to create a system where important contributions have a reasonable chance of being seen.
← Back to writing
Comments
Loading comments…