Employee Metrics

Business took a page from the manufacturing book with an adage from Edward Deming, “you can’t manage what you don’t measure”. Unfortunately, the quality guru never said it - because many important parts of your business can’t be gauged well. This applies most to employees.

Humans are much trickier to measure than rubber boots for submarine telecommunication cables. People game the metrics to look good.

Look at software. Programming managers like to measure software bug counts and lines of code. Coders naturally respond to bug counts by arguing with the testers about bugs instead of fixing them - or even avoid the bug tracking system. If you measure lines of code written, developers will tend to write bloated, unmaintainable code. Either criteria will cause worse performance.

Yesterday I asked you to tell me about the worst person on your team, who would it be... and why?

and I got the following responses :

• Don't care about the quality of their work. This shows in both personal attitude and in code quality (such as a lack of software testing). "The worst programmers tend to not buy into the project emotionally, intellectually and professionally," wrote one computer consultant. "They tend to show up, do the bare minimum to get by, and then leave." Their lack of engagement usually hurts the project, he says, in big ways (such as misses in requirements) and subtle ones, too. Or, as another described concisely, "The one who makes most money out of least work."
  
  
• Cost the team in time and frustration. One Java developer explained, "A bad programmer is someone who, simply by working, creates more work for the others on his team. When he codes something, he breaks other things, such that just because he did his job, the jobs of others become harder."
  
  Bad developers create buggy code that needs to be reworked, reducing the team's ability to Get The Job Done. "This should be obvious from change logs and QA reports," pointed out one respondent—one of the few places where "metrics" enters into the equation.

From the business viewpoint, what matters is the end result: the quality of the software. "Code speaks louder than words," wrote one person. But many managers can't differentiate between good and bad programmers and, he added, "They can't distinguish good software design from bad one[s] either."

•  Have a poor sense of timeliness. Software project estimation can be a black art, but a developer who cannot grasp a timeline or meet a non-arbitrary deadline is a big problem.
  
  
• Do not offer or ask for help. Wrote one project manager, "I expect developers to seek help when they need it, to collaborate with others, and to raise any concerns and/or opportunities for improvement to their manager." Team players learn from others and teach others, and that shows in their mutual appreciation for one another.
  
  
• Are arrogant. I'm hesitant to use that term, because a true expert's self-confidence can easily be mistaken as "Who the heck does she think he is?", but several people pointed out that the worst programmer often has a superiority complex. Wrote one software engineer, that individual knows he is always right and knows everything even (or especially) if he is just out of school. "Argues with everyone including software architect. Makes every meeting painful and long. Sneaks in unapproved tools/software/programming languages/databases."
  
  Personally, I'd refine the sentiment to stress that the "arrogant" label is heavily tied to the previous "unwilling[ness] to learn from others."
  
  
• They ask the wrong questions— The worst programmer on a team is the one who spends his/her time trying to identify the worst programmer on the team. (And that's the worst manager, too.)"

One thing that's clear to me (and should reassure some readers) is that the "worst" developer on a team is not necessarily the least experienced. Someone who knows his strengths and is actively trying to address his weaknesses is often appreciated for the former and cheerfully mentored for the latter. Savvy managers enable the process because, the team is good or bad together.

Expect similar fun in banking:

• Measure number of incoming customer calls handled? The call center will cut the customer short.
  
  
• Pay branch managers according to deposit growth? They’ll push harder for unprofitable rate exceptions.
  
  
• Pay tellers on customer satisfaction? They’ll waive fees too easily.

Employees are a little like subatomic particles - the very act of measurement will change them. Even if the yardstick is not explicitly linked to pay, people know that you are measuring because it’s important.

So what’s left?

• Make the measurements ungameable: combine multiple measures together to make sure there’s no way to adversely affect the numbers. For example, profits measured with funds transfer pricing are much less vulnerable to bad rate exceptions than deposit growth. Or just stop using rate exceptions completely. Note: Fair Isaac’s James Taylor rightly points out that decision automation has side benefits of reducing gamesmanship while focusing employees on the customer.
  
  
• Allow your employees to skew their outlook: it may not be a bad thing if tellers are solely focused on the customer - even if this drops fee income a little.
  
  
• Manage subjectively: Throw out the worst metrics and replace them with good judgment.
  
  
• Inspire your employees: Most people want to do the right thing. Make sure everyone understands how important banking is to the rest of society - a world without mortgages or savings accounts puts people in worse homes and keeps money hidden under the mattress. Explain how better customer service lets someone’s grandmother relax a little when worrying about money; higher profits allow the bank to help more people. Listen to their own ideas for how to improve.

What did I miss? If I asked you to tell me about the worst person on your team, who would it be... and why?