Critical Number Of Workers

Think of any biological system, like a BeeHive, for instance. A minimum number of bees are required to collect nectar for the good of the hive and Queen Bee. If they cannot find enough, the whole hive may die. If they get enough, the Queen bee will lay more eggs, but hopefully not so many that the feeding and rearing of the new bees becomes a burden that endangers the hive.

--DavidCymbala


(Er-r-r, Patterns are allegedly to be built from examples of known systems, not speculation or inventions. It worries me to see one written without examples, makes me think this is SpeculationInPatternFormat (which would be ok if you just said so). see also ResultingContextNamesProblems -- AlistairCockburn)

{ You're certainly right. I'll be re-writing this as a pattern if it actually merits it someday. -David }


I've seen instances of this "pattern" lead exactly to the opposite of desired behavior in software development.

People will work to optimize what is measured, or what they believe is measured, and a reporting system leads them to try to divine what second-order artifacts and activities are being monitored as indicators. It may be O.K. if you're monitoring progress on the actual end-user-delivered artifact, using a proven and time-honored measure like, oh, lines of code or something...

What happens is that people manipulate the reports to "draw attention to themselves." If they get attention, rewards, or resources, they feel important, and may even feel they're accomplishing something. Elite teams probably figure this out faster than the others.

And I don't know about you folks, but I've yet to see a software house where everybody isn't 120% busy. It's a strange phenomenon, because productivity drops if you try to increase this number through overtime (because people burn out) or if you try to decrease it by "working smart." I think that the developer duty cycle is one of the most misconstrued measures of productivity or anything. The goal is not to keep people busy. People need think time (UnderTime?) on effective projects, too. I think there is another kind of "working smart" based on sound domain knowledge, passion for the job, and strong customer engagement that makes the 120% work harder for you. But that's a whole 'nuthuh set of patterns...

Examples:

I, like AlistairCockburn, remain very skeptical that this is a pattern.

-- JimCoplien


This is well-placed criticism, Alistair and Jim. I finally finished reading Jim's OrgPatterns in the PLoP1 book, and realized that I missed the boat on making my point. This idea may not be clear enough for a pattern, but may just be a general guideline. -David


Is the CriticalNumberOfWorkers concept a corollary of the model in Robert Axtell's paper "The Emergence of Firms"? http://www.brookings.edu/~/media/Files/rc/reports/1999/06technology_axtell/firms.pdf

In Axtell's paper, workers are characterized by their propensity/ability to add value, as opposed to their propensity to free-ride or ability cause more harm then good.

On page 22, Axtell says, "It seems that the optimal size of a homogeneous group is very nearly at the stability boundary of the group.... it might be dangerous to select the optimal group size, for a small perturbation to the next larger size could bring on unstable oscillations, and presumably, the demise of the group."

On page 36, Axtell notes that in his simulations, "It is as if firms facing declining effort levels maintain total production, perhaps through the incorporation of new agents."

On page 47, Axtell has interpreted his model's "firm growth and demise as a process in which agents are attracted to high-income firms, these firms grow, and once they become large get over-run with free-riders." In a footnote, he states that "In reality the life cycles of firms are thought to be intimately intertwined with product and industry life cycles".

On page 67, Axtell notes that in his model, "successful firms are not profit maximizers, but rather are those who attract and retain productive workers." This is partly because his model does not have any explicit ways for profits to produce compounding growth, other than through accretion of workers.


When an organization drops near or below its CriticalNumberOfWorkers, it may suffer from the TalentPump AntiPattern.


See also: FixedCost?, TalentPump


EditText of this page (last edited August 28, 2009) or FindPage with title or text search