Have you heard about The Cobra Effect?
It refers to a situation that happened in India during British rule. The British government was seriously concerned about the large number of venomous cobra snakes in Delhi, so the government officials offered a generous bounty for every dead cobra collected.
Initially, this was a very successful strategy as a huge number of cobras were killed for the reward, and the number of snakes in the area started to decrease. But only until some entrepreneurial people realized they could begin to breed cobras for income. Soon a large industry of snake farming sprang into life.
When the government became aware of this, the reward program was scrapped. Naturally, the cobra farmers now had no use for the thousands of poisonous snakes they were raising, so they released them back into the wild.
The result? The number of cobras in Delhi was twice as large as it was before this initiative was launched.
This is what is called Perverse Incentive – an incentive that has an unintended and undesirable result that is contrary to the initial intentions, something that rewards people for making the issue worse.
Short-term, it seems to be a correct incentive, but long-term, it might have the opposite effect, either naturally or people intentionally start gaming the system.
How many such perverse incentives, rewarding the wrong behavior, or metrics, leading to unexpected side-effects, do we have at our workplaces?
Some examples of those might be:
❌ Bonuses for individual performance, team performance or department performance -> it leads to competition between the individuals, teams, or departments and sub-optimization instead of collaboration in the organization
❌ Rushed deadlines and emphasizing the number of features produced -> increased technical debt, which slows down future development
❌ Lines of codes produced -> excessive or redundant code, making the software more complex and harder to maintain.
❌ Number of Bugs found by QAs-> instead of enabling building quality in and true collaboration, QAs and developers start playing in competing teams. Another one is that QA engineers start searching for easy-to-find but trivial bugs, ignoring the more critical problems that take a significant amount of time to understand,
❌ Punishment for mistakes -> The errors get hidden, and there is no place left for psychological safety, experimentation and innovation
❌ Overtime Pay -> working longer hours to earn extra money -> burnout, reduced productivity -> more need to work overtime
❌ Micromanagement -> team members don’t develop autonomy and creativity or lose these skills -> in future, they need even more control and decision-making from the manager’s side
❌ Measure the number of broken builds per developer -> developers committing less often
❌ Make velocity a goal -> intentional overestimations of tasks
❌ Gender or other disadvantaged groups quotas at the workplace, political organizations, or events, such as speakers at conferences -> make the biases even bigger because the presence of such policy raises questions about competence in the eyes of observers (“Did they really deserve that promotion?”) and in their own minds (“Did I get in on my own merit?”) – Adam Grant “Hidden Potential”
What are others?
You might also be interested in:
Coaching in the Workplace
Teams: Diversity or Similarity?
Leave a Reply