Leadership always wants more out of developers but developers are not sales people. When a sales person lands a deal, this has a dollar amount associated with it and therefore a commission. The incentive is clear: more sales or larger sales equals more money. There’s a clear incentive. When a sales person hears, “work more” or “contribute more” they also hear a clear incentive: more reward. Developers have no such incentive. This article is a suggestion for creating incentives for developers which align with your business.
How do you quantify the value a developer brings? When we make one change, all the users of the system benefit from it. How can we value those benefits? Often the only metric comes down to a “move toward” or a “move away” decision from users. Moving towards a product means to either continue using the product or a desire to start using the product often associated with a sense of excitement and pride. Move away means a desire to discontinue the use of the product and encourage others to do the same usually followed by a feeling of disgust.
To complicate matters more, developers are not the captains of the ship. They do not make the calls on the overall product direction. If I had to counted how many times I created a feature that didn’t need to exist I’d, well, not enjoy it. Therefore, counting the number users is a faulty metric.
Leadership across the industry has tried all kinds of metrics to quantify developer value. Lines of code. Commits logged. Peer opinions. Management “feelings.” Hours worked. Tasks completed. Bottom line: they all fall short. People are wired differently. Some work long hours but yield little value while others may work far less but think much more deeply.
It’s really hard to quantify developer value. As an industry we do a terrible job at this and we all know it.
And that’s the problem. Without clear incentives, we get “meets expectation” workers. This is a travesty for software companies. The main money maker, namely, the product, has people doing “meets expectation” work. And the people who are really contributing will not stay since they are not rewarded for their massive contributions. Most of the rewards come from behind closed doors. The process is not at all clear.
Not just developers
Throughout this article I will be referring to developers but this concept is not limited to developers. It can be applied to marketing, creative, and project managers alike.
Introducing a method I call “Above & Beyond” or “A&B” for short. A&B is a process for acknowledging contributions that are above standard expectations. Standard expectations are what make up a salary. A&Bs are what make up the bonuses, equity, promotions, and cash payments.
- Recognition. Whatever incentive system that is implemented should have a clear mechanism for recognizing above average contributions.
- Open communication. Who is doing well, what they’ve done, and what they are earning is all useful information. Knowing how to get ahead empowers people to take those steps and who to listen to.
- Clear rewards. Hidden rewards are only found by accident. A person cannot be motivated by a reward they do not know exists.
- Bi-directional input. Not all ideas seem amazing to leadership at first glance and it can be difficult to know the impact of an idea. Supporting this goal allows for people “on the ground” to make a difference. Also, leadership often has insights into what is important and should have a mechanism to communicate that.
- Preserve normal life. No one can be amazing all the time. Typically, when a person is amazing in one area of life, they are neglecting another area. We all have limited energy. Life’s demands ebb and flow. There should be a place for normal effectiveness.
How A&B works
- Leverage existing task management tools such as Jira and Trello.
- Create a new label in your tool of choice called “Above & Beyond”
- Any developer may create a A&B proposal card. A proposal may be a needed body of work, exceptional idea, or improving effectiveness of a team.
- The developer assigns the weight to the proposal.
- In order for a card to be submitted for executive approval, the developer must find a “peer sponsor.” A peer sponsor is a peer, manager, or leader who says, “I believe in this and I support it.”
- A card may then be submitted for leadership approval.
- Once approved, the developer get a “bounty” or a reward for their contribution. A proposal may be resubmitted by the developer at a different weight if it does not gain approval from leadership.
- Proposal — created by any developer (manager, leadership, etc.)
- Sponsored — a peer who supports the idea or work
- Implemented — proposal has become a reality
- Approved — leadership acknowledges it’s value
Each proposal may have one of the following weights: 100x, 10x, 1x. These weights are used to determine the reward for a given proposal.
- 100x — a total game changer value
- 10x — exponential value, repays the effort many times over
- 1x — needed to be done and/or makes our lives better
To complete the incentive circle, each year, the leadership should:
- Allocate the bounties for each weight by division. It could be equity rewards, cash payouts, promotions, and bonuses.
- Declare the payout frequency. Examples are quarterly, employee anniversaries, annually, etc.
- These bounties should be clearly shared with that division. This creates clear incentives for that division to go Above & Beyond.
Rules & Guidelines
- Only one submission per month. This is to reduce policy abuse and to ensure normal work is being completed.
- Leadership approval may be given retroactively. It can often take time for a company to realize the value of a given A&B.
- A developer cannot submit new A&Bs if they are currently undergoing disciplinary action.
- Leadership may create “A&B warrants” for bodies of work which they wish could be completed but are not critical enough to prioritize. This is a great mechanism for leadership to interact with internal development teams.
- Cards may not be all sponsored by the same person to avoid collaboration abuse. This is also curbed by final leadership approval. Leadership abuse may be curbed by leadership peer reviews.
I’d love to hear your thoughts.