2 min read

Individual praise is a team opportunity

Give deep praise, and give it context. Praise is more impactful when people can also understand why the subject of the praise is important.

Give deep praise, and give it context. Praise is more impactful when people can also understand why the subject of the praise is important.

Why is it good? Show you understood what they did

"Great job" doesn't tell me you know what I actually did - @inert_wall

When giving praise, it's important to be genuine. To be genuine, you have to be specific. If you can't be specific, what are you praising?

Most often, I'm giving praise like this at a standup or a demo session. There's some context built in. Picking up on what was challenging about the work is where you'll find opportunities to be specific.

Meh:

You did a good job fixing that bug in the report.

Better:

You did a good job wrapping your head around those fact tables. I know the lineage of how those tables get populated isn't very well documented, but you managed to figure it out. Now we have a better understanding of how it works and why it was broken - and we get to close a bug.

✅ What they did, in credible detail

✅ Why it was hard, and how they used their skills to overcome that

✅ How it helps move things forward

Why is it important? Use what they did to provide context for a teams work

As the adage goes: criticism in private, praise in public. So when you are praising in public, you have the opportunity to make it clear why this good piece of work that someone completed is also important.

It's good for everyone to have it reinforced how what the team is working on actually matters, and how it moves the needle. People should feel like they're part of a winning team.

Tie it back to a team goal:

Burning down this backlog of bugs will mean we can stop being reactive and start being more proactive about how we want to improve this piece of our data infrastructure.

Tie it back to a product goal:

Burning down this backlog of bugs will improve user confidence in our reporting. Small bugs add up, and it undermines the value we are trying to deliver. This criticism appears often in our our NPS, we should expect that to improve as we keep closing bugs. We've been putting off building on what we considered a shaky foundation - once we get to zero bugs, we can start exposing new data that's often asked for.

Tie the progress to a piece of work that naturally follows:

We planned to invest in better documentation for these datasets, so completing work like this is a great excuse to start. It'll help us make changes with confidence. It's be a resource for support to raise more precise issue reports. It's a resource for QA to do more qualified testing. Engineering teams that want to contribute to the reporting suite will have a place to start.

I like digging into these a bit more at demo's, especially when other stakeholders join to observe. Gives context to colleagues who are further away from the work.

Don't be a robot

Be sincere. Don't force it. This isn't a script.

Sometimes a "good job" is all it takes, and that's okay. Prove you get it, prove you care, prove you understand - help everyone else do that too. Help everyone else see what you see when you give the praise.

If you do it in earnest you can't go wrong.