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>