Creating Work Products While Maintaining Post DesignShop® KreW Integrity

Gail Taylor
illustrations and additional material by Bryan Coffman


Editor's Note:

Check out these related articles on Work Products:
Introduction to Work Products
Creating Work Products

Most KreWs experience high levels of synergy during DesignShop® Ventures in proportion as they assume responsibility for managing the 7 Domains. However, some experience a degradation in the process of pulling work products together once the participants leave. This isn't by intent, or lack of focus--or even hunger to create something that adds value--rather, the team forgets to apply what it is learning about collaborative design and the release of group genius to its own practices. Suddenly, the 7 Domains fall out of the picture. We can understand this phenomenon through the use of two models: the Stages of an Enterprise model and the 7 Domains® model.

Team Death and Rebirth on the Stages of an Enterprise Curve
DesignShop Ventures appear to be seamless wholes, but viewed through the lens of the Stages of an Enterprise model, they separate into at least two distinct events: the DesignShop event itself and the follow-up production of the Journal and Work Product. One simple event precipitates the division: the removal of the participants from the process. Such a great change in the composition of the whole team cannot be addressed by anything short of rebirth of the team.

Usually the KreW circles up twice following the main DesignShop event: once immediately after the participants leave and again the morning after. The first circle-up closes the main DesignShop process. The second circle-up inaugurates the follow-up DesignShop process. Trouble inevitably ensues if the team uses the second circle-up to merely continue the work in progress. Yet, there is a strong temptation to merely continue, and for several reasons. First, the team likes the feeling of working in the Maturity stage of the Enterprise so much that it resists pushing the Entrepreneurial Button to redesign itself. Unfortunately, it is deluded into believing that the event is in maturity when it is really in start-up again. Second, the presence of work in progress adds to the feeling that the DesignShop event is not truly over. After all, there is a Journal in some stage of production, and a good portion of the conversation in both circle-ups focuses on what must happen to bring it to completion.

Nevertheless, the DesignShop event IS over and must be reborn as a new event. This means it must be facilitated through the entrepreneurial button. If the KreW continues along the original DesignShop enterprise curve, it travels the "rocky road to team death" as illustrated in the accompanying diagram. Productivity rapidly falls off only to be dragged up in lurching cycles by haphazard individual efforts to pull things together. Teamness collapses almost immediately, to be replaced by various pathologies: bureaucracy, paternalism, traditional management, infighting.

There are several ways to tell whether a KreW has actually pushed the entrepreneurial button or not. Foremost is a determination to recontextualize the work. Instead of the Journal being a document in progress on its way to completion, its form and content may be vigorously challenged until it becomes a new document more fit to match the final results of the DesignShop event. Quite a bit of collective energy is expended on the design of the Work Product, and this work is eagerly attended to by the entire KreW, including those working on the Journal. An all-encompassing vision of products--both Journal and Work Products--results. In other words, the KreW does not splinter into multiple teams until it has a sense of the whole product of the DesignShop process. Times for the whole KreW to circle up and present iterations of their work are programmed.

Managing Both DesignShop Events Using the 7 Domains
I claim there can be no high performance, self-organizing team or process without a keen use of the 7 Domains model. Frequently after a DesignShop event, the KreW falls out of BEING team, and becomes instead a group of individuals gutting it out to get the task done ... even competing -- instead of flowing -- with each other! (Occasionally someone will mutter that "when so-and-so gets tired enough, he will leave and then I can get the @#! thing done!)

A team must learn to create work products in the same fashion that it serves the customer during the DesignShop event. Here are some pointers that I think will help.

[the following glyphs come from the 7 Domains model]

Work products should be designed to add great value over both the short and long term
This means that we give the participants not only what they want but also
what they need. The work products must help them realize new patterns, new ideas, different ways of working. They should help participants communicate to others the "difference that makes a difference" about the work they did in the DesignShop event. Work products must be full of rich memes--transformative ideas that propagate through an enterprise's culture. These transformative ideas, properly embedded, will empower the participants and their enterprise to realize their goals in a manner that's easier, richer, and more worthy of their abilities and dreams. (Remember, we are supporting transition managers and the work products, and the Journal must have embedded within them morphogenetic fields.) So, work products must carry implicit and explicit information, and, like a seed, they store energy and release it over time.

The KreW must remain team
Some KreWs devolve into parts; each part going about its tasks in strategic and philosophical isolation from the other parts. The KreW must remember that it's one team doing one thing. This one thing will have many facets and may be expressed as a Journal, video, newsletter, story,
ANDMap® documents, finished art, or other artifact. The Journal is part of this whole. All products should work in synergistic relationship to each other. Each should be seen and felt in the other. Remember that a juggler can't juggle three balls at once. It's impossible to hold that many independent variables in thought at once. Instead, the juggler learns how to do one thing that's called "juggling three balls."

Therefore, I think it is a mistake to divide the KreW into two or more independent teams. How to manage the parts and the whole is a matter of design. There are many, many overlapping and value-added parts! Each part should grow stronger in interaction with the others.

The KreW must facilitate itself
process facilitator must ensure that this is happening, but not be responsible for it happening; this must be the responsibility of the whole team, and each and every member--otherwise the process facilitator becomes a boss and facilitation degrades back into command and control. I have noted that team members often fall into non-value added work habits and that no one takes responsibility for insisting that these habits not take over the work process. I suggest that the team takes time, before beginning the work, to assess each other's non-value habits. Ideally, this is a self-aware exercise, but often these habits that team members "fall into" are invisible to the individuals (I certainly have blind spots) and pointing them out can be a gift to the team and the individuals.

Be willing to give each other feedback
Insist that the work get done in the most enlightened way. Feedback still seems to be a very scary thing for members to provide each other. And yet, feedback loops are what governs the system and keeps it in homeostasis. (Read Drucker's quote of knowledge workers -- in the back of the Staff Manual guide) Remember that feedback is different from criticism or from managerial direction. Feedback demands collaboration and design between the different parties.

Work iteratively
oo often KreWs have no idea what the different products are like until they receive the final versions shipped to their homes after the DesignShop event is over. If the products from the shop are to work together synergistically, they must grow together, and this involves a periodic exchange of information on a high-frequency, low-magnitude basis. This can be accomplished in part by having scheduled circle-ups, but these are too low-frequency to be of great value. Instead, the environment should be employed so that people who are working on different products can see each other's interim work posted on nearby walls, and so that they are encouraged to kibitz on this work.

Also understand that iteration is a property of project management. This is important because current project methodology overlooks or attempts to eliminate iteration, mistaking it for redundancy or lack of efficiency. Iteration is the ONLY way for network-and-agent-based complex systems to manage toward a goal successfully. The network is defined in part by a rich set of connections between its agents. Without these active connections, the network collapses into a hierarchy or dissolves into a disparate collection of nodes.

"Exemplary performers use the constant flow of information to shape products and services. In contrast, other performers use only initial information. They tend to present their initial product or service as their final product or service and often have an aversion to producing or reproducing the product.

"Exemplars, on the other hand, use the flow of information as inputs to engage in productive iterations of product development: The exemplar, given the time constraints, will repeat the process as many times as necessary in order to produce a 'perfect product.'

"For most products or services, the exemplar engages in six iterations of production. Each of these iterations emphasizes further shaping of the product because of new information feedback. Each iteration becomes a more and more efficient resource investment -- perhaps half of the previous phase. In turn, each iteration doubles the quality of the product or services. In this manner the exemplar becomes increasingly more efficient in resource investments and effective in results outputs." --Robert Carkhuff, The Exemplar, 1984

I observed one recent successful implementation of iteration. The KreW met often (every few hours),each bringing iterations. They combined them rather than just acknowledging the parts ... often read the words aloud to "really hear" what was being said ... implicitly and explicitly. Feedback was good; ideas, both visually and verbally were sometimes "thrown out", other times celebrated; new possibilities grew from within the entire team. The team did not start with a clear model; they began with model elements and let the story/model emerge, into a whole.

Stay together
I have noted that many Knowledge Workers disappear as soon as the DesignShop event is over to find their own "private"space where their thoughts won't be interrupted! Now just think about how you feel when the participants do this! (Some Knowledge Workers check out of the psychological space while staying within the physical space.) If you are out of the"interactive" space you are out teamness. You will not sense/feel/intuit/hear when to flow your ideas into others and when to let other's flow into yours. Thus you will resist getting together every few hours to collaborate and iterate.
Employ the environment to aid collaboration instead of fragmenting it. Also work to employ technical systems to aid in collaborative work. If work is completed and posted to intranets or distributed databases, and iterations are noted by E-mails to the entire KreW, it may be easier to keep in touch.

These are a few ideas. Both Matt and I worry that the most work products and Journals are not yet living products. The reasons:

  1. Lack of collective, team-based understanding and use of the MG Taylor principles embedded in the 7 Domains.
  2. Lack of understanding of the patterns of thought and work from the DesignShop event; failing to understand the use of memes and implicit and explicit forms of knowledge that must be embedded in the various products.
  3. Poor use of time by not insisting that points 1 and 2 are understood and practiced.

copyright © 1997, MG Taylor Corporation. All rights reserved
copyrights, terms and conditions


© MG Taylor Corporation, 1995 - 2002

iteration 3.5