Recognition I think engineers actually value

A floodlit cricket stadium in Bangalore packed with spectators, the green field bright under the night sky

Most recognition programs I have seen reward what is visible. The launch gets the announcement. The demo gets the applause. The engineer who was up at 2am putting out the fire gets thanked in the all-hands. All of that is fine. What bothers me is what it misses, and I think it misses most of the work that matters.

The valuable work is often invisible

The fire that never started, because someone fixed the fragile thing in March, has no moment attached to it. The refactor that made the launch possible six months later is a footnote nobody remembers by launch day. The review comment that caught the bug which would have corrupted a week of data looks like a sentence in a pull request.

Engineers know this. They know which of their colleagues' work was hard and which merely looked hard. And they notice when the recognition goes consistently to the second kind, because it tells them what the organization can see, and they adjust.

What I think engineers actually want

I think the thing engineers want is to be seen for the right thing by someone who understood it. Both halves matter.

The right thing means the work they are proud of, which is often not the work that was visible. Asking is allowed. In a one-on-one, what did you do this quarter that nobody noticed is a question that gets honest answers, and the answers are a list of things worth recognizing.

Someone who understood it means that the recognition has to be specific enough to prove the person giving it actually knows what was done. Great job on the migration lands differently than I read the plan you wrote for the migration and the rollback section is why I slept that week. The second one is proof of attention. Attention is the scarce thing.

The forms I think land

Specific over general, always. A sentence that names what was done and why it mattered is worth more than any award.

The invisible work, named out loud. When something does not go wrong, I think a manager should say so, and say whose work made it not go wrong. Nothing broke during the migration because of the compatibility layer is a recognition of work that would otherwise never be mentioned.

Recognition from peers who know the code. A note from the engineer who inherited your module and found it easy to work in carries weight that nothing from a manager can match, because the peer has no reason to be polite.

Recognition that changes something. The person who has been quietly carrying the hardest part of the system gets asked to design the next one. That is recognition with consequences, and I think it is the kind people remember.

The public thank you is not always the right instrument

Not everyone wants to be named in the all-hands. Some engineers find it genuinely uncomfortable, and for them the public thank you is a cost dressed as a reward. I think a manager should know which of their people this applies to, and should find the private form that works for them instead. The point is that the person feels seen. The stage is one way to do that, and for some people the wrong one.

None of this costs anything but attention. That is why I think it is rare. Attention is the most expensive thing a manager has, and recognition that works is made of it.

Photo source: https://photos.robertstowe.com/bengaluru