Lessons on Learning LO10254

John Paul Fullerton (jpf@mail.myriad.net)
Sun, 29 Sep 1996 23:19:55 +0000

Replying to LO10242 --

Replying to my own note -- I'm sorry for not making the connection
between the note I responded to and for not making my point evident.

> > IMHO, if you take two 'identical' individuals, connect one to the
> > 'right' relationships [within and outside the org.] and leave the
> > other to flounder, you will soon see a significant difference in
> > actual, measurable work performance.

I wanted to share the following information, so I took the above related
comment as an opportunity. Building on the idea that relationships between
a worker and fellow-employees is important, here is a description of the
relationship needed between a software implementation effort and employees
and management that the technology is for. Though the description is
particularly about software, it seems related to new technology and new
levels of design in business.

I'm adding explanatory comments before quotes from my earlier letter. The
quoted information (in "") is from an article in the August 1996 "Object

The customer has to be introduced to the new functionality and needs to be
the one to choose what functionality will be provided. (The customer may
be the management.)

> "Every organization has a threshold for tolerating improvement. Utopian
> solutions won't fly if the customer doesn't see their value. One of the
> vulnerabilities here arises from the developer's desire to add unrequested
> functionality. With a few lines of code, or the addition of a method or
> two, we implement something and run on to the next idea, leaving the
> customer to figure out what to do with the functionality. Instead, we
> ought to sell the customer on the idea first, then implement it.

The developer's viewpoint and the user's viewpoint build from different

> "Most customers approach a tool or an application as a specific solution
> to a specific need. The customer's understanding of functionality,
> therefore, moves from specific to general; that is, only later in the
> customer's association with a concept or functionality does generalization
> occur. Developers, on the other hand, tend to approach functionality by
> implementing generic capabilities adaptable to numerous, specific
> requirements, and their orientation tends to move from general to
> specific."

Because the need for new technology or new business design is so easy to
question and the understanding of it may yet be in formulation, it is
important to be sure that the customer understands how to use the product
for benefit.

> "Individuals within our customers' organizations have built empires or
> sand-bagged their positions based on how things are currently done. These
> people resist any change until they figure out how to exploit it. As a
> safeguard, we must monitor the degree to which our customers understand
> how to exploit our output."

Knowledge of the benefit that technology brings and the sequence of
observations and experiences that make technology seem necessary are not
common in everyone's thought. Good reasoning may not be using the evidence
for adding technology, so other good reasoning that seeks to add
technology (or design) needs to make evident the necessary data that is
not shared in common.

> Every geographical place has things unique to it (as does every personal
> sequence or continued sequence of thoughts); it would be erroneous to
> expect others to see the advantage that is further along a particular
> sequence of thoughts without bringing them there. It's not a geographical
> place; it's explaining what's going on!

Have a nice day
John Paul Fullerton


"John Paul Fullerton" <jpf@mail.myriad.net>

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>