>I work in a startup software firm where change is constant. We refine our
>software design and evaluate the markets response to our product
>constantly. We are a fairly tight group with no hierarchy. The usual
>paradigm would suggest that there would be little need for documentation
>in this setting.
>
>However, IMO, in such a fast paced situation, documentation can really be
>critical. Often, tasks and responsibilities are shared. If real time
>communication does not occur, the system doesn't function well. It is
>interesting to notice that even though there is not 100 feet between any
>one of our desks, email gets used a lot. With such busy schedules, email
>helps us manage time effectively. And in my book, email counts for
>documentation.
>
>Most significant decisions are made by the managers jointly. Each person
>comes to the table with their area of specialization. Often, they will be
>predisposed to a course of action. In such situations, it has been my
>observation and personal experience that even though there is enough
>discourse to resolve the topics, my memory of the nuances of others
>positions is sketchy. Consequently, it has been important to have some
>system of recapping decisions.
Stephen,
I think the most interesting example of this need for documentation of
learning notwithstanding the fast pace are the 24 hour development efforts
of companies like HP and Robert Boscht. Global product development teams
hand of the tasks following the sun, greatly decreasing cycle time by
continuous, 24 hour per day development. But each handoff requires
documentation, and almost certainly something more structured, dependable
and consistent than email alone.
Michael A. Gort
gort@mail.com
--"Michael A. Gort" <mail18081@pop.net>
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>