He talks about learning to identify early signals of change, and how, from
those signals, an organization can change it's internal structures to
match the new, emerging environment. Without question I think that's an
important element of longevity.
The question, however, is at what level in the organization does such
learning occur? At this point I must state that what I have to say from
here on out is based on my experience in a high tech company, as an
employee not as a manager. My conclusions, therefore, are, I'm afraid,
short-sighted. But hopefully they will spark deeper conversation that will
round them out.
In my experience the employees were far more sensitivty to the signals of
change than were the managers, especially the line managers. I could give
example after example, but I'll settle for just two:
A number of years ago a couple of us were having breakfast. One guy said,
"You know, on my way home last night I was thinking. What if the number of
customers grew at the rate the company expects. How many support engineers
will it take to support our product in the year 2000?" That was a question
no one had ever asked. A few minutes later we figured we would have to
employee 200,000 (or there about) technical support engineers to maintain
the same support engineer to customer ratio. That clearly was not a
possibility. "So," we asked, "what are we going to do about it?"
No managers were present. Four our five employees sitting at a breakfast
table having casual conversation.
I said, "you know, if we we've got to be spending a lot of time answering
the same question over and over every day. Why can't we answer the
question once, document the answer, and make it publicly available through
E-Mail and FAX." (The web was still in it's infancy at that time.) The
next question came, "Yea, that's a great idea. But how would we know what
to publish?" A bunch of conversation took place, and we concluded, "We
need to monitor the type of problems people are calling about. Find the
recursive problems, document the solution, and make it available. Then,
when a customer calls and describes that problem, we can just FAX them the
document. It'll reduce our queue times, satisfy the customer, and allow
many customers to be serviced by a single problem report." We looked
around at each other. We had kind of done that type of thing in the past,
but not at the level we were talking about. We decided to call it
"document-centered support." We now had a new way of talking about our
business. Our language began to evolve, which, in turn, opened up new
possibilties.
The next question was, "How do we change the way we work to accomodate
this new approach?" We talked about it for days. Again, no mgmt. was
involved. A group of us agreed on a method, and we set out to change our
internal structures to accomodate our new model. After we had documented
our idea, we took it to management.
"Well," said management, "we just don't have the resources to do that. You
want to reduce the amount of time people spend on the phone, and that's
just not possible. We need to keep people on the phone as long as possible
so we can service all of our customers." Mmm. . ."Yea," we said, "but if
you move to the document-centered support then the queue times will
decrease, and you can actually service more customers in the same amount
of time." Nope. They wouldn't buy it. So we went back to talking among
ourselves. Over the next week or so we decided to call it the "one to many
support model," implying that one support engineer could literally service
thousands of customers at the same time.
We went back to management. They agreed to let us try. And so we did. The
result? We reduced the number of incoming support calls by 40%, which
allowed us to keep the same number of technical support engineers while
servicing a broader customer base. At that time there were 1 million
customers; no there's nearly 10 million. And there are actually 20 fewer
technical support engineers in the department.
(To be fair, there are still many problems with the support model. One of
the most trecherous is that the department often publishes inaccurate
technical information. This has the tendency of increasing support calls.
That was the problem we were working on when they laid us off.)
Well that took longer to explain than I wanted, so I'll not explain the
second example. But I think my point is made: Learning occurs naturally,
at all levels in the organization. And, in the Information Age, there's a
chance -- I don't know how high of a chance -- that the front-line
employees will be more sensitive to the signals of change than will mgmt,
and that, as a result, they will more quickly change their internal
structures to accomodate the environmental changes.
Networks and E-Mail systems, I believe, only increase the chances that
such behavior will emerge as a hallmark attribute of the Information Age.
The power, influence, and importance of management, may, therefore,
continue to decline as we move further into the new era.
I would like to see more material written on learning within the
low-levels of an organization, and how that learning can actually
influence management decisions.
For what it's worth.
-- Benjamin B. Compton bcompton@enol.comLearning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>