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.

  1. 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.

  2. The challenge for the Web is to generate several iterations of a Work Product. For this workshop, the Work Product should:

    1. articulate the conditions surrounding transition management and transition managers at the end of this century,

    2. 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

    3. use the domains of Process Facilitation, Project Management, and Environment as a framework and focus.

  3. 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.

  4. Knodes step up to the work by choosing a Patch to work in.

  5. For this event, process facilitation, project management and environment may not be assigned to Patches as three separate Patch Products.

  6. The purpose of each Patch is to generate the best Patch Product it can during each iteration of the game.

  7. Each Knode has two roles:

    1. it helps its Patch design and deliver its Patch Product;

    2. 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.

  8. 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.

  9. 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)

  10. 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.

  11. 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.

  12. 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.

  13. Knodes may switch Patches in accordance with rule 4.

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


© MG Taylor Corporation, 1995 - 2002

iteration 3.5