Viewed 1723 times | Published on 2019-12-08 15:13:38
This post is actually the background to one of my Wordbook entries, with the same title.
In a 2014 course that I followed in summer 2019 to update old conceptual skills before embarking on a personal project, one of the readings was a book that contained this quote blending bees, direct democracy, and decision-making within a swarm:
"When a honeybee swarm chooses its future home, it practices the form of democracy known as direct democracy, in which the individuals within a community who choose to participate in its decision making do so personally rather than through representatives. The collective decision making of a bee swarm therefore resembles a New England town meeting in which the registered voters who are interested in local affairs meet in face-to-face assemblies, usually once a year, to debate issues of home rule and to vote on them, rendering binding decisions for their community. Of course, there are differences in how direct democracy works between bee swarms and town meetings. For example, the scouts in a bee swarm have common interests (e.g., all want to choose the best available homesite) and they reach decisions by building a consensus. The people in a town meeting, however, often have conflicting interests (e.g., some do and some don't want to help fund the town library), and they reach decisions by using the majority voting rule: each individual has one vote, all votes have equal weight, and the option that gets the majority wins. Another basic difference between bee swarm and town meeting is that a scout bee in a swarm, unlike a citizen in a meeting, cannot monitor each exchange within the group's debate and thereby have a synoptic overview of the discussion. Instead, a bee can only observe and react to the actions of her immediate neighbors in the swarm cluster, hence she operates without global knowledge of the information that percolates among her fellow swarm bees." (T. D. Seeley, "Honeybee Democracy", 2010 Princeton University Press)
Yes, we are more complex than bees, but, frankly, in any human organization that is slightly more complex that a town library meeting, most people reason by "circles"- i.e. their overall understanding and feed-back extends to their everyday "potential contacts", not across the whole organization.
Then, in most cases, decision making is done between circles more than with the overall "swarm", often with a "hierarchy" (balance of power) as an additional "weight" to consider the feed-back.
Recently recovered a copy of a book that I had with me since the late 1980s.
Back then, I was asked if I wanted to work on a new line of business for Andersen, i.e. selling Decision Support Systems and Executive Information Systems software tools provided by an Anglo-American company called Comshare, working on PCs.
When I say PCs and DSS or EIS, I should contextualize: back then, a "Portable PC" was a "Compaq brick", but eventually I received a Toshiba with a plasma display- a mere 9kg (I was always around Italy for pre-sales meetings, to work on proof-of-concept projects, to audit models built by others across Andersen, to design models with either customers or senior colleagues, or to deliver training to customer managers or colleagues).
The key point was: as I worked across all the divisions of Andersen, one of my "perks" (and actually the main one that I used often) was a free access to the library in their Turin offices, which contained the "green booklets" for all the exams that were within the journey through the hierarchy, as well as books, as well as documents from projects.
Reason? Usually, I was warned with a short-notice, as (another bit of contextualization) we did not have mobile phones back then (I was even offered to install a fixed line in my apartment so that I could be reachable even in those rare nights I was at home in Turin, and over week-ends: you can imagine my answer).
So, I had to quickly get onto new subjects almost twice a week, and eventually started cross-feeding from one domain to the other (decision making is about making decisions, so you quickly learn to differentiate from what is really domain-specific, and what instead can be "recycled" with adaptation).
In political activities as a young federalist (at 17) I had learned that sometimes discussions and choices weren't a one-way road.
Saving face in Italy is important- in business as well as in politics, more than in other countries.
Admitting to a mistake is unusual, and the higher up within the hierarchy you are, the lesser the chances.
Anyway, I discovered quite soon first at the university while waiting to be called by the Army (long story, out of scope), then during my compulsory one-year service, and finally in business that keeping track only of "positive" choices (what was decided) is often the best way to make friends, as nobody wants to remember how the consensus was reached.
Hence, most let fly into the trashbin of memory all the discussions and disagreements that led to the result: as if any choice taken were to be "the" choice forever and ever.
Now, if you look instead at business, notably at Decision Support Systems, the purpose was to do at least the following:
1. "structure" an informal decision making process, so that it could become repeatable and maybe not even involving the provider of the "logic" (e.g. a senior manager or a cadre with long-term organizational memory)
2. represent that structure by a model based on rules with all the options covered
3. feed data, "cleaned" and structured in a sensible way, into the model, and support whoever was using it, by presenting options, numbers, and, in some cases, enabling to evaluate different scenarios (from "what if I change the number of gizmos produced"- what if, to "we would like to achieve a 12% operational margin on that product line, altering only the sales and distribution costs in three regions"- goal seeking).
Now, if you are used to Excel, in that case we were talking about models that looked like spreadsheets, but actually were closer to Rubik cubes, conceptually.
Or: fix the "slice" you want to see, and identify the coordinates on the other dimensions.
If you built a model, you made choices on what was in and what was out.
In my case, after few trial-and-errors, I saw that a small, old, unassuming book was actually useful to develop a forma mentis that I used both on DSS and, years later, change activities.
Back to the future: during high school, for reasons too long to explain I had studied how to "dissect" language, using something called BNF (to design "compilers", i.e. computer programs to convert programming languages easier to understand for humans into something more compact, to be processed by computers), specifically to analyze and structure language (both natural and artificial, e.g. computer languages or invented languages), and "building grammars"- syntax, morphology, and the like.
So, I tried using that also to describe the "decision patterns" for each model, but it was useful to summarize (e.g. also in organizational manual to ensure that every step in every process was covered and that responsibilities were identified and, if possible, no overlap was allowed).
But when you are building a model for, say, end-to-end production-to-distribution-to-sales, the number of elements and options (e.g. channels, each one with their own constraints) in any sizeable business can be staggering.
Imagine: few regions, few product lines, each product line with few channels, across few years (for comparison reasons), then few Key Performance Indicator to be computed, but all assuming that some combinations should be ignored (e.g. the proverbial selling of ice-cream to those close to the North Pole).
In one of the Andersen's "green booklets" I found a reference and outline on "decision tables".
And, being a book-worm by birth, I looked at bibliography, and found a book that was available in our library, "An Introduction to Decision Logic Tables", by H. Mc Daniel, published in 1978 by Petrocelli (New York and, again, Princeton).
The Wordbook entry gives an outline of what implies using such a tools as a "structuring and checking" tool, coupled with "organizational memory" (i.e. keeping track of the decision history and, even more important, being able to access when needed).
There are other issues related to the "lifecycle of information" that I discussed in the past and will be part of other Wordbook entries, for the time being a short introduction is available, as usual, on Wikipedia.