Self congratulatory atmospheres can be suffocating. When every small win is celebrated like it's sending a man to the moon, it can undercut legitimately impactful moments.
My rule of thumb for giving people kudos is:
- Quantify the financial impact of what they've done (revenue or saved cost). Would this make someone in Finance or Ops say "dang, that's a lot of money".
- Could anyone else have done this1? Is there some unique secret sauce that this person brought to bear?
- Own successes and failures. If you're only advertising the times that you've succeeded, you make positive accolades into the din of background noise. Recap failed or delayed projects in similar channels, ideally with a RCA attached so people collectively can learn something.
- Cite your sources. Include PRs, figma designs, and anything that can stand fully baked. Some features are deceivingly simple. Looking under the hood reveals what it actually took to make it happen2.
- Write them in an email, not on Slack. Slack channels only reach the people that are already most engaged on a project. If you're trying to socialize success, let people (especially in the C-Suite) forward it via email.
Will these rules independently combat a self-congratulatory atmosphere? Probably not. But if you start here, you'll already be ahead of a lot of cultures that I've seen struggling from its consequences.
-
It could be the specific approach, the delivery timeline they were operating under, etc. ↩
-
It also helps executives understand tech debt. If something intuitively feels like it should be fast to change, but ended up being more complex - what's the issue here? Should we invest in a refactor or stack change to make it easier in the future? ↩
