How do you recognise engineers without using commit counts or story points?

Recognise named pieces of work in writing: the review that caught something, an incident handled, a deletion nobody asked for. Activity metrics measure volume and are gamed within a sprint. A sentence about a specific pull request cannot be.

Should on-call work be recognised separately?

Yes, and the same morning. On-call is a cost paid by one person while the rest of the team sleeps, and the incident write-up is a natural trigger for a public thank-you, including when the response was imperfect and honestly reported.

Do engineers actually want public recognition?

Many prefer it specific and short. A message that names the pull request and what it prevented is welcome almost everywhere; a generic shout-out with confetti often is not. Ask the team which channel they want it in and keep it there.

How do you recognise refactoring and technical debt work?

Attach it to a number the team feels. Build time, test flake rate, deploy frequency, lines removed. The work is invisible until somebody says what it changed, and then it becomes the most popular kind of recognition on the team.

Recognition for teams

Employee Recognition for Engineering Teams: What Works

Engineering produces two kinds of work: the kind that ships with a launch post, and the kind that keeps the launch post from becoming an incident report. Recognition mostly reaches the first.

The demo thanks the last mile

Software work is organised around shipping, and shipping has a ceremony. The sprint review shows the feature, the launch post names the people who built it, and the company reacts with emoji. That ceremony is fine as far as it goes. The trouble is where it stops.

The feature was possible because somebody upgraded the framework in February, somebody else rewrote the flaky integration suite so the team could trust a green build, and a third engineer reviewed the data migration carefully enough to notice the column that would have been null in production. None of those people are in the demo. Two of them may not even remember the work by the time the feature ships, because from the inside it felt like routine.

A recognition habit on an engineering team exists to reach those three people. Everything else already has a ceremony.

Where the evidence lives

Engineering leaves an unusually good paper trail. Pull requests have reviewers. Incidents have timelines and write-ups. CI has a history, and the graph of build times is a record of who improved them. This makes recognition easier than in most functions, provided somebody reads the trail with that intent.

A manager can spend ten minutes on a Friday scanning the week’s merged pull requests for the ones that removed code, fixed tests or touched the runbooks, and the incident channel for the person who took the page. Each of those is a fair thing to thank in public, with a link. The link matters: engineers trust recognition with evidence attached and are suspicious of recognition without it.

Teams with regular feedback see 14.9% lower turnover, and on an engineering team the people most likely to leave are the maintainers who feel their work is the plumbing nobody sees.

Tagging the work the roadmap ignores

Values tags are more useful here than they sound. Agree on a short set, craftsmanship, ownership and candour for example, and tag each recognition. The monthly recap then shows how much of the team’s thanks went to launched features and how much to reviews, incidents and mentoring. If the ratio is ten to one, the team knows what to fix. Evergreen does this inside Slack or Teams and sends the recap without anybody exporting a spreadsheet, which is the only way an engineering team will keep doing it.

This week

Post one recognition about a code review, with the link. Ask the on-call engineer from last week what the worst moment was and thank them for it in the channel. And find the pull request with the largest negative diff of the month and say what it made faster. The incident response messages are a reasonable place to borrow phrasing from until the team finds its own.

What gets in the way

Launches get the credit: A feature demo at the all-hands thanks the people who built the last mile. The engineer who spent the quarter deleting the dead code that made the feature possible is not in the demo.
Maintenance leaves no evidence: Flaky tests fixed, dependencies upgraded, a runbook rewritten. The reward for this work is that nothing happens, and nothing is hard to thank.
On-call is a cost paid alone: Somebody was paged at 3am, fixed it, and wrote the incident up before standup. The team saw a green dashboard and a tidy postmortem, and rarely the night behind it.
Metrics reward the wrong thing: Commit counts and story points are easy to chart and easy to game. A team that recognises by leaderboard ends up thanking the engineer who splits every change into six pull requests.

What works

Thank the review as much as the code. A careful review that catches a data migration bug is worth more than the pull request it was attached to, and it is almost never mentioned.
Make the incident write-up the trigger. Whoever handled the page gets thanked by name in the channel the same morning, including for the parts that went badly and were reported honestly.
Recognise deletions. A pull request that removes four thousand lines deserves the same applause as one that adds them, and saying so out loud changes what people volunteer for.
Pair recognition with the retro. The last five minutes of the sprint retro are the moment when the team can still remember who unblocked whom.
Let engineers recognise product, design and support. The best bug report of the month usually came from outside the engineering channel.

5 messages written for this team

Priyanka’s review on the migration PR caught the nullable column before it reached staging. The fix took ten minutes because she found it on Tuesday rather than Friday night.
Manager, in the engineering channel
Thanks the review rather than the code, and prices the timing.
Thanks for taking the 2am page on the payments service, Tomás, and for writing it up so the rest of us could read it with coffee instead of adrenaline.
Peer
Names the cost and the second piece of work, the write-up.
Kenji removed 3,800 lines from the legacy scheduler this sprint and the build got forty seconds faster. Nobody asked him to. Every one of us benefits from it twenty times a day.
Manager
Applauds a deletion with a number the team feels daily.
Rafael, your flaky test hunt this week turned the red CI badge green for the first time since March. I had stopped believing it was possible.
Peer
Recognises maintenance work by its visible result.
Thank you, Wen, for pairing with our new graduate on her first production deploy and letting her press the button. That is how she learns to trust the pipeline, and herself.
Manager
Recognises mentoring, which never appears in a sprint report.

A program that fits

Start in the channel engineers already watch: Recognition posted to #engineering or the team channel gets read. A separate HR channel gets muted in a week.
Name the categories that are usually missed: Agree as a team that reviews, on-call, docs, test infrastructure and mentoring count, and tag them as values so they show up in the monthly recap alongside shipped features.
Put the reminder after the sprint boundary: A nudge on the day after sprint review lands while the work is fresh and the demo has already thanked the obvious people.
Read the month back at the engineering all-hands: Five minutes, three recognitions, chosen for the work the demo did not cover. Over a few months this shifts what the team thinks the job is.
Check who receives, rather than how much: If the same three senior engineers receive everything, the program is measuring visibility. Look for the person who reviewed forty pull requests and was thanked for none of them.

Questions people ask

How do you recognise engineers without using commit counts or story points?: Recognise named pieces of work in writing: the review that caught something, an incident handled, a deletion nobody asked for. Activity metrics measure volume and are gamed within a sprint. A sentence about a specific pull request cannot be.
Should on-call work be recognised separately?: Yes, and the same morning. On-call is a cost paid by one person while the rest of the team sleeps, and the incident write-up is a natural trigger for a public thank-you, including when the response was imperfect and honestly reported.
Do engineers actually want public recognition?: Many prefer it specific and short. A message that names the pull request and what it prevented is welcome almost everywhere; a generic shout-out with confetti often is not. Ask the team which channel they want it in and keep it there.
How do you recognise refactoring and technical debt work?: Attach it to a number the team feels. Build time, test flake rate, deploy frequency, lines removed. The work is invisible until somebody says what it changed, and then it becomes the most popular kind of recognition on the team.