Recognition Is a Safety Signal (Not a Reward)

When was the last time you publicly thanked an engineer for speaking up and challenging you?

Not for shipping. Not for staying late. Not for hitting the sprint commitment with zero spillover. When was the last time you stood in front of your team and said, “I want to call out what Sarah did in planning last week — she told us this approach was wrong, and she was right, and we would have burned two sprints if she hadn’t spoken up”?

If you’re being honest with yourself, it’s been a while. Maybe never.

Here’s the thing: you probably have a values document somewhere. Maybe it lives in Confluence, maybe it’s pinned in a Slack channel nobody reads. It says something about courage, or transparency, or “we value candid feedback.” And you mean it — you wrote it with good intentions, maybe even got the team to contribute. But values documents are like gym memberships in January. The intention is real. The follow-through tells a different story.

As the legendary UCLA basketball coach John Wooden put it, “The true test of a man’s character is what he does when no one is watching.” In engineering leadership, I’d adapt that slightly: the true test of what you value is what you recognise when everyone is watching. Because that’s when the signal is loudest.

The Signal You’re Already Broadcasting

Most engineering leaders treat recognition and psychological safety as two completely separate leadership competencies. Recognition lives in the “motivation and retention” bucket — the conference talk about keeping your best people. Psychological safety lives in the “culture and trust” bucket — the other conference talk about creating brave teams. They show up in different training modules, different books, different frameworks. And that separation is actually wrong, in a way that causes real damage.

Recognition is a signalling mechanism. Every time you recognise someone publicly, you’re broadcasting to the entire team: this is what good looks like here. And the inverse is equally true — what you never recognise, people learn to interpret as “that’s not valued, so it’s probably not safe to do.”

Think about what happens in most engineering orgs. Who gets the shout-out? The person who shipped the feature on time. The person who hit the sprint commitment. The person who stayed late and got the deploy out on Friday. The hero.

Now think about what almost never gets recognised. The engineer who raised a concern in planning that slowed things down but prevented a bad architectural decision. The person who admitted their approach wasn’t working and asked for help early instead of struggling silently for two weeks. The person who said “this solution works, but it’s going to make the next team’s life miserable” when everyone else was ready to merge and move on.

Those behaviours are exactly the ones psychological safety is supposed to enable. But if your recognition patterns only reward output and speed, you’re actively undermining safety through a channel most leaders aren’t even watching.

You’re saying “we value psychological safety” with your words and “we value shipping” with your recognition. People don’t listen to words. They watch what gets rewarded.

The Sprint Demo Problem

If you’re running Scrum — or whatever your organisation’s flavour of it looks like — you’ve got a built-in recognition ceremony that most teams don’t even think about critically. The sprint demo.

What gets celebrated in a sprint demo? Completed work. Features. A hundred percent sprint completion gets a fist pump from the PO, a bit of a clap from the manager. “Great sprint, everyone.” The board is clean, the velocity chart looks good, and we move on.

But when do you recognise behaviour? When do you call out the engineer who flagged a risk that nobody wanted to hear? When do you celebrate the person who refactored a critical path instead of just bolting on another feature? When do you thank the junior who asked the “stupid” question in the architecture review that turned out to not be stupid at all?

The economist Daniel Kahneman spent decades studying how humans make judgments under uncertainty, and one of his key observations was that people are far more influenced by vivid, emotionally available examples than by abstract principles. A values document is an abstract principle. Watching your manager publicly praise someone for pushing back on a bad idea — that’s a vivid, emotionally available example. It lands differently. It sticks.

This is why public praise for the right behaviours is worth fifty times what a values document delivers. Not because values documents are useless — they do help establish a baseline. But alone, without the reinforcement of visible recognition, they’re wallpaper. Nice to look at, easy to ignore.

You’re Training Your Team Right Now (Whether You Realise It or Not)

Every recognition moment is a micro-announcement about what’s safe to do in your team. And most leaders are accidentally broadcasting “only output matters” dozens of times a month without realising they’re systematically dismantling the safety they claim to want.

Think about the stories that get told in your organisation. Not the official narrative — the stories engineers tell each other over lunch, over beers, in DMs. “Did you hear about the time Somchai stayed up all night to fix the production outage?” “Remember when Namfon shipped that entire feature in a single sprint?” These are the legends of your engineering culture, and they’re almost always about individual heroics under pressure.

Now think about what those legends teach new engineers walking through the door. They teach them that what gets noticed here is powering through difficulty alone and delivering. The engineer who’s burning out silently isn’t failing to feel safe. They’ve correctly read the signals and concluded that struggling visibly isn’t safe here.

This connects to something I see constantly in engineering teams across Southeast Asia and beyond. There’s a particular dynamic in high-performing, culturally diverse teams where engineers impose enormous pressure on themselves. They grind silently because they think that’s what’s expected. They don’t ask for help because they’ve never seen anyone get praised for asking for help. They don’t raise concerns because every story they’ve heard about success in this company involves someone who overcame obstacles quietly and delivered.

That behaviour doesn’t come from nowhere. It comes from watching what gets recognised.

Recognition as Curiosity

Here’s where it gets practical. The shift isn’t complicated, but it does require intentionality.

Instead of “great job shipping X,” try “I noticed you pushed back on the original scope in planning — what made you see that risk?” That’s recognition and curiosity combined. It tells the person their challenge was valued, and it tells everyone watching that challenging scope is something leaders here pay attention to and appreciate.

Instead of only highlighting what was delivered in retros, call out how the team worked. “I want to recognise that three people flagged concerns early this sprint, and because of that, we avoided a significant rework cycle.” That reframes the narrative from “we shipped” to “we made better decisions because people spoke up.”

Instead of the hero story — the late night, the weekend push, the individual who saved the day — tell the story of the team that caught the problem before it became a crisis. The drama is quieter, but the signal is louder.

The British cycling coach Dave Brailsford became famous for his philosophy of “marginal gains” — the idea that tiny improvements across many areas compound into transformational results. Recognition works the same way. Each individual moment of praising the right behaviour seems small. But compounded across weeks and months, those moments reshape what your team believes is valued, which reshapes what they’re willing to do, which reshapes your entire engineering culture.

What to Actually Recognise

If you want to build a culture where engineers feel safe to challenge, experiment, raise concerns, and admit mistakes, you need to start recognising those exact behaviours. Publicly. Consistently. Not as an afterthought after the sprint demo, but as a deliberate practice.

Recognise the engineer who said “I was wrong about this approach” early, before it became expensive. Recognise the person who asked for help instead of spending two weeks struggling in silence. Recognise the team member who slowed down a decision because they saw a risk nobody else had considered. Recognise the person who deleted code instead of adding to it. Recognise the engineer who helped another team unblock instead of focusing solely on their own sprint commitments.

Make it visible. Say it in the team channel. Say it in the all-hands. Say it in the one-on-one and then, with their permission, say it again where others can hear it. Because recognition that happens in private builds confidence in one person. Recognition that happens in public builds culture across the team.

And here’s the uncomfortable corollary: if you only ever recognise shipping, speed, and individual output, you are telling your team — clearly, repeatedly, unmistakably — that those are the only things that matter here. No amount of psychological safety workshops will overcome that signal. No values document will override it. Your recognition patterns are your values, regardless of what’s written on the wall.

The Reframe

Stop thinking about recognition as a reward you hand out after good behaviour. Start thinking about it as a safety signal you’re constantly broadcasting.

You’re not failing at psychological safety because you haven’t read enough Amy Edmondson. You’re failing because your recognition patterns are telling your team exactly what you actually value — and it isn’t safety.

The good news is that this is one of the most fixable problems in engineering leadership. It costs nothing. It requires no reorganisation, no new tools, no budget approval. It just requires you to pay attention to what you praise, and to deliberately, visibly, consistently praise the behaviours that make your team braver.

Behaviour is core to what builds engineering culture. If you want to grow a particular culture, you need to grow the behaviours that support it. And the single most powerful way to grow behaviour is to call it out. Tell everyone what you think makes a good engineer — not in a document, but in the moment, in front of their peers, with specifics.

Now, if you’ll excuse me, I need to go publicly thank the engineer who told me my proposed architecture was overcomplicated last Thursday. She was right. And if I don’t say that out loud, in front of the team, I’m just another leader who says he values challenge but only recognises compliance.