Basketball, Lean and Incentives

The NBA Finals are going on right now and one of the main story lines surround Kobe Byrant and his supporting cast. The general consensus of the national media is that despite Kobes point production, the Lakers need more from the other people to be able to win.

Sports Economists have long pointed out that NBA players are rewarded for one thing: scoring points.   Often this comes at the expense of everything else around them, including winning.  The thinking goes that if everyone tries to score as many points as possible, their team will win.  A NBA players’ financial rewards, playing time and endorsements are based on very little outside of point totals. Thus, there is a huge incentive for players to shoot as much as the possibly can, regardless of how efficient they are at making those shots.

The problem is that basketballs are scarce resources.  A shot taken by one person cannot be taken by another.  All of those shots can cause havoc to the rest of the team and actually hurt the overall odds of winning.  Missed shots and turnovers increase fast break opportunities for the opponent and give more opportunities for your opponents to score.  Last week, Kobe Bryant missed more shots than he made and had 7 turnovers. Despite that, the prevailing wisdom is that he did all he can to avoid the loss.

So what’s this got to do with Lean? One of the core principles of lean is to optimize the system as a whole and not try to optimize through decomposition. One of the best ways to do that is to get rid of individual based performance rewards and incentives. If you have those types of incentives, you’ll find people working through their tasks with the sole purpose of maximizing whatever it is they’re being measured by and rewarded on. Lines of Code written, bugs found, projects delivered on time, etc… Unfortunately, this has the tendency to create a system with tons of churn:

QA testers are “finding” bugs as quick as they can, without regards to if they actually exist.

Developers churn out more code than necessary just to pump up their LOCs count.

Project managers rush projects into deployment just to increase their numbers.

All of the behaviors just increases the thrashing within a system, which increases the load on every single resource in the system.  Development spends more time looking for bugs that might not exist. Operations spends time trying to get a possibly buggy and non-functioning system to work. QA spends time testing features and code that isn’t needed. The cycle keeps going and going.  Sure, everyone gets their bonuses. Yet the entire team / department suffers.  What’s worse is that no one has an incentive to help out anyone else, since time wasted on you is time that I can’t be working towards my bonus.  It creates a very self-serving culture and isolated team dynamic.

The old adage of “tell me how you measure me and I will tell you how I will behave” still rings true .  Make the choice to measure your team on team based goals.  Place a premium on team communication, collaboration, ownership and overall delivery.   You want people chipping in to help, even when it’s not their particular area.  If you overhear “that’s not my area” or “let operations handle it”, your team priorities are counter productive and likely weighing you down.