Consultants & "complexity stuff" LO11017

Michael Erickson (sysengr@atc.boeing.com)
Fri, 15 Nov 1996 14:55:07 -0800 (PST)

Replying to LO10987 --

Hello all.
This discussion about how self organization might work with humans is
something I've given a lot of thought to.

In all this discussion it seems that some of the main issues are:
- Control (we have to decide what it is that's being controlled)
- Responsibility for work being done
- Simplicity (removal of all the "stuff" that stops you from doing
what you need to be doing).

What else?

On Thu, 14 Nov 1996, Michael McMaster wrote:
> Replying to LO10959 --
> Ben shares a great example of how "organisation comes before self
> organisation". As his example says, my point is that design for "self
> organisation" is different from design for hierarchical, mechanistic
> control, but it is still design.
>
> Why call it "bottom up"? It isn't. As his example shows it is neither
> top nor bottom. In this approach, the very idea of top and bottom make no
> sense. It might be better to call it emergent, or systemic, or complex or
> living or ??
>
> I consider it to "centre out" where the centre is wherever you are.

I saw a Margaret Wheatly and David Whyte gave a presentation where they
discussed how humans operate (that the engineering model of work doesn't
work on people (of course... I knew that) rather, the human needs to
belong, and the non-coercible characteristics we humans have require a
different model).

These discussions scare many of the more traditional management types
because breaking the hierarchic model implies losing control. If you
can't "control it" then they feel we are in a state of disaster. Yet even
they will admit that SOMETHING has to change.

In all this discussion I saw repeatedly the juxtaposition of two words.
They were: "Hierarchy" and "Relationship".

This brought to mind the following analogy that suggest some possible
organizational models already exist, that we DO know something about that
may also work with people.
----------------
In the early days of mainframe computing, databases consisted of lists
stored in the computer (or in the decks of cards that had both code and
data intermixed. The lists could be fairly thick with records, but since
the machines could search them fairly quickly, there wasn't much
complexity to their design.

As machine capability rose, the need to link lists became aparent, and the
IMS model of data management was developed. This was a hierarchic database
design where data was held together in a tree structure (looks a lot like
an organization chart if plotted on paper) and placed it's emphasis on
"who or what was - in the box".

It was fast and efficient for the machine to manage, but required a
certain type of logic if one was to get data out of the data base. If a
new question was asked of the data, it often required a good bit of
re-coding in order to get that data, otherwise you had to ask your
questions in the "normal way" and had search the print outs for your "off
the wall" answers.

Then in the mid 1960's the Codd relational data model was introduced.
(The Boeing company build some of the early relational database engines -
I think one was called VULCAN, that established the viability of the
relational database in industry). This model placed the emphasis on the
relationship between data elements rather that "what was in the box", and
permitted a lot more flexibility in what kinds of questions one could ask
of the data held in a machine. Old mainframe computist's would often
complain that this was not always the best idea because a query to a
relational database could tie up CPU time for an intolerable number of
hours or days, where the hierarchic model was "really fast", but I don't
think they ever got the point. Machine efficiency wasn't what was needed.
New understanding of the data was what was the issue.

What I find interesting in the relational model is where CONTROL is found.
The correct definition of the relationships between data defines the
"business rules" being used. The relationship controlled the system. The
skills of the data modeler are critical to figuring out what these
relationships are-a Business Level modeler who can boil out the business
rules at the high level (rather than the flow chart builder who just
tracks the flow of the current system) would have tools to do this.

Now, what if we tried to build a relational organization? What if our
structure was based not on "who's in the management box" but rather on
"what is the necessary relationships needed" to make the enterprise work?
What would the essential relationships be?

I've heard Margaret Wheatly describe chaos theory, and the idea of the
strange attractor giving structure and organization where only mayhem is
supposed to be occurring. She says this is a natural process, and works
in spite of what ever efforts we expend to "control" it.

I suspect she is correct because my work experience suggests thatin most
organizations there actually is a dual system in place in most
organizations.

While on the one hand the typical org chart depicts who's in the
box and who we are all answerable to, yet there is always the "back
bushes" activity where contacts and friendships are made between people
in a company, and where favors are traded when results are needed or
machines need to be fixed, etc. I was a full participant in the
underground Macintosh computing support system that came into existence
in the Boeing company after the decision to eliminate the Mac and go all
PC was made at the corporate level.

Since my assigned work as an artist required a high level of
productivity, and since I found the PC to be intolerably clunky, time
consuming and problematic to use for art up until about a year or so ago
when the current wave of windows software matured. I developed links
and relationships that allowed me to keep my old 1988 vintage Mac
IIx alive and viable to this day (I'm writing this on it) even though I
have a 100 MHz pentium on my desk for my production work.

So while we us our informal relationships to get around blockages in our
heirarchic organization, we are still answerable to the heirarchy.

This suggests to me that both heirarchic and relational/chaos based
models are at work concurrently.

The flexible organization seems to require intelligence at all levels and
in every job or task. Quick responses to new situations seem to require
the ability to plug into or relate in different ways without the
cumbersome permissions and signatures required by the hierarchic model,
yet the management need to feel some sense of control or they will all
panic.

It seems to me that the relational model that has been used to manage data
(and has a track record, experience base, rule of the road, etc.) could be
one of the ways we could consider when organizing people and
organizations.

Of course a lot of clear thinking will be needed to define the
relationships accurately, so the actual business rules are known, but if
this work is done well, I feel that MORE control can be had. It won't be
the sort of control current management is used to, but just as in the data
base environment, the new kind of control was (or is) much more powerful
and capable than the old kind of control.

Of course if we follow the analogy to it's end, we find the database
designers working with the Object Oriented model for data.... I don't know
enough about it to think much about it... But if the rules can be figured
out, and tested, could it be adapted to human organizations?

Comments anyone?

Michael Erickson
sysengr@atc.boeing.com

-- 

Michael Erickson <sysengr@atc.boeing.com>

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