I have to be careful in how I answer the question in such a public forum,
because many of you know where I work. While I want to be honest, I don't
necessarily want to reveal everything that is or isn't going on. I have
stock options I'd like to profitably exercise, so I want to say things
that raise the stock price, not lower it. (Take the implication, but don't
count on the specifics.)
The biggest challenge is in helping people to see our organization as a
living entity, not as a machine. The entire measurement system is
completely focused on production: How many incidents were resolved within
5 minutes; how many resolved within an hour; how many resolved within four
hours, etc. This is a very mechanistic approach.
The assumption is that speed is the only thing that counts. The problem is
that people feel so much pressure to "meet their numbers," that they never
take the time to learn. They use time allocated for learning (which, I
don't understand; why do we allocate learning time?) for calling customers
back instead of digging into a problem, and learning something new.
The other assumption (that is not limited to Novell, but pretty much the
entire industry) is that people really don't have very good cognitive
abilities. While this may seem a bit fantastic, look at the way those in
the industry structure the technical knowledge. It follows a format
similar to:
Problem. . .
Possible Cause . . .
Solution . . .
This perpetuates what I have come to call the "Public School Approach to
Learning," which is MEMORIZATION. So our Engineers (and our customers),
get really good at memorizing known Problems/Solution sets. They don't
understand why the problem occurs, only that it does; worse, they don't
understand why the solution solves the problem, only that it does. Of
course this, theoretically, allows an Engineer to process a large number
of calls everyday. As soon as an Engineer encounters a problem that has
never been seen before, they don't even know where to begin to solve the
problem. They'll come and ask somone like me: "What do I do? I don't even
know where to begin?" I used to give them a list of troubleshooting
steps, which they'd try, and if they didn't solve the problem they were
right back at my desk. This really bothered me, so now I help them think
through the problem. They don't like this approach because they think it
slows them down (which it really doesn't), and it forces them to learn
stuff they don't want to know. Now I never get asked questions.
Three years ago I was out performing the people in my department by a 10:1
ratio. When I moved into the back-line support group, I wasn't taking
incidents anymore, and I began working on preventive support measures.
Over those three years we've had our management team replaced twice, and
most of engineers have been with the company less than 2 years, so nobody
remembers the performance level I was able to achieve. Well I've watched
performance drop over these three years, but I didn't have the time to get
involved because management kept me so busy on other projects.
Recently I had the time to write down what I had done to solve so many
problems in a 4 1/2 hour period. It's an easy, six step process:
1- Be committed to your work (and your career)
2- Learn concepts; link concepts; think in concepts
3- Pay attention to the linguistic patterns of the customer
4- Learn through experimentation (be scientific)
5- Learn from more experienced engineers
6- Think in terms of "the whole system," not the "parts."
None of this is real rocket science, but it seems to escape most of the
engineers I've known. I sent a message to the department recently, stating
that I'd like to share this experience with them. People went ballistic;
they felt I was saying I was smarter and more dedicated than they were. So
I started talking to them about their feelings, and what was really going
on was people were afraid that they'd have to increase their performance
by a significant amount (as, given today's measurements, I out performed
them 30:1). In the end, the other managers felt I should back off and not
push the issue. It was causing too many people stress to change the way
they worked. I think what they're really saying is, "A machine can't
think." I'd agree. But we're not a machine. Which brings me right back to
the point I made in the beginning. The biggest hurdle I have to jump is
getting people to think of us as a complex, intelligent, adaptive system.
. .not a machine.
For what it's worth. . .
--Benjamin B. Compton bbcompton@aol.com
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>