Mike McMaster wrote:
> Have you included the possibility of saving redundant and even apparently
> useless information for its later value in recombination?
> One of the more recent Nobel prizes went to the scientist who discovered
> many years ago the apparently random sequences in DNA strings - but only
> recently was the significance of these random strings apparent.
> John Holland in his work on complexity and innovation makes the point that
> we should keep old ineffective rules (even bits of them) around and use
> them from time to time just to see if they add to the current mix. Just
> because they weren't of top functionality in some other environment
> doesn't mean they won't be now.
As far as I know the division I work with has not considered this one way
or another. But I have not idea what upper-management is thinking.
I see benefit in doing this, but I also see some danger as well. Excuse
the long examples, but I think they're quite pertinent.
In 1991 or 1992 the SWAT group -- then part of WordPerfect -- was asked to
create educational material and certification tests for our messaging
product, then known as Office. WordPerfect was attempting to emulate
Novell's education program, which was the foundation for their large
distribution network of resellers and integrators.
One of the issues that we needed to document was how many people could be
in a single Post Office (a logical grouping of users, serviced by a single
server process). We did some benchmarks and came up with a maximum of 250
users. There were a number of factors that lead to this conclusion: First
was the fact that our server process was a 16-bit MS-DOS application, and
we simply didn't have the horsepower to handle more users. Second, the
architecture was still young and making it difficult to effectively put
more than 250 users in a Post Office.
This was a rule of thumb that caught on quickly. Pretty soon it started
appearing in marketing publications, white papers, and press releases.
Four or five years later this rule of thumb is still used throughout
Novell, despite the fact that we now have 32-bit servers, and native
access to the NetWare Filesystem, allowing us to include thousands of
users in s Post Office.
In my design methodology I tried to kill this rule of thumb and replace
with the following: The number of users allowed in a PO is determined by
the amount of free disk space on the server. Expect each user to take
between 10 - 15 MB. This has never stuck, despite the fact that I've
shared the rule with a lot of people. (I think the problem is that it
requires math -- very simple math -- and its much easier to say 250 users
per Post Office.
Last June I was presenting my design methodology at a Novell sponsored
conference, and the guy who designed our corporate E-Mail system was in
the class. When I put up the new rule of thumb he took issue with me,
despite the fact that customers were in the room. I stood my ground, and
explained my reasoning. He was acting on old information -- created by me
and four other people four years ago -- and was totally oblivious as to
where that knowledge had come from or why it was the rational.
The 250 users per Post Office is a meme that has been good at replicating
and surviving. I just wish it would evolve!
Second point, three years ago I started talking about "solutions support,"
which I felt would emerge within five years. I kept talking to my
directors and vice presidents about the idea, explaining that in the
future people wouldn't simply want help with a specific technical problem,
but rather help in designing their entire system. They would want a
solution to their business problems or issues. I began to talk about how
we could bring this about, and actually intensify our leadership position
in the marketplace. I got a lot of really nice smiles and even a few nods
but not much more. We did some experiments with this idea in the SWAT team
and found phenomenal results. We were actually able to see, on average, a
decrease of 58% in the number of technical support calls by those
companies we experimented with. The experiment was discontinued because it
was giving "more service than the customer had paid for." Ironically, it
was actually cheaper for us to provide service this way.
Two or three vice-presidents later, I'm told we're going to reorganize our
regional support center. The reason? We need to provide "solutions
support." I recently had a meeting with my VP where he explained the
re-organization. I told him we had done this before, and found it to be
quite effective. He looked at me with dismay, as if to say, "You mean,
this isn't an original idea?"
In one sense, the old information -- even useless -- is still used. It
won't die or evolve. It just keeps replicating, surviving, and annoying
the hell out of me. And in the other instance, it is a case of an
organization who is not open to new information that is not discovered at
the top -- even though the results were clear and undeniable.
And I'm tired, so I'm going to go to bed.
--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/>