Team Knowledge & Patterns LO17198

Nigel Vickers (thenige@interlog.com)
Fri, 27 Feb 1998 01:02:42 -0500

Replying to LO17088 --

In LO17088 Michael Hertz wrote:

> I am currently chewing on some ideas that are tangentially related to the
> ideas of teams and team organization.

...snip... to paraphrase Michael . . .

> What I am working on is what sort of knowledge is embedded in a person and
> what sort of knowledge is embedded in a team.

...snip...

> . . . Person A is then approached by another team and convinced to
> leave the team. The teams make an arrangement that Person A is not to use
> any of the stuff (explicit knowledge, i.e. algorithms and such) that she
> learned from her first team. However, Person A is still able to use the
> tacit knowledge that she gained while working with the team. This
> knowledge is not readily available to her first team because (as almost
> universally accepted) tacit knowledge is hard to codify.

...snip...

> . . .The more complex and interesting (at least
> to me) aspect to think about is if a whole team leaves an organization.

...snip...

> I feel that this topic is
> sufficiently juicy that there are several parts that could be addressed.
> If anyone has any ideas on the subject I would be very interested to hear
> them. Also if anyone knows where I can locate information on this topic I
> would like to hear it as well.
>
> Thanks,
> Michael Hertz
>
> 309 Emmet Street
> Charlottesville VA 22903
>
> mth3r@virginia.edu

I hope I preserved enough about Michael's points that I can logically
extend this, so here goes.

Michael makes an interesting point about the web-like synergies and
complementary skills that exist in successful teams -- and how the loss of
a team member affects those synergies by introducing a void. A void in
manpower and a void in knowledge. Manpower can be replaced, knowledge
cannot.

What I see as the issue is the ability to store knowledge for reference or
reuse, in a medium other than the human being. One of the most effective
tools I have found to store knowledge is Patterns.

Patterns originate from an architect named Christopher Alexander. In his
book A Timeless Way of Building he recognizes and captures repeatable
ways of developing communities based on years of experience -- using
constructs called patterns. Each pattern consists of:

o the name of the pattern
o the problem statement
o the context of the problem
o the forces to be considered
o the solution

Groups of patterns in a particular domain (e.g., architecture, object
technology, BPR, auto sales) can be thought of as a compendium of
best-practices. But the key to patterns is in their application . . .

[ . . . patterns are creatively interpreted, combined and applied based on
their applicability in the problem domain. ]

When a person on a team has applied patterns to develop a solution, the
solution is not the only end-product. Another end-product is the patterns
(i.e., knowledge) that were applied to arrive at the solution. A
different individual of similar intellect can use the same patterns to
develop an equally-effective solution. Notice I didnt say identical
solution, as this is where the human traits of creativity and
interpretation come in.

I'm out of breath : )

Have any of us investigated, applied or constructed patterns to build
solutions? as a way of housing knowledge?

Cheers,

Nigel Vickers
Analysis by design, Inc.
thenige@interlog.com

-- 

Nigel Vickers <thenige@interlog.com>

Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>