Creating Work Products While Maintaining Post DesignShop®
KreW Integrity
Gail Taylor
illustrations and additional
material by Bryan Coffman
02/20/1997
Editor's Note:
Check out these related articles on Work Products:
Introduction to Work Products
Creating Work Products
Prologue
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
The 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
This is IMPERATIVE. Too 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:
- Lack of collective, team-based understanding
and use of the MG Taylor principles embedded in the 7 Domains.
- 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.
- 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
19970220091833.web.bsc
|