Once more, into the breach...
People are not sheep, Ben. They don't need to be driven.
While I appreciate your apparent frustration with prior experiences which,
in your mind and point of view, lead you to your own inferences, there are
three words which, IMV, sum up the problems which you, and Novell, may
have been facing:
SYSTEMS DRIVE BEHAVIORS.
Regarding your days as quality manager, there were three identifiable
areas which were part of one overall purpose, in providing customer
support:
1. responsiveness
2. freedom from all errors
3. "wasting" no resources
Such metrics as were used to meet each standard were each subject to
process and system failures, and demanded operational definitions which
may have not been sufficient, or may have themselves produced unwanted,
unexpected outcomes. Simply saying that "x is a proof of y" is not
sufficient.
> By error-free we meant that when a customer called with a technical
> problem we solved the problem. By responsive we meant that we got to the
> customer quickly. . .we didn't want them to sit on the phone for an hour
> waiting to talk to a support tech.
How did Novell get to know what "error-free" solutions meant? How did
Novell provide for responsiveness-capability? And, what did Novell do with
the "wasting resources" information, assuming that there was some
available. How was that defined, by whom, and to whom?
Ben also states:
> This definition allowed us to create a number of measurements against
> which we could measure both individual and team performance (both were
> important to us; individual performance was an indicator of a persons
> passion and their ability; team performance was an indicator of the
> ability and passion of their team leader as well as an indication of how
> well the team was functioning as a whole).
And, of course:
>The standard measurements were:
>
> 1- Number of calls resolved within five minutes
> 2- Number of calls resolved within one half hour
> 3- Number of calls resolved within one hour
> 4- Number of calls resolved within four hours
> 5- Number of calls resolved within 24 hours
>
> These measurements drove the performance of the organization (114 people).
Indeed, such measurements, and those which were not measured, certainly
did drive the "performance" of the members.
Though stubbornly resisted by many managers, there has been sufficient
study as to the application of variation to the activities of the "real"
world. Such performance metrics are meaningless if they are not seen in
the context of system variation, but they are still assumed, wrongly, to
be adequate to make such statements and draw such conclusions as "proving"
the "passion" level of the participants. Sheer drivel, but it has been
used elsewhere, where the emphasis was on "eye-balling" the data, such as
it was, and then drawing conclusions.
It certainly seemed that the atmosphere in Novell was unhealthy, and
probably disfunctional, as Ben indicates. It is no wonder those inside
were intent on fighting battles, or wars, and continued to do so even
after they left the company. Remember the Pygmalion effect, and how we
deal with expectations.
I think it is a sad thing, but a useful thing nonetheless, to have such
"insider" information put on the table for discussion. In the context of
learning organizations, Novell appeared to be ignorant. Whether they still
are is unknown. But if they continue to utilize such methods and
practices, they are doomed to repeat the past unhappiness.
On the other side of the coin, Ben provides adequate information on just
why the metrics were of little use. Ben states that:
> They also excluded a number of critical factors that had a bearing on the
> quality of our support. For instance we never measured the accuracy of the
> answer, nor did we verify if the answer actually solved the problem. We
> didn't measure how many times a customer had to call us to get their
> problem solved. These are critical measurements,and their absence had a
> profound and tragic effect on the organization.
I would suggest that even if the information was provided it would not be
proof of passion or even competence, but rather might be proof of lack of
resources and training, among other things.
Systems DO drive behaviors, and sometimes they can drive people crazy.
Think about it. Is this an indication of a "learning organization"? What
did they (at Novell) learn? And those who left?
Some years ago Canada Bell did research on their telephone operators in
much the same way as did Ben's scenario; they found that their system was
making it impossible to achieve the very results demanded of the
operators. (Similar to the passion-requirement...) So much emphasis on
the clock was impeding the service to the customer, and the effect was to
"brand" or "rank" the operators much as other companies have done, to no
avail. It did not produce better employees, better service, but rathr more
frustration, more bitterness, more anxiety, more stress...which then
produced...........etc. Round and round, and finally someone asked why.
When they finished, they eliminated the system, amended their process and
procedures, emphasized the customer and the need for "operator-support"
such as better training, better working conditions, and so on.
Ben provides a good example, but a sad one, with bad results. This was not
unexpected, it seems.
So much depends on the thinking process of management, and so much results
from the system impacting on that thinking.
-- Sincerely,John Constantine Rainbird Management Consulting PO Box 23554 Santa Fe, NM 87502-3554 Rainbird@Trail.Com http://www.trail.com/~rainbird
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>