Slime molds
In the introduction to Emergence, Steven Johnson interviews Evelyn Fox Keller, a Ph.D. in physics that participated in launching the line of thought that’s called “emergence” (I don’t know yet if it’s Johnson who coined the term or if it has been known by that name since before the book). Regarding the slime mold – which actually is an organism that, as Johnson writes, “spends much of its life as thousands of distinct single-celled units, each moving separately from its other comrades. Under the right conditions, those myriad cells will coalesce again into a single, larger organism” – Keller says that biologists had a hard time accepting the fact that there aren’t any “founder cells” or “pacemaker cells” – cells that shepherd the others.
Keller and her collaborate Lee Segel published a paper in 1969, arguing that there weren’t any such pacemaker cells – something that biologists had assumed, writes Johnson, “were a sign of insufficient data, or poorly designed experiments”. Keller says, “The response was very interesting [...] For anyone who understood applied mathematics, or had any experience in fluid dynamics, this was old hat to them. But to biologists, it didn’t make any sense. I would give seminars to biologists, and they’d say “So? Where’s the founder cell? Where’s the pacemaker?” It didn’t provide any satisfaction to them whatsoever.”
Johnson continues, “Keller’s challenge [...] also unearthed a secret history of decentralized thinking, a history that had been submerged for many years beneath the weight of the pacemaker hypothesis and the traditional boundaries of scientific research.” That is, it meant the beginning of the end for the idea that there must always be some entity that controls groups of other entities. The idea that groups of things – be it birds, ants or people – can “self-organize” without the help of a coordinator is difficult to accept. We are inclined to think that there must always be someone calling the shots.
This makes me think of one interesting response I got from Deric (via e-mail) to my post The relationship organism (over at Tesugen.com). He said that my post linked with ideas he had had about teamwork and the appearingly subtle difference between shared responsibility and common responsibility. Shared responsibility is when each member of a team has his/her share of the task; the team is done when each member is done. Common responsibility, on the other hand, is when each member does everything to get the task done – either working directly with the problem being solved, or indirectly by supporting his/her team members. The difference between these two is that with common responsibility, every member sees it as his/her responsibility to finish the task, instead of only caring for 25%, or whatever fraction of the task that he/she was responsible for.
With shared responsibility you definitely need someone calling the shots, but with common responsibility you don’t. This is something that’s rather central to Extreme Programming (XP), but I guess that many XP projects struggle because of the belief that you must have someone in charge. When I read Deric’s e-mail, I also came to think of the Fast Company article Engines of Democracy, by Charles Fishman, I read a while ago, about how at General Electric’s jet engine factory, there were one boss, that was more like a coach than a boss (that is, that she regarded her primary duty to be to enable the workers to do their job as effectively as possible).
I think this flawed thinking – that you must always have someone in control of things – is something we must rid ourselves of. As a programmer, I have found it to be rather obvious that development can be done much more effectively, if only the buyer of a system engages closely in the project – and if both the buyer and producer parts are following the maxim of common responsibility. The farther the buyer and producer are apart, the slower things go; the more time has to be spent nailing down specs and verifying the outcome; the more both parties become defensive and want to secure their backs in case the project should fail.