Knowledge in a Flash . . . Cube
(download zipped Word 6.0 version)

Rick Dove, Paradigm Shift International, www.parshift.com,

"I need a fish to eat", the poor man said, "please tell me how to get one."
   "Take this hook and line", replied the fisherman, "put a worm on the hook, go to the dock there, drop it in the water, and soon you'll catch a fish."
   Ten minutes later the man was back with thanks for the fisherman and a fish for dinner. He did as he was told every evening that week until Sunday, when, after two hours, he gave up and went home empty handed. After some time on Monday and no fish he came back to ask the fisherman what was wrong.
   "Simple", the fisherman said, "the weather has changed and the fish are now biting under the bridge. And it is a bigger fish this time so you'll need a heavier line, a larger hook, and a small fish as bait."
   Ten minutes later he had his fish for dinner. Doing as he was told he was successful every night that week, and on Friday he thanked the fisherman for teaching him how to fish.
   "You know how to fish last week and you know how to fish this week" the fisherman said, "But next week you will not know how to fish."
   Any good fisherman will tell you that he is still learning how to fish; but lifelong learning is not our point. Our point is that a straightforward procedure is not knowledge; at best it is simply information. You have knowledge when you can use fundamental skills creatively under novel conditions.

You have knowledge when you can use
fundamental skills creatively under novel conditions.

In our last essay here (#49, Jan. '99) we described a packaging concept for transferring knowledge, not mere information, at high speed within an organization - packaging that knowledge plug-compatibly with what people already knew. We described a packaging format and rationale which we depict here in both abstract and actual graphic representations.
   Here we will take a deeper look inside our "flash cube" at the nature of the packaged knowledge - and see that it is structured to help provide an insight into a whole class of problems and not merely today's fish.
   Last time we talked about creating a generic metaphor that makes explicit the tacit knowledge which everybody understands about something they respect as functioning well. We call this a local metaphor because the knowledge is local to the people we are interested in. After we package the local metaphor in our flash cube pattern, and help everyone become comfortable with this representation, we then introduce all new knowledge in the same packaging pattern.
   Basically the local metaphor provides everyone with a template of language and culture for describing problems and their related solutions.
   The reason this works is because the packaging pattern is not simply syntactic (conveying location: describe the problem in the upper left corner, describe the solution in the upper right corner, etc); but rather a semantic (conveying meaning) framework that tells us to describe the problem in terms of the nature of change it must address, and to describe the solution in terms of its relationship to a specific Reusable-Reconfigurable-Scalable change-proficient architecture. Thus, we install in every person a common knowledge pattern that can be overlaid with specific information about virtually any business practice, production process, product design, procedure, or other knowledge of interest.
   To be sure there is a lot of information unique in each new piece of knowledge to be dealt with; but in each case it is cast in a very familiar pattern. The person attempting to understand the knowledge will know exactly where to find the answers to a common and familiar set of questions. No, the same depth of understanding that comes after practice and experience is not conveyed in the abstract package; but the information and conceptual framework necessary to guide practice and employment is all there.
A local metaphor in a specific industrial setting might focus on a manufacturing process or other business practice that everyone in the organization respects for its ability to work well under all manner of changing conditions - such as the accompanying diagram of a Just-In-Time assembly line. But local metaphors don't have to be about something in the work environment - they just have to be about something everyone respects in common for its ability to accommodate changing conditions.
See essays 33 (Aug 97) & 35 (Oct 97) for fine print
Most of you may not be fisherman, but probably have some idea what fishing is about, and probably even know a fisherman or two who's competency you respect. With this as a respected process we all have in common, we could use it to package a local metaphor.
   One requirement of a good local metaphor is that a lot of explicit detail not be required in order for the important concepts to be understandable.
   The first thing we need to do is to describe our problem in terms of the types of change it must deal with effectively - the structured problem definition. If we focus our interests on fresh water fishing the proactive change requirements might include, most importantly, changing our empty hand to one with a fish in it; and then improving the time it takes to get a fish and the predictability of success. Eventually we'd like to migrate toward some simple salt water fishing; but for sure we want to expand out fresh water capability to most all fish types; to handle shore, dock, and boat fishing; and to handle lake, river, and stream fishing. On the reactive side, we'll need to deal with broken tackle, a variety of different fish types at any moment, and variations in weather conditions. If we should be so fortunate to find a school of fish or a feeding frenzy, we want to be prepared to take advantage of that and not be capacity limited below what the regulations allow. And of course, we'll want to be able to reconfigure our tackle and our bait to match changing or unexpected conditions. With these requirements met we should be able to enjoy a wide range of fishing experience. If you find something missing here, perhaps it is because you wish a different experience than I, or perhaps we should have collaborated on the development of this problem definition. In any event, the structure in this definition came from our attention to eight different types of change.
   Now on to the structured solution framework. The strategic themes we'd like to achieve in our fishing experience are simple: catch it quick, and catch consistently. The principle activities we will employ include configuring tackle, choosing bait, choosing location, choosing time, and choosing style.
   Our solution resources will be represented as a pictorial icon pool for things you might find in the tackle box with its many divided compartments, such as a variety of hooks, sinkers, artificial baits, and floats; along with a variety of live bait as the occasion suggests. And of course some different weights of fishing line for different fish sizes, weights and orneriness; and a few different rods with interchangeable reels.
   The application story will be a short two-pages that describes a few typical resource configurations to a few different fishing conditions, making the point by example that we have highly reconfigurable resources that are assembled to take advantage of whatever conditions prevail at the moment, and that experience and experiment teaches us how to improve our configurations.
   Next we'll draw some pictures of two or so collections of the resource icons assembled into typical "fishing systems" that parallel examples in the story. And while we're at it, we'll briefly state who is responsible for assembling and reconfiguring these systems, and for maintaining the pool of reusable resources. In this case these responsibilities all fall to the fisherman.
   Finally, we will structure our story points into each of the ten RRS principles in action (Oct 97), showing how the application of these principles contributed to the adaptable capabilities we required in our problem definition. We have a simple intuitive example here that will not require any further structural detail.
   We'll that's my fish story for the day.

©1999 RKDove - Attributed Copies Permitted
Essay #050 - Published 2/99 in Automotive Manufacturing & Production as Fishing for Knowledge,
Gardner Publications
Would you like to offer some thoughts or add to the dialog? Your sending of a comment automatically grants us permission to edit and post at our discretion. Send your comment to
========= Reply =========================
From: paul@jpcripwell.com  (Paul Cripwell) Date: Tue, 16 Feb 1999
I read this paper and some other things on your website and found them basically interesting but they all seemed to be centred on one very important concept: It is possible to proceduralize the transfer of information to knowledge as well as their application. I have found this concept throughout many articles on both Knowledge Management and Information Engineering and find it almost impossible to believe that this can be turned into any kind of turnkey system. If you had read recent articles from HIS HIGHNESS (ugh!) Bill Gates this is exactly what Microshaft is trying to do; create a software package that does everything for you. One of my strongest arguments against the procedural concept is: Every one is entitle to thier own opinion and in many cases competing views can both be correct. This would not be tenable in current software or even advanced AI. There are some additional thoughts on my website and you might be interested in the Information Overload and What is Information pages. Cheers, Paul

========= Reply =========================
From: (Rick Dove) Date: Wed, 17 Feb 1999
Thanks for your comments, Paul. Many of the essays on this site, as well as the RealSearch paper, make the point, and reference supporting learning theory, that different people learn differently, and that what you're prepared to learn (transfer into knowledge) has a lot to do with what you already know. There in fact are many "procedures" for transferring information to knowledge - the apprenticeship process is one of these, "action learning" is another. For some, reading with active empathy is an effective procedure. All such procedures don't work equally well with all people; but in each case learning theory generally attributes the success to the new knowledge being sufficiently similar to existing knowledge. Our packaging exploration in the current essay series is attempting to explain the workings and nature of one particular generalized knowledge metaphor that can and does ease the transfer of a certain but large class of information into knowledge for many people. In Seymour Papert's excellent book "Mindstorms" you'll find a wonderful and personal example of this in his forward; which he credits for motivating his work on LOGO, another attempt at providing a generalized metaphor to ease the assimilation of a large body of new knowledge.

Another body of knowledge you might find informative about process and procedure for information transfer into knowledge can be found in situation theory. A web search on this phrase will turn up quite a bit.

I agree that Information Technology vendors too often exaggerate the support that technology can provide in the areas of knowledge management and knowledge capture. The domain of knowledge is the brain, not the disk drive. Nevertheless, IT does have valuable support to offer, not only in libraries and catalogs, but especially in collaborative connection and infrastructure.

People come in many thinking and learning varieties. One quick cut is known popularly as the left and right brain dominance differences - logical vs gestalt, detailed vs holistic, bottom up vs top down, sequential vs parallel. I have found over the years that presenting a gestalt picture to a dominantly logical thinker fails to transfer any knowledge, just as a procedural view generally fails with gestalt dominant thinkers. My experience leads me to feel that most of the people I try to communicate with in operational business environments are in the logic dominant area - probably because their promotion to positions of management have been facilitated by their generally more effective communications capability. In any event, these minds prefer a procedural view point of what to do and why, rather than an equally valid mind map of contradictory and broader information. Thus, since I hope to have an effect on decision makers of all kinds, I find it necessary to develop procedural tools - on occasion I liken this to dressing up a sheep in wolf's clothing.

Even the Zen master employs procedures.

========= Reply =========================

Home | Library
 Send mail to with questions or comments about this web site.
© 1994-2005 Paradigm Shift International - Attributed Copies Permitted
Last modified: April 25, 2005