Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!glacier!oliveb!hplabs!hplabsc!taylor
From: taylor@hplabsc.UUCP
Newsgroups: mod.comp-soc
Subject: Re: Performance Monitoring
Message-ID: <688@hplabsc.UUCP>
Date: Fri, 26-Sep-86 21:37:00 EDT
Article-I.D.: hplabsc.688
Posted: Fri Sep 26 21:37:00 1986
Date-Received: Sat, 27-Sep-86 20:59:02 EDT
Reply-To: hplabs!ucbvax!chapman@cory.berkeley.edu
Organization: Hewlett-Packard Laboratories
Lines: 48
Approved: taylor@hplabs
Reference: <681@hplabsc.UUCP>

This article is from ucbvax!chapman@cory.berkeley.edu (Brent Chapman)
 and was received on Fri Sep 26 18:36:16 1986

While management misuse of monitor stats could hurt morale, as has already 
been suggested, proper use could also help morale.  How many have been in 
situations where there is a freeloader in your group, unrecognized by 
management?  You know, the person who spends all day reading USENET news, 
(:-) but gets credit right along with the rest of you for your group's 
accomplishments.  Doesn't that hurt the morale of the rest of the group?  
Proper management use of stats could weed out and discourage this type of 
person. 

Even better, the knowledge (or even simply the _belief_) that he is being 
monitored may cause this person to "clean up his act."

Some studies (I believe done by IBM) showed that telling workers they were 
being monitored caused productivity to rise, even if the monitoring was never 
actually implemented, or was quitely dropped.  (Perhaps someone recognizes 
what I'm talking about and can cite the source.)

Monitoring is one thing.  Establishment of quotas is another.  The problem is, 
once you have accurate performance stats, it's hard to resist establishing 
quotas.  Monitoring I have no problem with.  Quotas I very strongly object to.

Monitoring alone could be used to establish a positive reinforcement system: 
If someone performs well relative to their co-workers, that person is rewarded.
Quotas, on the other hand, tend to lead to negative reinforcement systems: If 
someone doesn't meet their quota, they are punished.  

Of course, there is always the problem of _what_ to monitor.  How do you
quantify performance in a given field?  In some fields it's easy: How many 
non-faulty assemblies did this person do?  In others, it's a real pain.  How 
do you quantify, say, a telephone operator's performance? The more calls 
handled, the better?  But doesn't customer satisfaction count for anything?  
What if Operator X is handling more calls than Operator Y, but at the expense 
of courtesy to clients (and therefore future business for the company)?  Does 
that make X a better operator than Y, who handles fewer calls, but whose 
clients are satisfied and inclined to deal with the company again in the 
future? 

Nearer and dearer to our own hearts, how do you quantify programmer
performance?  Number of lines of code?  Number of bytes of source? Number of 
bytes of object?  Object divided by source?  Number of cycles spent running 
his programs?  Amount of revenue his programs generate for the company?  How 
many hours he works?  

Brent Chapman
ucbvax!cory!chapman	or	chapman@cory.berkeley.edu