Review: Liz Keogh, Learning and Perverse Incentives

Liz Keogh, Learning and Perverse Incentives: The Evil Hat, QCon London 2011

This 50 minute talk discusses perverse incentives: situations where incentivizing individual behavior causes an organization to become dysfunctional.  When we attempt to optimize an organization, but fail to use systems thinking (i.e., when we are optimizing from an internal perspective) we can create inappropriate results.

Different feedback mechanisms drive behavior in both positive and negative ways. Some examples: Reinforcing forces, balancing forces, feed forward, delayed feedback (and the resulting oscillations.) A positive feed-forward example: “Chance favours the prepared mind” (Louis Pasteur). If you prepare yourself properly, good things happen in the future. A negative feed-forward example: over-preparing for avoidance of a negative outcome. If many people worry about limited resources, people can hoard those resources and cause a systemic shortage.  Local optimization caused systemic failure.

We often place a strong emphasis on risk avoidance, but this can kill innovation. Risk is a natural part of any creative process, such as developing software, but some creative attempts will fail. When we take on risk, we learn. If you are in a creative field, you should never take on risk free projects. Some organizations make punishments so great for project failure, and rewards for doing new things successfully so minimal, that innovation stops. One perverse incentive is if someone punishes you for failing to achieve an estimate, you pad your estimates, and then your velocity goes up.  (See Liz’s “Estimation Anti-Patterns” on her blog.) Another perverse incentive: requiring architectural review on after people on a team innovate and fail: too frequent reviews will kill innovation.

When we put on our Evil Hat, we say “How can we game this system?”  That perspective is great for finding perverse incentives.  KPI’s—Key Performance Indicators—are a potential source of gaming and arbitrage (exploiting that true value is different from the KPI). The quicker we’re getting feedback from a metric, probably the further away we are getting from measuring true improvement. People tend to game the system for the metric, not the improvement, especially when KPIs are rewarded.

Your brain is brighter than you are. You will game the system even if you think you aren’t consciously wearing the Evil Hat. Rarely do people game the system deliberately, but there are some situations, particularly with middle managers, where people deliberately game the system for their personal benefit. (See Snakes in Suits below.)

How to improve:  Get away from solving a problem, and create a system where problems are solved. Evangelize and embrace frequent Root Cause Analysis, with 5 whys, to get to root causes. Keep metrics close to the improvement you are trying to measure (see The Goal below.)  Create a learning environment. Even in standups, “This is what I learned today; This is what I hope to learn tomorrow; Can anyone help me find out… ?” could be useful.  Fit the process to reality, not reality to the process.  Try focusing on what’s going right as well as what is going wrong. Then we focus on learning: what should improve, what should we keep? Thank people for doing a good job, and think “How can I anchor good work?”

Book List:

• Peter Senge, The Fifth Discipline: The Art & Practice of the Learning Organization
• Tom DeMarco and Timothy Lister, Waltzing With Bears: Managing Risk on Software Projects
• Donald Reinertsen, Managing the Design Factory
• Edward de Bono, Six Thinking Hats
• Paul Babiak and Robert D. Hare, Snakes in Suits: When Psychopaths go to Work
• Eliyahu M. Goldratt and Jeff Cox, The Goal