Change processes are difficult to do. Most of them fail to have the intended results. The reasons for that can be many, of course. There is one, though, that is of particular interest to me today.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.” ― Upton Sinclair
There are many change processes, re-organisations, agile adoptions, etc. that don’t aim for changes in the reward systems. This is only natural: changing what people earn is a very sensitive subject! It almost guarantees a good amount of resistance.
But if you’re in the middle of an agile transition, and line and/or project managers are being rewarded with bonuses for completed projects? Or for reducing ‘idle’ time? And if your change requires longer-term customer relationship, but your sales team is rewarded for new business?
Sometimes it’s enough to simply follow the money.
From the Lean Startup movement, we learn that it makes sense to choose your business metrics wisely. The same is true for the metrics you base your reward system on. But can we use those same Lean Startup principles to alleviate the risk of paying people to resist the change you need?
In a change process, employees are one of your stakeholders. Your customers. Your customers have needs and expectations that you will have to satisfy to allow the acceptance of your change process to grow. So how can you turn this around, and use the rewards program to generate support for your change?
I see two possible situations. One is that the rewards program is mostly in alignment with company goals. This happens mostly when there is some kind of profit-sharing system happening, with the distribution key fairly well fixed and independent of individual contributions. In this case, as long as the metrics for the change process are linked to the main company goals, it’s easy to also relate them to the rewards program. There can still be a challenge connecting those measures to day-to-day activities, but that is shared with our second scenario.
And that second situation is more difficult. If bonuses are awarded based on lower level metrics, then even when the overall health of the company improves with your change process, it can still be detrimental to individual rewards. In those situations it is absolutely crucial to adopt the rewards system in lockstep with the change program.
Stop paying people to resist the change you need
An example:
In a software development environment, say you have a bonus system based on project completion and you go into an agile transformation. As part of the transformation, it becomes less important to deliver projects as a whole. According to the existing definitions, fewer projects are ‘completed’ even if more new features reach your end-users. You will have a situation where your project or line managers are incentivized to push for work that now has lower priority for the company.
So make changes. If at all possible, relate the reward system directly to company results. But don’t wait for your year-end or quarterly figures. figure out how much each user or purchase or site-visit contributes to the overall revenue. Find out how much they cost. And use those kind of figures to calculate a rough indication of bonus/profit sharing figures (x% of revenue goes to the profit-sharing pool?). Those figures can be tracked day-by-day. Or week-by-week. And they can be used to change behaviour, and align interests.
Track rewards related metrics on a day-to-day basis, so they are an incentive to change behaviour
Of course, in most change processes, there will be a transitional period, with some large projects running. You can, for a short while, have these two types of incentives along side each other. Probably. You don’t let your employees take a financial hit because you are in the middle of a change. That could require a little investment, such as a guarantee for the short-term that a certain minimum is kept. But make sure to change as quickly as possible to the fast feedback figures.