You have 1 article left to read this month before you need to register a free LeadDev.com account.

Estimated reading time: 6 minutes

A simple “good job!” in a public Slack channel shouldn’t be your recognition strategy.

When one of my best engineers, who led the development of our critical system, told me during our 1:1 that she didn’t feel like anyone noticed what she did, I was stunned. But I knew that if she felt invisible as the lead engineer and a mentor for three junior developers on the team, something was fundamentally broken.

I used to think I was pretty good at recognition. The common mechanisms of my recognition included occasional “Nice work!” messages in Slack, shout-outs during standups, and thank-you emails after big releases. However, I soon realized that these superficial tactics didn’t actually create an environment where people felt seen for the work they actually did.

The markers of an undervalued team

The feedback I received in the 1:1 with my report was only the beginning. It was later reinforcedin our engagement survey, where engineers were asked, “I feel valued and recognized for my contributions.” The results showed we scored 2.8 out of 5, the lowest score across all categories, and well below the org average of 3.9.

The recognition structure itself was broken. Once a month, we’d hold a recognition ceremony where I’d publicly acknowledge ~2–3 engineers. Most people went 4–6 months between any acknowledgment. But here’s what really bothered me when I dug into the data: the engineers getting recognized weren’t necessarily doing the best work. They were doing the most visible work. The person who spoke up in planning meetings got noticed. The one who sent detailed weekly updates got recognized. Meanwhile, the engineer who kept our infrastructure running at 99.99% uptime? The one mentoring three junior developers? They were invisible in our system.

Your inbox, upgraded.

Receive weekly engineering insights to level up your leadership approach.

**What you should avoid **

Before I share what actually worked, let me save you some painful lessons by sharing what did not and why these approaches failed.

• Recognition apps and gentle gamification: We trialed a platform where people could give each other points and badges. Within three weeks of its inception, it became a popularity contest.
• Mandatory recognition exercises: I once required everyone to send one appreciation message per week. Soon, engineers felt it was more like homework than gratitude. After all, forced appreciation isn’t appreciation at all – it’s an obligation.
• Public-only recognition: I used to think that recognizing people publicly was always better. Then I discovered that for some team members, public callouts created anxiety, not motivation.
• Generic praise without specifics: Early on, I’d send messages like “Great job on the release!” thinking any recognition was better than none. But I was wrong: people couldn’t tell exactly what they did well, so they couldn’t replicate it.
• Annual recognition events: We tried a quarterly awards ceremony, inviting our org leaders to hand out “star performer of the quarter” recognition. It created three problems: first, it made recognition scarce by design, as there could be only one star performer; second, it came too late, once a quarter; and third, it created competitive dynamics.

The real issue behind these failures is simple: our approach to recognition has always been to implement it as a program rather than embed it as a behavior.

What actually moves the needle

Here’s what I’ve realized: as a manager, I see maybe 30% of what my team actually does. The remaining 70% that goes unseen includes late-night debugging sessions, patient and detailed explanations in code reviews, and the times someone drops everything to unblock a teammate.

After that wake-up call with the engineer, I started experimenting with different approaches to recognition. Some flopped spectacularly, but a few things actually worked:

• Peer recognition that people use: Of the different peer recognition ideas we tried, the one that worked best was starting our sprint retros with a simple question: “Who helped you out this week?” It became a natural moment where people would call out teammates, and because it was time-boxed, it didn’t feel forced.
• Recognition that fits the person: Directly ask your reports how they prefer to be recognized. Some may value quick private messages way more than public announcements. Asking new team members this question during onboarding has become a mandatory practice for me.
• Making invisible work visible: The most meaningful recognition happens when you spotlight the work that usually goes unseen. When our product manager started calling out code reviewers by name, or when I began highlighting improvements in infrastructure during our monthly all-hands, people suddenly realized just how much invisible effort kept everything running.

Making recognition sustainable

Looking back, my biggest misstep was trying to own all recognition instead of empowering others to share it. That’s a recipe for burnout and inconsistency. Instead, I focused on creating systems that could run themselves.

We designated rotating “culture champions,” like a scrum master, but for recognition. Every two weeks, one engineer volunteered to be our eyes and ears for good work that typically goes unnoticed.

Their job was simple: ask follow-up questions in standups when someone mentioned helping a teammate, facilitate our “who helped you this week?” retro segment, and call out good work in real-time without waiting for formal ceremonies. The magic wasn’t in the process; it was in getting different perspectives. Our senior engineer noticed mentoring moments I’d miss. Our newest team member highlighted the onboarding help that veterans forgot was valuable. Recognition stopped being solely filtered through a (my) “manager” lens.

The impact of recognizing impact

Two years into treating recognition as a real priority, we saw a transformation, and the data attested to it. Our “feeling valued and recognized” score jumped from 2.8 to 4.3 out of 5, a 54% increase, which moved us from the bottom quartile to the top 15% across the entire engineering organization. Recognition frequency increased from my sporadic 2–3 callouts per month to an average of 23 peer-driven recognitions per month, nearly 10× growth.

We also tracked participation in our “who helped you out this week?” retro segments. In the first month, only 3–4 people would speak up. By month six, we were averaging 9–10 people sharing appreciations, and we had to extend the time slot because people had so much to say. This wasn’t just about making people feel good; it changed the way we saw and appreciated each other’s work.

London • June 2 & 3, 2026

Rands, Nicole Forsgren &** Matej Pfajfar** confirmed

Why this actually matters

I’m not going to pretend that better recognition solved *all *our team problems. But after two years of being more intentional about it, I can tell you what changed:

People started helping each other more because they knew it would be noticed. Code review response times decreased, people were more likely to volunteer for cross-team projects, and our retrospectives shifted from what went wrong to what went right. And those engagement numbers I mentioned earlier? They translated into real retention, real collaboration, and real momentum.

The question isn’t whether you’re saying thank you enough – it’s whether you’re building a team where people feel genuinely seen and valued for the work they do. And not just the flashy stuff, but the daily grind that keeps everything running. When that changes, it changes how people show up. That’s harder than sending a Slack message, but it’s also what separates good managers from great ones.