Bryan Siever asks:
>Is it possible, and/or prudent, to blend employee development and employee
>performance into a singular process?
Bryan, this is a very difficult question and you may get differing advice.
I'm not even sure what you mean to include in "employee performance" but
I'll assume you include performance evaluation and improvement. If not,
stop reading now! ;-)
For many years, every rational bone in my body wanted to believe that not
only was it possible to blend employee development and employee
performance, it was the only sensible thing to do. After all, feedback
has been shown to be one of the most critical factors influencing
performance (often, THE most critical) and, so said my rational bones,
isn't good performance evaluation just feedback?
Unfortunately, there are practical flaws in this reasoning. I like your
use of "prudent" in the question. What goes wrong when blending schemes
for employee performance improvement/measurement with plans for employee
development has little to do with theory/rationality/clever
design/intentions and has everything to do with the practicality of
implementing any such plan. And things do go wrong! Here are some of the
things that imprudently fail:
1. The feedback required to help employees improve their performance must
be given much too frequently to be used as part of performance appraisal.
That's in part because performance measurement has legal and monetary
implications (in almost every case) and, therefore, must meet some very
high standards for accuracy, fairness, etc., etc. This makes the process
of doing it quite expensive -- too expensive (in time and money) to do
every week or two!
2. When the person being measured must participate in the measurement
process (as many performance measurement schemes require -- because it
enhances the power of the information as feedback, for one thing; or
because there's no other way to get the information other than directly
from the employee, for another), it makes a difference whether it is
perceived that the information will be used "against" the person or not.
Most performance appraisal processes create the perception, no matter how
they're designed and explained, that the information may potentially
damage the person's chances for promotion, for getting a raise or bonus,
etc. This causes two negative side effects:
a. The information gets distorted (to paint as good a picture as
possible.)
b. It gets more expensive to collect the information because the
collection process has to be made as "tamper proof" as possible. [This
expense then relates to the first point, above.]
3. When any system has what is perceived to be conflicting purposes,
there will be problems. Performance improvement is usually perceived to
be done for the best interests of the company; employee development for
the best interests of the employee. This "mixed purpose" cannot be
prudently combined in a single scheme -- no matter what the "real"
intentions of you or your company may be, and no matter how well designed
the plan is, and no matter how much rational sense it makes to combine the
two. Many employees react to such mixed-purpose programs with suspicion,
even in the most positive corporate cultures. [I know, I know -- they
"shouldn't" ... but they do.]
4. Your role, even with the best of intentions, will be misunderstood if
you are seen to be the supporter/designer/provider/or just implementer of
a mixed-purpose system. Your co-workers are likely to view you with the
same suspicion that they view the system you are seen to be purveying.
This can interfere with your ability to work successfully with them.
As an outside consultant, I reluctantly had to give up my beautifully
designed combination systems (that took "the fear out of performance
appraisal") and have just had to accept the prudence of permitting
companies to run two separate systems -- one for employee development and
another for employee performance.
There is one person's sad experience, for what it's worth.
Maybe the lesson is simple: Systems that have different purposes/goals
are different systems and should be designed independently.
--"John Gunkler" <jgunkler@sprintmail.com>
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>