Incentivize – Carefully

During 1930s there was British Raj in India.
At that time, in one of the villages of India, the British government was facing lot of difficulties with the increasing population of venomous snakes.
In order to deal with the situation the Britishers called the villagers and told that whoever can bring a dead snake will be rewarded.
The villagers dutifully  started to bring the dead snakes to the British Raj and were getting rewarded.

The surprising fact was over the period of time the population of the snake increased

It defeated the purpose of the whole activity which was tried with an intention of reducing the snake population.
When looked deeper into the situation it was found that the reason for the increase in snake population was that the villagers started to breed snakes and kill it and bring it to the British Raj in order to get the incentive.

So it was around 1930s.

Let’s fly through the time and come straight to 2016 when Wells Fargo was fined for $185 million dollars for opening fraudulent accounts.

The purpose of the exercise which led to this penalization was that Wells Fargo wanted to have better customer satisfaction and increased usage of their products by increasing the customer base.
What was one of the easiest measure to indicate that?

The number of new accounts opened. The more the number of accounts, the better customer satisfaction.  At least that is what the management of Wells Fargo used to think. The initiative was at first successful but when Wells Fargo ran out of actual customers to open new accounts, the employees started to create fake customers and got rewarded by the company for it until the malpractice was finally revealed to public

Now we come to one of my personal experience around 2018

I was asked by one the manager to look into a team where the developers of a team were extremely good in the all the parameters they were measured. However the product they were working on was always a crap. When I looked into various details some interesting facts came to my attention.

I found that the developers were measured in terms of

• Number of lines of code they are writing
• Number of git contributions made
• Number of bugs found and fixed and
• Number of Technical debt addressed.

The manager used to take the data from various tools like that of GITLab, Sonarqube and others in order to be accurate in the measurements.

While initially it was all fine, eventually the developers started to understand the co-relation between these parameters on which they were measured and their bonuses.
Eventually, they landed up on the hamster wheel of producing more and more junk code to increase the lines of code , git contributions and while identifying and fixing the bugs they introduced some more junk code and bugs which were minor but good enough to be counted as bugs in order to ensure their bonuses which were linked to these parameters.

After this discovery, It took us a lot of time, effort and lot of experiments to bring back the intended culture and behavior in the team.

So now we time travelled from 1930s >> 2016 >> 2018 and I am sure similar issues are still happening somewhere in the world right now as we are reading this in 2020 also.

I would like to highlight the lessons learnt from all these examples  so that we all can keep a mental note whenever we are back to our work about these kind of situations

So Lessons learnt

• Focus should be on the system outcome instead of individual behaviors. Otherwise we might end up in unintended consequences

• We should not only measure the activities or behaviors or metrics that are easy to measure. We should always try to measure what matters. Like in case of Wells Fargo instead of measuring the number of accounts opened, may be we could have measured number of new customers or number of happy customers  or something else which would give us a measurement of what actually mattered.

• Whenever we are measuring something the purpose of the same should be clearly communicated. May be here we can try using Simon Sinek’s Start with Why. Once the why is clearly defined and communicated for an activity we will have more clarity on how we should work

• We should always have experimental mindset and try to validate our assumptions at every step before its too late. When we run an experiment we have faster feedback loops which lower the risk of things going completely sideways

• And finally I come to an end by saying we should incentivize carefully. Using carrot and stick approach often lead to the trap which we intended to avoid in the first place.

And last but not the least Dilbert Cartoon strip to enlighten our mood 🙂

Using carrot and stick approach often lead to the trap which we intended to avoid in the first place.