R. Clayton (rclayton@monmouth.edu)
Mon, 20 Mar 2000 11:38:33 -0500 (EST)
This is a message we have just received from our coder
My computer is having some serious problems. It keeps rebooting for no
reason. I have been trying to get the code to work although I haven't been
able to get much accomplished and I need your help.
It's Sunday afternoon, Is there anyway we could have an extension till
Wednesday morning?
No. Either you've been working diligently on this since it was assigned way
back when, in which case you've probably done more than enough work to
demonstrate a grasp of the principles I'm trying to get across with this
assignment, or you've waited until the last minute to do anything at all, in
which case you'll at least learn, perhaps, the risks of waiting until the last
minute.
Also, I'm getting the impression from messages like this one that groups are
using a sort of one-for-all working arrangement where one person - possibly the
person who's the manager of the task - does all the work and everybody else
stands around to see if that person can get the work done by the deadline.
I've left it to each group to determine their most comfortable and effective
working arrangement, and if it's one-for-all, that's great. However, for those
groups that may be having trouble with one-for-all, I'd like to suggest they
try all-for-one, in which one person - again, probably the manager of the task
- assigns a piece of the task to each person in the group and then coordinates
among the working members to bring everything smoothly together at the end.
All-for-one has a number of advantages over one-for-all. First, it exploits
the old but useful adage "many hands make the load light". Second, it spreads
around the risk of absolute failure; reducing the consequences of individual
failure and making the possibility of total failure less likely. Third,
managers in the real world who don't learn to delegate don't last too long;
they either burn out or get shuffled off to a position where their
under-productive, high-risk management style has less consequences to overall
objectives (or they get demoted back to engineers).
This archive was generated by hypermail 2.0b3 on Thu Mar 30 2000 - 20:50:05 EST