A632.2.3.RB_SienkiewiczRaymond

In her research on the concept choice, Sheena Iyengar dived into a deeper examination of the implications of having a greater variety of choice, and found that more is not necessarily better. In fact, choice overload can arguably lead to poorer choices or no choice at all. One simple but interesting example she gave was how grocery customers, when presented with a selection of six versus twenty four different jams, were more likely to make a purchase when they had fewer choices.

Through these observations, she proposed four different techniques for application in business to improve the choosing experience. The first technique was to make cuts, not in an across the board manner necessarily but to trim back extraneous choices that had little positive impact, e.g. a product that had poor sales or cost more to make than it profited. The second was concretization, that is, illustrate clear consequences related to the decision being made, in her example what a person could do with extra money saved away. Some additional choices can be useful though. In a third technique, Iyengar suggests categorization by way of taking a large pile of potential choices and breaking them into multiple categories. In her example, she believes it is better to have 400 magazines with 20 categories rather than 600 with 10, for there is greater distinction and better choice opportunities. Finally she suggested conditioning for complexity by giving the less complex before the more difficult ones, as this helps avoid a level of decision fatigue where the chooser keeps going with the "default choice."

I could see the techniques of cutting and concretization as having some notable implications for myself and my organization. Knowing myself, I know that it doesn't take a lot for me to start feeling a little "whelmed" by decisions involved with a project or a problem, and I may well procrastinate until I'm forced to make a decision. By consciously breaking down a problem into the fewest number of available courses of action, I would expect it to be easier to make any necessary comparisons and make a decision more efficiently. Expanding upon that, by having fewer decisions in the pool it yields a reduced workload in anticipating concrete consequences from those decisions, another important variable in making a selection. In short, I would ideally reduce my decision chain to include only the most viable or reasonable courses of action, and if queried about consequences it will be easier for me to give concrete answers to provide justification or gain buy in.

There are also organizational implications for these two techniques. In my line of work, there are some problems that crop up which may be beyond my expertise, or may require a higher level of authority or influence. At the point I come to my commander or other senior leadership, there's an increased expectation that I come to them with possible solutions as they are inherently very busy people and can't do all of the problem solving for me. By cutting back the possible decisions being presented to them and being able to vocalize the concrete consequences as well as any possible second or third order effects, that enables them to more rapidly make a decision or to execute any necessary actions to help move things along. Additionally, by helping them out, that also ideally creates greater tolerance towards providing their inputs or expertise when I come to them with a problem that has me well and truly stumped.

To summarize, cutting and concretization techniques will, while not necessarily guaranteeing me the best decisions ever, will help me to actually make an informed decision in the first place at a reasonable pace, or at least give me a framework with which to provide my leadership useful options and enabling issues to be resolved at the lowest level possible.

A632.1.4.RB_SienkiewiczRaymond

In reading over the noted section on multi-stage decision making and the formulas that researchers use, I have to admit I'm impressed that researchers were able to work out decision making to the point where it wasn't just simply a recommend series of steps or a thought process that could be broken down into an acronym, but that they were able to lay out a numerical and data driven formula. Impressive as it may be though, I am very far from that same level of detail and would say I more often operate on a very basic set of heuristics as the text may call it.

Most of my day to day decision making can include recognizing potential problems in projects or solving problems that come up (and back brief my leadership accordingly, only pulling guidance if its a very hot issue), but often times I mainly need to decide whom to task with getting a problem worked and the manner in which I keep my supervisors in the loop. As comes inherent to the military profession, much of the technical expertise on the particulars of how a problem gets solved is taken care of by more experienced enlisted personnel to whom I give the broader objectives, and to whom I give any necessary authorizations to execute their solutions. Given that information and action flow, I'm inclined to think the implementation of decision formulas would be unfeasible, if not outright problematic. Thus, my decision making usually boils down to simply finding out what gadget needs fixing and delegating the job to the appropriate shop, or consulting with my flight chief or other senior enlisted for more complex matters such as appropriate disciplinary measures (which can also often times be dictated for us either by the Commander or Air Force regulations). As noted in the text on page 43, I'm generally using heuristics that weigh my options, generally weighing between action or inaction within different contexts.

Upon further examination it seems like the text focuses on examples of decision making in the context of events that have repeating occurrences or decision points, often with statistical elements, that in my opinion don't translate particularly well to decision making in the context of leading people and managing projects. Having said that, there are still good points that I believe have universal application in avoiding "myopia" and hurdles such as cognitive limitation and concreteness bias. I will admit that one of my greatest difficulties in working IT management is that often times we're talking about computer programs and processes -- something that I can't easily see or touch beyond perhaps drawing out a diagram. Even so, those aspects as well as the limited physical tasks of moving systems and plugging them in are things I often never touch and can only deal with conceptually due to what is expected from my role as a manager vice that of a technician.

Being conscious of another potential pitfall though, is generally speaking a good thing. Although maintaining a long term view isn't natural in day to day decision making, particularly at my level, I think it would be beneficial to think about second and third order effects next time I'm dealing with a larger scale decision. Further, knowing that there really is a thing as concreteness bias, that provides further impetus to ask the right questions to try and solidify concepts that at first glance have no inherent solidity. Although it would be rather difficult to use the text's process in a sensible manner to my duties, considering the potential obstacles to thinking may well improve my ability to anticipate and mitigate issues, and perhaps help me help my workcenter create better deliverables the first time around without a lot of back and forth between our level and senior leadership.