Developing a Rewards and Recognition Program
13 August, 2021
Engineering Manager at Atlassian
Problem
A large number of engineers working in one of my previous companies felt under appreciated. They thought they were doing a lot of great work, but that rewards and recognition were not coming their way.
This is a common situation in many engineering organizations. Visibility and appreciation are not easy to ensure when a fast-paced environment dictates its own priorities. However, if the problem remains unaddressed, underappreciated engineers will soon become unhappy engineers, which will directly impact their productivity and attrition. This is particularly worrisome in places like Bangalore, India where talent is a crunch.
Actions taken
For starters, when it comes to lack of appreciation, what management thinks is secondary to how engineers feel. Their concerns should be taken seriously, on face value, and acknowledged in full. This was a founding principle that drove all my further actions. To address our engineers’ concerns, we formed the Rewards and Recognition Core Committee. Our first task was to identify what we should be rewarding engineers for and how we would establish the criteria for that. Coming up with titles for rewards or establishing how frequently we would announce them was much easier to do, and we decided to push that for later.
One of the things that stuck with me from the beginning was connecting rewards and recognition with our organizational values. For example, if we valued being customer-first, every time an engineer demonstrated that behavior, we should express our appreciation. We introduced the Thank you award, a peer-to-peer token of appreciation, with no material benefits tied to it. It is a token of sincere gratitude for one’s effort to live organizational values and something that deserved to be acknowledged on a regular basis.
The second-level reward we came up with was the Spot awards. Managers and senior ICs would be able to give the Sport awards to recognize and support any good thing -- whether it is an individual’s behavior or good practice -- that would happen on a team. Next, we came up with the third-level rewards that we announced during monthly Town Halls. We created a number of different awards to recognize a variety of positive actions/conducts/practices: the Albert Einstein award for innovation, the award for team spirit, the award for displaying extraordinary dedication and commitment, etc.
The set of criteria we agreed upon became publicly available, so everyone knew what the organization valued and how one could gain recognition. Managers were encouraged to nominate people from their teams, but we also empowered engineers to nominate their fellow engineers. The core committee soon became rather busy; we would receive an extensive list of nominations we had to filter out and pick a winner. The idea was that we would up the bar every time we give an award, and we were quite successful in our intention. Not only that we made our engineers feel more appreciated, but we managed to raise the bar in terms of promoting values and best practices we cared about.
Lessons learned
- Before introducing any rewards system, take time to think about what you want to achieve with it, especially what you want to reward people for. How your rewards system will look will depend mainly on what your organizational goals and values are.
- Introducing the program is great, but adoption is the key. Most likely, you will not arrive with the most compelling program at once and will have to iterate repeatedly. Use every opportunity to talk about the rewards program's purpose at different forums and see what people think before introducing any change. Introducing such a system is not a one-off thing; it requires repeated evangelization at multiple venues and on numerous occasions.
- Being appreciated and having your hard work being recognized is the most powerful motivator for many people. That recognition is helping them thrive and improve in their work, day in, day out.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
4 January
I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.

Ahsan Habib
VP Software Engineering at human
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
7 December
This is a brief comparison and contrast of Google and Facebook, as a place for one’s software engineering career. Both can be amazingly good places for engineering careers. But both places can be misfits for otherwise excellent engineers. This is a short differential guide. [Originally on LinkedIn]

Michael McNally
Chief Technology Officeer at GraphStax
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
30 November
When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Ramkumar Sundarakalatharan
VP - Engineering at ITILITE Technologies