Rol,
I suggested something similar to many hierarchies in an earlier post.
What you say is, I think, so. The common, inherited problems
attributed to hierarchies are not necessarily functions inherent in
hierarchy.
William asks, "Have you ever seen a hierarchy go quietly into the
night?" My response is, "Sure. Many times." When project teams
form, they are generally small hierarchies and when the project is
finished, the team (hierarchy) disappears with little problem. And
new ones form around different projects. (I'm not saying that
hierarchies are necessary nor even optimal in project teams - just
observing a common phenomenon.)
I suggest a few principles for having these hierarchies work as a an
organisational design.
- have there be clearly multiple hierarchies in the system which are
not merely building blocks of larger hierarchies but "stand alone" as
operational units
- have at least some of these hierarchies overlap by membership or
task (if each person is in more than one hierarchy, they tend not to
get so attached to their particular one nor to their particular
position in one)
- have a structure that constantly begins and constantly ends
particular hierarchies so it becomes the cultural norm for
hierarchies to be temporary rather than permanent.
--
Michael McMaster : Michael@kbdworld.com
web:http://www.vision-nest.com/BTBookCafe/TIA/TIAmap.html
"I don't give a fig for the simplicity this side of complexity
but I'd die for the simplicity on the other side of complexity."
attributed to Oliver Wendell Holmes
Learning-org -- An Internet Dialog on Learning Organizations
For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>