|
Rules of the Web
An Application of Patch Theory
to Collaborative Design
Bryan S. Coffman
March 18, 1997
How the Rules Came About
During the week of February 24, 1997 at a 7 Domains®
Workshop held at the knOwhere store, Hilton Head, SC, the facilitators
completed the design of a set of rules that would allow the twenty-two
participants to collaborate on the creation of a work product focused
on exploring the role of the Transition
Manager with respect to three of the 7 Domains: Process Facilitation,
Environment, and Project Management. However, they would collaborate in
a special way. There would be no management, no hierarchy, and assembly
as an entire group to discuss issues was discouraged. Furthermore, the
participants could not divide the work functionally (writing, graphics,
layout, assembly). Each participant would be connected at random to four
other participants (accomplished by assembling the participants into a
circle and having them toss a ball of yarn until each participant had
made exactly two tosses). Each participant was also assigned to a "patch"
consisting of four or five other Knodes. Participants could communicate
freely within their patch, but communications between patches could only
be accomplished via the ball-of-yarn connections. Each patch had a mission
to conceive and create its own work product, and the work products of
all of the patches taken together must add up to a synthesized, complete,
seamless-looking work product of the web.
Patch Theory
 The theory behind
the game comes from Stuart Kauffman's book, At Home in the Universe.
The book is an investigation into how living systems might generate "order
for free" by naturally seeking out autocatalytic system states on
the edge of chaos, thereby avoiding the twin deaths of chaos and equilibrium.
Kauffman uses computer simulations that reveal certain characteristics
of complex systems that maintain their balance at the edge of chaos. Simple
networks can do this by tweaking the rules by which nodes change state,
or by changing the number of connections that each node is allowed to
make to the rest of the network. It turns out that for webs composed of
"N" nodes, each having "K" connections, the networks
exhibit continuous complex behavior for K=2. For K<2, the networks
slip into a static equilibrium, and for K>2, the networks display a
frenetic chaotic behavior that never settles into patterns of complexity.
In the real world of business, however, it's extremely unlikely
for any individual Knode to have only two connections to other Knodes
in the enterprise--connections which cause the Knode to "recalculate"
its current state. Organization charts, matrix management techniques,
and traditional span of control doctrine all strive to limit the number
of compelling connections that any one Knode may have. But in vain. Kauffman
applies additional computer simulations to the problem of K>2 connections
and proposes Patch Theory. Each Knode is assigned to a Patch and is allowed
to change its state only if doing so will yield increased fitness for
the Patch. Each Knode in the simulation has exactly four connections to
other Knodes, some within its own patch and some to Knodes in other patches.
When the simulation is run, the web as a whole moves steadily and swiftly
across the fitness landscape to settle on the highest fitness peaks. Because
the improvement of one patch's fitness may occasionally cause the fitness
of the entire web to decrease, webs don't get stuck on less fit local
peaks, but have the ability to "devolve" their solution--move
down into valleys--in order to find and climb higher peaks.
Traditional management has indeed experimented with Patch
Theory through the process of departmentalization and dividing companies
into business units. However, the traditional approach is fatally flawed
because in the process of creating business units, all of the rich set
of connections between Knodes are severed and most communication is funneled
through manager Knodes who communicate with one another, but direct and
specify the states of the Knodes under them. This technique may create
the illusion of control and order, but it sacrifices evolution and learning.
The workshop facilitators sought from the beginning to avoid falling into
this trap, and the rules of the web are fairly strict concerning the creation
of hierarchy.
A model of the NK web similar
to the one that was created in Hilton Head is shown below, followed by
the rules.
Rules of the Web
copyright©, 1997, MG Taylor
Corporation, all rights reserved.
-
The Web is an enterprise composed of Patches, which
in turn are composed of Knodes. Each Knode is connected to exactly
four other Knodes, selected at random. A Knode may be connected to
other Knodes in its Patch or to Knodes outside of its Patch, or to
itself! No Knode or Patch is in charge of the Web.
-
The challenge for the Web is to generate several iterations
of a Work Product. For this workshop, the Work Product should:
-
articulate the conditions surrounding transition
management and transition managers at the end of this century,
-
reveal models, philosophies and strategies, principles,
tactics and methodologies showing how transition managers interact
with and respond to these conditions in order to complete the
evolution of a more fit breed of enterprise, and
-
use the domains of Process Facilitation, Project
Management, and Environment as a framework and focus.
-
The scope of content of the Work Product is divided
into Patch Products. The content of the Patch Products should be non-overlapping,
but interdependent. For example, an aircraft’s wings and engines
are two non-overlapping but interdependent Patch Products of the aircraft--they
influence each other’s design and performance. Each Patch Product
is assigned to a Patch. The Patches may not be organized along an
assembly line approach where one Patch writes content, another does
illustrations, another does layout and assembly. Instead, each Patch
designs, writes, illustrates and publishes its own Patch Product as
a whole.
-
Knodes step up to the work by choosing a Patch to work
in.
-
For this event, process facilitation, project management
and environment may not be assigned to Patches as three separate Patch
Products.
-
The purpose of each Patch is to generate the best Patch
Product it can during each iteration of the game.
-
Each Knode has two roles:
-
it helps its Patch design and deliver its Patch
Product;
-
it trades ideas, concepts and portions of its Patch
Product with the other four Knodes to whom it’s connected.
These ideas may relate to design, content, process or organization
of the product. The purpose of trading is to help the Patch improve
its product and to influence the design and content of the Patch
Products being worked on by other Patches. Knodes should trade
ideas frequently during each iteration.
-
Knodes incorporate the ideas they’ve received in
their trading sessions into the current iteration of their Patch’s
product ONLY IF the ideas will improve the fitness of their Patch
Product--make it more robust, effective, etc. To determine if the
idea will improve the fitness of the product, the Patch must play
‘Spoze with it. They
may not incorporate changes that would reduce the overall fitness
of their product.
-
All communication between Patches is inter-Knodal. Outside
of their Patch, Knodes can communicate only with the Knodes they’re
connected to, but whole Patches cannot brief or be briefed by other
Knodes or Patches, or the Web as a whole. (see rule 11 for an exception)
-
The collective products of the Web’s Patches must
weave together and present a cohesive, designed and integrated appearance
and content. The whole product must present a sense of unity and seamlessness.
The tension between this rule, rule 8 and rule 3 drives creativity.
-
It may be necessary to radically adjust or redesign
the definition and scope of Modules, the composition of Patches, or
Connections between Knodes to address both the fitness of products
in the Patches and the fitness of the overall product of the Web.
These tasks, however daunting, can be accomplished using only inter-Knodal
and intra-Patch communication strategies. However, in
extreme cases, the entire Web may assemble to reconfigure itself to
better respond to the challenge. This is the only time that rule 8
may be broken.
-
A Patch may change its Patch Product so long as the
scope of the Web's Work Product is not diminished (rule 2) and so
long as the new Patch Product meets the criteria outlined in rule
3.
-
Knodes may switch Patches in accordance with rule 4.
Conclusions
Over the course of four days, the participants actually played the game
for a total of 10 or 12 hours. The remaining time was filled with other
activities. The product they created can be
viewed on this website. Until the end of the week, the participants had
not been afforded the opportunity of reporting their work to each other
as a whole. The product they created, divided into four sections (one
for each patch) exhibits a great deal of internal integrity with respect
to content and nomenclature. As in any living system, there is some redundancy,
however it usually provides a slightly different view of the subject.
The participants felt frustrated about not being able to
have one or several individuals "in control" of the overall
look and content of the document; no one had a good sense of what the
whole looked like--they could only work to improve the product their patch
was working on, and communicate portions of that work to Knodes in other
patches. The integrity of the work emerged despite the inability of any
one Knode to have a sense of the entire product.
 
copyright © 1997, MG Taylor Corporation.
All rights reserved
copyrights,
terms and conditions
19970318221142.web.bsc
|
