At Novell I worked in technical support, first as an engineer and then as
quality manager. During my time as quality manager we defined "quality
support" as follows:
"To provide the customer with a responsive, error-free experience without
wasting company resources."
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.
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). 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).
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.
Another factor absent from our organization were clearly defined values.
This left people confused when they confronted novel or disturbing
situations. Furthermore it left people confused about how they should
actually interact with each other at work. Expectations varied, which led
to constant and energy-sapping conflicts within the department.
Excluding those factors we could measure the performance of both an
individual and a team. The measurements were, on the whole, pretty
accurate. But there were other measurements that engineers took into
account that were never measured:
- How many times does a tech have to ask the same question before he/she
"gets" it?
- How many calls does a tech solve on their own? How much of other
peoples time do they consume?
- How quickly is a tech able to isolate a problem within a complex
system?
- Is a tech able to explain why what they did fixed the problem?
Both these informal measurements (value judgments really) and the formal
measurements combined to create a natural ranking within the department.
There were those who were revered and those who were disdained, and the
categorization pretty much went along the lines of competency and desire.
Management was afraid to make these distinctions, despite the fact that
everyone within the department had already made them. What management
really wanted was not a group of competent people but a group of people
who went with the flow and rarely caused problems. (It could be said that
there was more than one war between the competents and the incompetents;
management had a wonderful ability to side with the incompetents, which
the competents took as a sign of managements incompetence.)
When the lay offs came guess who got the bird and the boot? That's right.
The competents. I called Novell for support today and I talked to a guy
who I went to war with more than once. He didn't understand the problem I
described, and true to form, put me on hold while he went and asked
someone how to solve my problem (I had actually solved the problem, I was
merely calling to report a bug with the software, but, of course, he
wouldn't listen to me long enough to get the message). As I sat on hold
(after waiting an hour and half just to talk to the guy) I remembered so
clearly why I hated that place. . .here this guy was draining others
energy to solve a problem he should have understood instantly, he should
have known how to solve instantly. I was on hold for over 15 minutes
because he was in line to talk to the "expert" who could not take calls
because so many people had to ask him how to solve the problems they
didn't understand and didn't want to know how to solve in the first place.
Tragically, the competents now work for Microsoft or other companies. The
incompetence now have their reign, and the fact of the matter is they're
screwing up. Mediocre performance is now considered "exceptional." The
decline in performance has been attributed to the growing complexity of
the product. I don't buy it. I'm a computer consultant and I support the
same product Novell does and I do it much more proficiently. In my day,
what I experienced today would have been an embarrasment.
How could employee ranking have changed the outcome? Is the current state
of Novell's tech support due to the fact that the competents have left?
Why have they left?
In my view the fact that employees were never ranked, and people were
never called what they were has had a tragic and sobering effect on the
organization and its ability to perform at a reasonable level.
I am open to other views on this scenario but it will take a lot to
convince me that employee ranking couldn't have done something to drive
performance to new levels instead of thrusting it in a constant decline.
-- Benjamin B. Compton bbc_mail@juno.comLearning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>