Managing By Metrics

People who work with me are probably getting sick of hearing my rant on managing by metrics. In a nutshell, I find that technical leaders have a tendency to be anti-social (a trait typical, if not slightly less damaging, in their previous career as developers). The path of least resistance for these anti-social managers¹ is to institute rules to take place of communication². Rather than pairing with a developer for an hour or floating from project to project to get a grasp on capabilities and direction, the antisocial manager prefers metrics dealing with code coverage, defect rates and test failure rates.

I only bring this up now, because I heard an interesting story on NPR that I thought paralleled my problems with managing by metrics. All Things Considered compares the struggles the NBA has had with player pay incentives with those on Wall Street. In both cases, employees were given bonuses for reaching individual goals. In both cases, those individual achievements can have a negative impact on the team as a whole. The individual is encouraged to act in the best interest of themselves over the short term to the determent to the larger organization. In essence, people are making bad decisions, because we pay them extra if they do.

Then later, they wonder why
a) the star of the team breaks a scoring record, but the team doesn't make the playoffs
b) the project has great code coverage, but very fragile code
c) your company did so bad it helped drive the entire economy into the crapper, yet your employees somehow earned $270 million in bonuses.

¹ the phrase anti-social manager should be an oxymoron
² Ironically, this is the exact opposite of the first statement in the Agile Manifesto: Individuals and interactions over processes and tools