Sometime during the British India rule, government became concerned about Cobra snakes. It offered bounties for dead cobras. Initially this strategy was successful. But soon creative folks started cultivating cobras for the money.
When Brits realised the problem, they suddenly shutdown the scheme. Lacking incentives, breeders let go of the snakes. This resulted in a much bigger population of the deadly snake.
When an incentive has the opposite of its intended effect, then it’s called a Perverse incentive. Cobra effect is an example of perverse incentive (the design to reduce snake population, increased it instead)
Information Technology
What can we learn from this at IT companies ?
Ever seen a longgggggg running project ?
Sometimes the reason is … rewarding problem-solvers results in promoting the problems.
Technology team is encouraged to work as poorly (cultivate cobras). This because, ones solving the problems later (killing cobras) will be rewarded.
If the incentive is to close a bug or resolve an issue, then there is no incentive to – avoid the problem in the first place.
If incentive is to kill a cobra, then it is also to keep the cobra population alive.
Let’s add another dimension to the discussion.
Solving an issue is a “visible” exercise, whereas avoiding one is an “in-visible” one.
Solving a bug usually requires:
This adds to the person’s performance metrics.
This ensures that the person ‘looks’ busy.
Again a visible exercise.
Brings social status to the person.
All of the above are ‘visible’ tasks. Visible tasks are easy to reward.
Onto avoiding the problem …
The result is invisible.
Most people don’t realise the discussion ever happened. It is invisible.
The number of tickets assigned to him are few to none.
Adding to his invisibility
This adds to the invisibility of the techie’s work.
Notice that most of the avoiding work is ‘invisible’.
We have understood the concept. Let’s talk about how we might use this at IT organisations.
To Techies
Do you work on killing the cobras or avoiding them too ?
Do you choose the invisible task or only the visible one ?
Doing the visible task is easier and rewarding. Doing an invisible task is difficult and NOT always rewarding.
Technology is opaque. Details of any code/ module are very difficult to see through. You know more than your superiors do. (I know it, and you know it)
So, the next time you feel like you’ve found something – telling the right parties is your job. This even when it isn’t part of your defined role.
But why bother ??
Fair question. Lets try this perspective:
Job descriptions mention words like – self driven, ownership, leader etc. The words intend to tell you that part of your salary is for taking ownership.
So, if the Business analyst, QA team, or the Manager are scapegoats, then you do not have ownership. Therefore, you might not deserve your full salary.
Now – Let’s flip the equation.
Want more salary ? Start taking more ownership !
Have an “Inner sense of Captaincy”. Will doing so always help you ?
NO !
I want to be clear about this – invisible work will NOT always be liked or rewarded. You might have a lethargic lead or an idiot manager.
Again, then why bother ?
My question is – are you doing this for the short or long term ?
Even at the risk of being disliked or not being rewarded.
In the Long term, your proactiveness WILL benefit you. Period.
To Corporations
First thing – All teams need people who can kill Cobras i.e. solve problems. Their worth is not to be undermined.
At the same time, NOT needing them is a still better option.
If the focus is on resolving as many bugs as possible, then the focus is NOT on avoiding them in the first place.
When Brits were focussed on killing Cobras, they were NOT focussed on NOT having them in the first place.
If the focus is on going as fast as possible, then the focus is NOT on choosing the right vehicle. You might be running as fast as possible, when a bus might be much more efficient.
It’s worth asking why, if we think something is worth saving, we don’t put more effort into protecting it ahead of time.
FarnamStreet blog
If the number of bugs solved is a performance signal, then the ‘scarcity of bugs’ is also a performance signal.
I am not qualified to speak about incentives. Having said that, I believe that signals should be appreciated but NOT rewarded. If they are, then signalling become the goal, not the work. e.g.
In these cases, incentives will become perverse i.e. have the opposite of the intended effect.
A public acknowledgement or a thanks note might do the trick. But a promotion, increment or bonus will have the opposite effect.
Instead the reward should be associated with the end goal – a signoff, project delivery, handover to support team, completion of the deadline etc. In these cases people focus on “getting the job done”, instead of simply solving more bugs.
Avoid Cobras, don’t just kill them.
Idea conceived and help from: https://fs.blog/2021/02/inner-sense-of-captaincy/
Write back, in case you have an opinion. Like what you read – do like, comment and share.