The Future of Decision Making: How Revolutionary Software Can Improve the Ability to Decide

“The authors start from some essential truths about cognition. By combining them with a solid grasp of business realiti...

Author: Roger Schank | Elliot Soloway | Dimitris Lyras

34 downloads 708 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

“The authors start from some essential truths about cognition. By combining them with a solid grasp of business realities and software possibilities they are able to describe a realistic future in which machines promote the sharing of human wisdom.” —Eric Domeshek, AI Project Manager, Stottler Henke Associates, Inc. “These authors have converged to produce a forward-looking book that is as unhidebound as the methods they are preaching.” —William K. Purves, Professor Emeritus of Biology, Harvey Mudd College “Decision making is complex, and facts and figures are important, but common sense is even more important. We most often have to make decisions in circumstances when facts and figures are inadequate. This book is an insightful account of how to reintroduce common sense into decision making tools.” —Lawrence Howell, CEO of EFG International Private Bank “Roger Schank is the right person with the right skills to talk about decision making, about how the mind works and how to develop new technologies to make it work better.” —Sebastián Barajas Caseny, Founder, LearningWorks “Roger Schank has been pushing the edge of cognitive science for many years. As a co-founder of the Cognitive Science Society and a pioneer and visionary in the field, his concepts change the way organizations think about the choices they face.” —Arthur Stern, CEO, Global Prime

10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway

Copyright material from www.palgraveconnect.com - licensed to ETH Zuerich - PalgraveConnect - 2011-04-01

Additional Praise for The Future of Decision Making



This page intentionally left blank


The Future of Decision Making





HOW REVOLUTIONARY SOFTWARE CAN IMPROVE THE ABILITY TO DECIDE

ROGER C. SCHANK, DIMITRIS LYRAS, AND ELLIOT SOLOWAY



THE FUTURE OF DECISION MAKING


Copyright © Roger C. Schank, Dimitris Lyras, and Elliot Soloway, 2010. All rights reserved.

Where this book is distributed in the UK, Europe and the rest of the world, this is by Palgrave Macmillan, a division of Macmillan Publishers Limited, registered in England, company number 785998, of Houndmills, Basingstoke, Hampshire RG21 6XS. Palgrave Macmillan is the global academic imprint of the above companies and has companies and representatives throughout the world. Palgrave® and Macmillan® are registered trademarks in the United States, the United Kingdom, Europe and other countries. ISBN: 978–0–230–10365–8 Library of Congress Cataloging-in-Publication Data Schank, Roger C., 1946– The future of decision making : how revolutionary software can improve the ability to decide / Roger C. Schank, Dimitris Lyras, and Elliot Soloway. p. cm. Includes index. ISBN 978–0–230–10365–8 (hardback) 1. Decision making. 2. Technological innovations. I. Lyras, Dimitris. II. Soloway, Elliot. III. Title. HD30.23.S296 2010 658.4⬘03—dc22

2010007918

A catalogue record of the book is available from the British Library. Design by Newgen Imaging Systems (P) Ltd., Chennai, India. First edition: August 2010 10 9 8 7 6 5 4 3 2 1 Printed in the United States of America.



First published in 2010 by PALGRAVE MACMILLAN® in the United States—a division of St. Martin’s Press LLC, 175 Fifth Avenue, New York, NY 10010.

Introduction

1

Section I A New Decision-Making Model 1

Don’t Follow the Rules, But Do Embrace Case-Based Reasoning

2 Why It Matters: Greater Productivity, Profit, and Purpose 3

Software Based on the Science of Decision Making: Tools Organizations Can Use

21 41 59

Section II The Software Argument 4 Start with Activity Maps, Proverbs, and Goal Conflicts: Creating Software That Functions the Way the Mind Works

87

5

Identify the Experts and Gather Their Stories

107

6

Finding Information versus the Information Finding You

125

7

Decision-Making Training: More Experience through Software

147



Contents

CONTENTS

Section III

Implementation

8

The Human Factor: Achieving True Usability

167

9

Obstacles and Opportunities: How Organizations Can put Cognitive Systems into Practice

189

Index

211



viii


The Future of Decision Making





Many organizational employees make well-intentioned but poor choices. This is true for everyone from top executives to line workers. It is equally troubling that these employees rely on software that often makes matters worse. Having invested significant amounts of money in state-of-the-art information technology as well as hiring and training smart managers, organizations should possess the systems and skills for astute decision making. However, two problems prevent good decisions from being made. First, organizational systems, processes, and even cultures discourage employees from making intuitive choices. They are taught to ignore their gut instinct when making tough decisions. Instead, they feel compelled to trust the data and to depend on rigorous analysis and the conventional wisdom. This may work in certain circumstances— especially when decisions are relatively easy—but not when options are ambiguous and situations are unfamiliar. Cognitive science has made great strides in recent years in understanding how the mind works. One discovery has been that decision making is largely an unconscious process. When we believe that it’s a conscious activity we ignore factors that are crucial for right decisions while clinging to ones that are less important. We attach too much importance to available data and not enough to the signals we’re receiving that run counter to the data—to that voice inside our head that knows from previous experiences that a non-data-driven option is preferable.



Introduction


The other problem hindering decision-making potential in companies today is that most of the enterprise software currently in use is generic, and its lack of situational and organizational specificity results in poor decisions. Generic software provides information without context. Employees rely on this software for everything from crisis management to hiring. The software may provide tools to analyze alternatives or help match up a candidate’s skills with the job specs , but fails to take into consideration situational specifics. Software is generic out of economic necessity—Microsoft Dynamics is one example of this type of generic enterprise software. It is designed for big and small companies, for manufacturers of toilet paper to marketers of cell phones. As a result, it fails to consider specific industry and company factors and the situational challenges organizations are dealing with. The information and recommendations aren’t tailored to an individual employee facing a new or confusing situation but for composite companies in composite situations. Just as troubling, this software does not make the right generalizations across industries. In other words, it doesn’t “abstract” goals and obstacles, but instead focuses on an object that seems common to a number of industries, such as a purchase order. Goals and obstacles— such as why people buy things or what major deciding factors can be abstracted effectively—are essentially the same abstractions with different emphasis regardless of the industry. Companies must develop industry-, organization-, and processspecific software as well as capitalize on the common sense of the people with situation-specific experience. Years ago in less competitive times, these issues weren’t as troubling. But decision making today has become infinitely more challenging. In the old days, many choices were obvious—the problems were largely black and white and the options were limited. On top of that, mistakes weren’t catastrophic; there was a lot of room for forgiveness in the system. Today, little of this former lenience exists. More significantly, the business environment is growing in complexity and is volatile; it 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


2

3

requires a lot more insight to understand. People struggle with “rightversus-right” decisions. They’re operating in gray areas where nothing is clear. For these reasons, misconceptions about the decision-making process and the inappropriate use of generic software have had devastating consequences for businesses. The good news is that it doesn’t have to be this way. Companies can capitalize on advances in cognitive science and software development to make great decisions. Whether it’s a split-second choice in the heat of a business negotiation or a long-term strategic decision in a boardroom, we possess the cognitive insight and technology to make highly effective choices. The goals of this book are threefold: 1. To help decision makers capitalize on the science of decision making. We will reveal what cognitive scientists have discovered about how choices are made and apply this knowledge to common business situations. 2. To give organizations an understanding of a new software design concept that facilitates better decisions. We shall demonstrate how and why this concept is compatible with the principles of cognitive science. 3. To offer insights and advice about how organizations might combine cognitive science principles and this new software concept to develop performance support software (fostering better decision making during the execution of job responsibilities) as well as training software. The third goal needs a bit of explanation. The ideal enterprise performance support software doesn’t exist as of this writing. However, certain aspects of this software exist within the shipping industry and employee training software and we’ll use both examples to demonstrate 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


INTRODUCTION


what is possible. The technology is available. The cognitive science is known. There is nothing stopping organizations from creating this ideal software. It simply requires a commitment to this new decisionmaking model to put it into practice. The future of decision making is closer than most people think. We’re writing this book to make it a reality sooner rather than later.

Some Fundamental Truths Let’s start with some cognitive science basics: ●

Decision making is largely an unconscious activity.

We noted this earlier, but emphasize it here because this principle feels counterintuitive to a lot of people. When managers decide to hire someone, acquire a company, or enact a new policy, they’re not thinking consciously or logically. Of course, they like to believe they are. Most business leaders like to see themselves as rational planners. We’re taught that this is an attribute of leaders and believe our decisions are a product of research, analysis, conversation, thought, and decision. But all these steps are just how we rationalize our unconscious decisions. Most people take comfort in the “facts” to justify why they made a risky decision or took a controversial position. They tell themselves (and sometimes others) that they instituted a hiring freeze rather than downsizing because studies show that it’s better to save morale than costs in this type of situation. Or they choose to try and gain a foothold in an emerging market because their task force recommended doing so before their competitors recognize this market’s value. There’s nothing wrong with rationalizing decisions. However, there is something wrong with relying exclusively on data and analysis in making these decisions, especially when the choices aren’t easy and obvious. Every day in a large



4

5

organization people are called upon to make choices clouded by ambiguity, volatility, and emergency. The individuals who make the best decisions go beyond rigorous analysis and statistical probabilities and depend on what, for lack of a better word, we’ll refer to as a “sixth sense.” We might call this sense “instinct” or “trusting your gut,” but it’s more than that. People who make great decisions in tough situations usually have experienced a number of relevant situations in their past that guide their sixth sense. They’re not conscious of this fact, but nonetheless choosing A over B just feels right because of it. As we’ll see a bit later, computer software can be designed to capitalize on and help people take advantage of their sixth sense. ●

We make good decisions based on accumulated experience.

When facing a difficult decision, we are unconsciously reminded of similar past situations and of choices we made that led to both success and failure. That’s why organizations are smart to hire people for jobs where their experiences are directly applicable to their areas of responsibility. Ideally, we would choose the President of the United States based on his prior experience as president of another country; he would have encountered situations in one job that would have been valuable in the next. Unfortunately, we seem to think that being governor of Arkansas, Georgia, or—dare we say—Alaska is somehow relevant experience for the position when it’s not. Corporations are smarter than the electorate in this regard. Many companies hire CEOs who have been CEOs before. Even though they may not have faced the exact same situations in the past, they’re likely to have experienced the same decision-making categories. Some managers make great decisions—ones that seem uncanny in their foresight. An organization will hire an unlikely person for a job and she’ll turn out to be the perfect choice. These managers invest boldly in an untested technology that rapidly evolves to a state-of-the-art



INTRODUCTION


level. But they aren’t prescient. They are experienced. Unconsciously, the choices they face remind them of similar relevant experiences that help guide their decision-making processes. A baseball movie from the 1950s, The Kid from Left Field, illustrates this point. Early in the film, the protagonist, a young boy managing a little league team, calls a weird bunt-steal play that wins the game against the team from Myer’s Bakery. Later on the protagonist, now the manager of a major league team, calls the same play and ends up winning the World Series. When asked how he came up with that crazy play, he says, “Well, it worked against Myer’s Bakery.” This is how people make decisions. The coach didn’t consciously remember using the same play in the little league game, but the experience lodged in his brain. When he was in a similar situation managing a major league team, he was reminded of what happened and it resulted in a successful decision. ●

Decisions should flow from goal conflict adjudication, not through half-baked logic.

Here is a story from the shipping industry that illustrates this principle. A captain is navigating his ship through the Suez Canal when the exhaust gas boiler catches fire. The logical response is to stop the ship and put out the fire. Yet experienced captains will keep the ship moving despite a boiler fire because they know that they would probably have to deal with local bureaucracy and corruption in order to extricate the floundering ship from the Canal. And while the notion of putting out the fire seems paramount, veteran captains also recognize that the extent of damage caused by most exhaust gas boiler fires is nothing compared to the financial consequences of stopping a ship—catastrophic grounding, costly delays, local extortion, and so on. Despite the sight of twenty tons of red-hot steel and gushing



6

7

fire hoses in the engine room, a savvy captain knows it’s best to keep moving. Consider another shipping story with a less calamitous set of conflicts. A ship’s $10,000 anchor detaches and sinks. On the one hand, the captain could wait for divers to show up and retrieve the lost anchor. On the other hand, if he waits he’ll experience a costly delay in delivering the cargo. Goal adjudication is not just a matter of weighing one cost against the other. It’s also about conflicting interests—there’s the owner of the ship who also owns the anchor and the chartering company that will lose money if the shipment is delivered late, and a contract between the two parties stipulating a timely shipment. In many business situations, there aren’t just one or two factors to consider, but ten or twenty. Goal conflict adjudication may involve numerous nuances in which there’s no wrong answer and two right ones. Such subtleties are often understood only by seasoned executives—the “old salts” who can steer the right course in even the most difficult circumstances. They have the experience to adjudicate conflicting goals so that their decisions cost their organizations less or profit them more. Be aware, too, how people phrase these goal conflicts in their minds. Again, this is unconscious phrasing: In our Kid from Left Field example, the conflict would be phrased as, “I don’t want to look stupid (by calling an unorthodox play) but I want to win the game.” In our Suez Canal example, it would be, “I don’t want the ship to burn up but I don’t want to have my crew in jail and the ship impounded by corrupt government officials.” In our anchor example, it would be, “I don’t want to lose the anchor, but I don’t want to lose the shipping contract if it arrives late.” When decision makers lack the requisite experience or rely too much on logic in their approach, they don’t adjudicate goal conflicts. Rather



INTRODUCTION

8


●

Expectation failure catalyzes learning that translates into better decisions.

Organizations loathe the idea of failure, but failure is integral to on-the-job learning. The best way to learn on the job is to make a decision, assume it’s the right one, and discover that it’s wrong. This type of expectation failure is emotionally resonant—we are upset when our expectations are thwarted and negative consequences occur. This experience is indexed in a retrievable way by our brains, so that the next time we’re in a similar situation facing a similar decision, the experience is recalled on the cusp of the decision and guides us toward a more effective choice. This is how employees learn what to do—and what not to do. Recognizing the cognitive value of failure will make organizations more tolerant of it as a teaching tool. We’re not suggesting that companies tolerate multimillion-dollar mistakes and widespread, illconceived choices that harm the bottom line. However, we do advocate acceptance of failure as part of the learning process for young and new employees—be it an on-the-job mistake or in a training scenario. We’ll refer to all four of these cognitive principles throughout the book, explore them in greater detail, and suggest how to incorporate them into software.

Hard Truths about Software In his book, Why Software Sucks . . . And What You Can Do About It, author David Platt castigates software developers on a number of fronts.



than being aware of all the factors making one goal more important than the other, they make a choice based on incomplete or erroneous criteria.

9

Platt suggests that they create software for people like themselves rather than normal users, making software complicated simply because they appreciate the technical aspects of its complexity, and so on. This book is right on the mark. We would also add that enterprise software fails in decision making because it doesn’t take into account the three cognitive science principles we’ve just listed. This generic type of software is designed to provide general information for broad scenarios rather than specific problems. It’s fine for making small, straightforward decisions where all the variables have been adequately analyzed. But when things become a bit more complicated or involve issues particular to a specific company or industry, then this kind of software is virtually worthless. Because the vast majority of enterprise software fails to adjudicate goal conflicts or doesn’t allow people to go with their gut when facing difficult choices, it falls far short of what it might be. The shame of it is that technology has reached a point where it can really help businesspeople make more effective decisions. The increased speed and mobility of computer technology has made it possible to capitalize on cognitive science principles and to create software with these principles in mind. This software uses indexing language. Here’s a story from Roger that will help explain how the mind indexes concepts. I appeared on a CNBC show about Innovation, and after the show I was contacted by the Chief Innovation Officer at Procter & Gamble. He had liked what I had said and wanted to work with me on creative approaches to making the company’s bleach better. When we met, this P&G executive explained why innovative thinking was needed to overcome an inherent problem of the bleach—while it is a highly effective product, it sometimes is too effective—bleaching clothes that you don’t want bleached. He used the term “collateral damage” when referring to this side effect. As soon as he came up with this term, he put indexing into operation. Indexing is the way the mind



INTRODUCTION


catalogs information. “Collateral damage” is a term that is used in the military to refer to unintended casualties of war. But it also applies to chemotherapy. When the innovation officer made this connection, he talked to chemotherapy experts, and they explained what they did to minimize collateral damage (i.e., damage to healthy tissue) during treatments. He was able to apply the same collateral damage process to limit the undesired side effects of the company’s bleach. He hit upon this innovation because collateral damage indexes a disparate group of experiences that can be learned from and provide the learning necessary to make effective decisions.

Now let’s turn to software that employs indexing language. In any given industry, there are at least five to ten experts who know what a decision maker needs to know in any given situation. These experts might be veteran employees of the company, outside consultants, and others in a field who possess great insight into how to do crucial tasks. They can share stories about how they solved common problems and capitalized on common opportunities (i.e., a story about when faced with a decision about whether to violate their strategy of organic growth to make the perfect acquisition, they decided to stick to their strategy). These stories can be videotaped and translated into software using indexing language. For instance, the indexing term we referred to earlier, “collateral damage,” captured the inherent goal conflict for a given problem. An example of organizational collateral damage is downsizing the workforce because of the tough economic climate but harming morale by doing so. Once all this is effectively indexed, the software can automatically “play” a relevant story when a decision maker faces a situation triggered by the indexing or goal conflict. The software “recognizes” this conflict by the information that has been input and provides stories/suggestions from the relevant expert. This expert shares what actions worked and what didn’t when he had to downsize and preserve morale.



10

INTRODUCTION

11

●

●

●

●

Keeping a talented but difficult employee on board or firing him and losing his expertise. Moving forward with a costly research and development (R&D) initiative that could have significant long-term benefits or spending the money on short-term strategies that will better satisfy Wall Street demands for results Taking the risk of pulling out of a moribund but marginally profitable market to devote more resources to a hot but uncertain emerging market Revamping a process that people like and are comfortable with or implementing a new, more efficient process that will require time and patience to get everyone up to speed

Most organizations make decisions about these goal conflicts without hearing what experts have to say about them at the time they need to hear it. Why did a seemingly sharp organization like Starbucks embark on a massive expansion plan that eventually required the company to close hundreds of stores? Why did the executives at General Motors invest in gas-guzzling SUVs as oil prices trended higher? If they had software that could adjudicate goal conflicts—the type of performance support software addressed in this book—they might have made much better decisions. To make a leap of faith and start developing this software, though, requires overcoming a set of obstacles that exist in most organizations.

Obstacles to Good Decision Making Cost and the status quo are two very different but very formidable obstacles. Companies are reluctant to invest in new software, especially



Think of all the difficult goal conflicts managers face:


when the old software seems to be working just fine (even though they want more capability from the system to improve organizational efficiencies). Information technology managers have a vested interest in keeping the old software—they understand how to use it, they may have had a hand in developing it, they paid a lot of money to buy it from a big company, it’s considered the industry standard, and so on. Even though developing the type of software we’ve described isn’t as expensive as a lot of people think, it still requires an investment that is threatening to some corporate executives. There are also other, subtler obstacles. For instance, some companies believe that collaborative decision making solves many of the problems we’ve identified. They believe that when groups of people (rather than single managers) are empowered to work together and reach consensus, their combined and diverse knowledge help them avoid bad choices and make good ones. While more experiences are better than fewer, from the cognitive standpoint, the collaborative process still has all sorts of flaws. There’s no guarantee that the people involved will have the right set of experiences. Group decision making tends to avoid failure by seeking middle-ofthe road solutions that are safe but not particularly rewarding. Goal conflicts are not adjudicated as much by the right expert knowledge delivered at the right time but by the group leader imposing his authority. Beyond this, “collaborative decision making” can be a misnomer. In reality, it’s a series of small individual decisions made over time and space (different offices in different locations) that eventually result in consensus. Earlier we alluded to General Motors’ bad decision to invest in gas-guzzling SUVs. No doubt this choice was a collaborative one that involved more than one person. But the ultimate decision came about because a number of people in different areas of the company



12

13

made poor choices about this subject in different areas of the company—the financial person didn’t do the right projections, the marketing person didn’t come up with a good promotion strategy, the R&D person miscalculated development time, and so on. Our point is that collaborative decision making should not be an obstacle to embracing a cognitive approach. Individual decision making remains the norm, even in companies with strong team-based structures. Another subtle obstacle is leadership that operates under misconceptions about how employees make decisions. These misconceptions are reinforced by much of the literature on the subject. Numerous books and articles suggest that people can make better choices by using logic and mathematics; that rigorous analysis and probability principles are key to improving the effectiveness of decision making. On the surface, this might make perfect sense. But in reality it runs contrary to what cognitive scientists have discovered about how people really arrive at decisions. In Winning Decisions: Getting it Right the First Time, authors J. Edward Russo and Paul J. H. Schoemaker suggest that people in business must approach decision making with a clear process and plan. The book offers four stages for doing so: Framing, Gathering Intelligence, Coming to Conclusions, and Learning from Experience. No doubt, Russo and Schoemaker have some valuable insights about decision making, and we fully endorse the notion of Learning from Experience. But like most authors of these types of books, they seem to subordinate gut reactions and doing what feels “right” to information gathering and analysis. As they write in the book’s first chapter, “People cannot consistently make good decisions using seat-of-the-pants judgment alone,” and “A systematic approach will lead to more accurate choices.” In truth, a systematic but logic-dependent approach will lead to choices that only seem more accurate. Diligence frequently dictates



INTRODUCTION


justifying decisions by exhaustively weighing the wrong pros and cons and gathering tons of poorly qualified data. Analysis and data are fine, but if managers rely on these resources exclusively, they’re likely to make a wrong choice. Each data point collected has many contextual factors that the system ignores. Having the right experiences or hearing about these experiences from experts at the right time can facilitate more effective decision making. Possessing software that continuously collects stories and information from experienced and savvy employees and indexes them so that they pop up onscreen in relevant situations is also crucial. When organizations possess a method of disseminating the right stories to the right people at the right time, they also can give their people the freedom to trust their gut in complex, confusing situations. With a strong experiential base, employees will make the right choices most of the time. This last statement assumes that an organization allows its people to make the right decisions. In some companies, decision makers aren’t allowed to make certain choices for political or other reasons. A given manager may know that he should do X. His experience says do X and so does his instinct. But he chooses to do Y because (i) he knows that doing X will upset his boss who has a vested interest in X, (ii) it represents an innovation that carries an unacceptable degree of risk with it, or (iii) it represents a break with tradition or doesn’t jibe with the company culture. Whatever the reason, if an organization won’t give people the freedom to make honest decisions, even the best software can’t prevent them from making wrong ones.

A Cognitive Science Expert, a Shipping Executive, and a Computer Science Professor Each of us comes at the topic of business decision making from a different perspective.



14

15

Roger is the preeminent researcher in the field of cognitive science, specializing in learning and memory. He has used his expertise to create learning-based applications for a wide variety of organizations. In this capacity, he has helped design software to facilitate organizational decision making. Dimitris provides enterprise software solutions for the marine industry via Ulysses Systems. The primary obstacle in ship management and maritime investing is the cost and risk involved with daily decisions, and his company has created software that reduces both dramatically. The performance support software the company has created for the shipping industry, called Task Assistant, provides a preview of the future of decision making. Elliot is a professor who studies the use of technology in education and developing software that considers the unique needs of individual learners. Because of this expertise, he is aware of the flaws in decisionmaking software and how these might be corrected Our knowledge of cognitive science, business, and software are what make this book different from others on this subject. We understand how people really make decisions in a business environment as opposed to how they are perceived to make them. We grasp how bad decision making can hurt a business and how good decision making can help it. We also recognize the difference between the standard decision-making software companies use and the potential of software they could use to satisfy the real requirements of decision makers. In short, we are acutely aware of what’s wrong with how companies make decisions and what could be right. “Could be” are the operative words, since few companies have taken advantage of the great decisionmaking tools presently available. However, one industry has capitalized on it, and throughout this book we will provide numerous examples of how it has helped this industry.



INTRODUCTION

16


While some of the shipping industry’s terminology and situations may not be familiar, the decision categories will resonate. Most industries confront the same types of issues—choosing between time and money, jury-rigging a problem for a short-term fix or revamping the entire system, facing a risky decision during a crisis,and so on. Perhaps even more to the point, we can share the problems and solutions as we developed and rolled out software designed to facilitate decision making within the shipping industry. For instance, we referred earlier to categorizing goal conflicts properly. Categorizing can be a tricky business, and we’ll explain how the process for replacing an oxygen and gas meter seems different from failing to do a risk assessment before shutting down a sea water pump and blanking it off. It turns out that both share the category of “importance of perceptions about safety.” Learning how to categorize properly—indexing in terms of goal conflict adjudication—is a crucial skill for decision making. We’ll pass on what we’ve learned from designing all types of shipping software. In the following pages, we’ll refer to companies and industries that have nothing to do with shipping, but no other industry is as advanced in their software from a decision-making perspective. Dimitris’ firm is constantly improving software through beta testing and other methods, aiming for the ideal technology proposed in this book. Nonetheless, no other organizational software approaches state of the art from a cognitive perspective. Therefore, by using this industry and its software as a paradigm, we can learn not only from the solutions but avoid the mistakes of the pioneers.



Shipping as a Decision-Making Paradigm

INTRODUCTION

17

This book is divided into three sections. The first section, “A New Decision-Making Model,” describes the cognitive science principles governing our point of view. It details how people really make choices in business situations, and how a concept such as case-based reasoning is critical when designing software to facilitate business decisions. The second section makes “The Software Argument.” It explains how software should be designed in order to maximize what cognitive science knows about the decision-making process. This isn’t a technical essay on the nitty-gritty of design, but a higher level approach to the issues that such design should consider, such as how to collect the key stories from the experts and make them accessible to decision makers when they need them the most. The third section, “Implementation,” consists of the book’s final two chapters and looks at the possibilities and pitfalls of putting a performance support software system into practice. We’ll focus on the issue of “usability” and how to overcome the common obstacles to putting this type of system into practice. We’ll also examine the opportunities that these systems offer companies and how to capitalize on them, both now and in the future. Understanding the cognitive science concepts and software possibilities presented in these pages will help organizations improve how key employees make choices. More specifically, here are four benefits: ● ●

●

Avoid bad decisions that are the result of rational analysis only. Make better hires and promotions by matching people’s experiences with decision-making requirements of various positions. Increase the odds of effective decision making during crises by providing just-in-time stories and advice from experts.



Book Methodology: Structure and Benefits


●

Help executives make better right-versus-right decisions through goal conflict adjudication.

The concepts that are conveyed in this book should result in these benefits. If companies were to revamp their software systems with these concepts in mind, the benefits would be that much more significant. Our hope is that these concepts will create a shift in how organizations approach the notion of decision making. To help start this shift, let’s look at the value of case-based reasoning as the foundation of effective business choices.



18

A New Decision-Making Model



Section I




Don’t Follow the Rules, But Do Embrace Case-Based Reasoning

Managers are constantly faced with decisions big and small: should they downsize now or wait until the end of the fiscal quarter to make that assessment? Should they endorse a new team-building protocol? Should they acquire a company? Should they respond to a customer complaint by talking to the customer personally, delegating the job to someone else, or ignoring it? While some decisions are simple and easy, most are not. The complexity of many choices confronting business executives cannot be underestimated. Even decisions that may seem simple on the surface often have underlying complexities. For instance, a direct report tells his sales manager that a customer is upset that the company didn’t clearly communicate that there would be a brief delay in shipping them a quantity of product. The direct report, who has only been on the job for a few months, is upset and recommends that both he and the sales manager visit the customer to placate them. This is a reasonable response, but the sales manager is a veteran of the business and has dealt with many similar customer complaints. She knows that



Chapter 1


certain customers want to vent and that directly engaging this type of customer over minor matters generally results in unproductive arguments and bogs everyone down with trivial details. She finds it better to acknowledge the problem via e-mail and do nothing else; she grasps the underlying issues and her experience tells her the best course of action. In making this decision, the sales manager doesn’t consciously remember all the times she visited a customer in response to this type of complaint and the situation went from bad to worse. Nor does she consciously recall each time she ignored a complaint and the situation resolved itself. Instead, she responds immediately to her direct report’s suggestion by saying, “Here’s what we’re going to do.” She knows instinctively what the right decision is. That’s because her unconscious mind works at lightning speed and has reasoned, based on a variety of similar and well-categorized cases, that doing nothing is sometimes the best option. Every organization would benefit if they relied on case-based reasoning more than they currently do. Unfortunately, many organizations are overly reliant on policies and rules that are far less effective from a decision-making standpoint. Let’s contrast the two types of decisionmaking methodologies.

Case-Based Versus Rules-Based: Relevant Experience Versus Generic Guidelines Case-based reasoning is the unconscious or subconscious process whereby we draw on relevant past experiences (or “cases”) and use them to make a good decision. A current situation reminds us of a past experience, and that experience provides us with guidance about what to do . . . or what not to do. It is not the conscious, logical approach



22

23

to cases that is taught at many business schools. It happens naturally. Think about how people drive a car. They’re moving down the street, when out of the corner of an eye they see a child dart into the crosswalk, or traffic is heavy on their usual route to work so they take an alternate route, or it starts raining and they put their wipers on at just the right speed to clear the windshield. What happens in these drivers’ minds is that a given situation reminds them of a similar situation or series of situations in the past, and they make an effective decision based on those experiences. There is no conscious analysis of how much space exists between themselves and the child; they don’t thoughtfully weigh the pros and cons of staying on a crowded road versus taking an alternative route. With extensive, relevant experience, their minds do this work automatically—and correctly. Of course, business decisions can be much more complicated than those faced by a driver of a car. Let’s consider this ambiguous, uncertain, and potentially volatile situation: a senior executive of a large food marketer learns that thousands of people have become ill after eating his company’s product. It is unknown at this point if the company is guilty of negligence, if another party (i.e., a supplier) is responsible, or whether some other factor was involved (i.e., the product sat in a warehouse that lost power for twelve hours during unusually warm weather, resulting in spoilage). Complicating matters, this senior executive is receiving conflicting advice from his company’s lawyers and public relations (PR) agency: the lawyers want him to remain silent until all the evidence is in, the PR people want him to be proactive. While there’s no obvious right answer, this senior executive can still rely on case-based reasoning to help him determine the best response. If he has extensive crisis management experience and is reasonably



CASE-BASED R EASONING


intelligent, he’ll likely be able sense what his best option is. “Sensing” may not sound like reasoning, but that’s exactly what it is. How does a mystery writer know when to introduce a plot twist, or an all-star baseball player decide when to swing at a pitch? While there may be some conscious analysis involved, most of the decision is intuitive. The baseball player senses that a fat pitch is coming right over the place and swings hard. The writer has a feel for her plot and knows she can catch readers off guard with a surprise development just when they probably think they have everything figured out. They’ve made these decisions before, will be reminded of these past situations (where they both succeeded and failed), and will opt for actions that will increase the current odds of success. Now let’s contrast case-based reasoning with rules-based logic. Every organization has numerous regulations, policies, best practices, protocols, processes, and so on. In some instances, these rules are stated explicitly. Various paper and online handbooks detail firing and hiring policies, operating procedures, and more. A customer service representative might be handed a list of “dos and don’ts” to use when talking to customers on the phone. A manager may receive explicit training about what to do in common situations such as resolving conflicts, managing diverse teams, and so on. This manager may also receive implicit messages from his boss about “how things are done around here.” These “things” can range from how the company develops their direct reports to how it conducts performance reviews to how it handles customers. All these rules guide people’s decision making. An executive is aware that it is company policy to create diverse teams—employees young and old, male and female, and racially diverse. Therefore, when an opening comes up for membership on a high-profile team that has been charged with restructuring a division, an executive will decide to select the employee for the opening who represents the missing diverse component.



24

25

Without a doubt, these policies, processes, and other rules appear to provide good guidance for decisions. They are based on collective or conventional wisdom; they have probably been demonstrated to be effective in other situations. Yet as a decision-making tool, they’re flawed for two reasons: (i) they are based on imperfect case generalizations, and (ii) they lack the nuances and insights that come with personal experience. Rules are nothing more than generalizations that emerge from past experiences. They lack the mind’s facility with cases, however, because they’re generalized rather than specific to a given person in a given situation. Hence, you have a rule such as, “Never talk to the media immediately after a crisis occurs.” It is based on a number of cases in the company’s history where an executive spoke immediately after a crisis and his comments resulted in negative publicity. Though situations may arise where it’s sensed that a prompt public response is exactly the right thing to do, the rule will prohibit an executive experienced in crisis management from sensing the right thing to do and acting on that feeling. Rules usually fail to consider all the variables, largely because rules are derived from science. In the lab, conditions are fairly static and variables much more limited. If you mix chemicals A and B, you will get precipitate C every time. In the world of business, however, conditions change frequently and new variables are constantly entering the picture. In financial risk management, for example, investors rely on statistics to predict to the future and determine their investing decisions. They use statistics about mortgage failure, for instance, to predict the risk involved in an investment. But these statistics can be misleading, since what caused mortgage failures in the past probably won’t be the only causes of failures in the future. In fact, it’s fair to say that rules are written or communicated in such a way as to apply more accurately to past issues than to present





ones. When the rules were written, no one could anticipate the changes and variables that would be impact in similar situations in the future. Thus, the old rule that companies should be “the first with the most” in a given market. Microsoft has rendered this rule obsolete, allowing others to be the first and to dominate a market for a given period of time and then sweeping in and taking over (either by purchasing the pioneering company or using their muscle to shove competitors aside). Rules often take the form of strategic imperatives within organizations and limit the ability to draw from a variety of cases. General Motors decided to expand its SUV line because this expansion was a key element of their strategy. Goldman Sachs decided to invest heavily in sub-prime mortgages because their goal was to develop a reputation as an innovative financial firm. We can assume that diversely experienced people within both organizations suspected that these decisions were the wrong ones, but the weight of “strategy” buried whatever objections they might have made. Experience really is the best teacher. An experience is often emotional, and thus has a greater impact than a purely cognitive rule. The best global leadership training programs have learned that there is no substitute for sending trainees to other countries to live and work as part of the training. Despite a company’s efforts to create global leadership best practices, such practices aren’t sufficient when it comes time to run a business in, for instance, China or India. Best practices aren’t internalized the same way that experiences are. A company may tell a new country manger that when doing business with an executive in that country, it’s important to have three preliminary meetings before even talking about a deal. Experiences, though, can help people personalize this best practice and adapt it to their own circumstances. They may need to make a few mistakes and be embarrassed a few times before they master the subtleties of how to do business effectively in this country. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


26


27

Why do experienced business professionals make poor decisions? It happens all the time. In business publications there is a story every week about a poor decision made by a thirty-year veteran of some company or industry. Tellingly, there are stories about CEOs who were highly successful at one point in their careers, and then made horrendous blunders later on. In Dartmouth professor Sydney Finkelstein’s book Think Again, he discusses how Bank of America chairman Ken Lewis attempted to replicate the Citigroup “financial supermarket” strategy. Lewis had seen how successful this strategy had been at Citigroup (at least for a time). Based on his experience, it seemed to Lewis that it would also work for Bank of America. In an interview on the Breakout Performance Web site (http:// breakoutperformance.blogspot.com/) about his book, Finkelstein said that Lewis “based his decision making in 2008 on misleading past experiences.” Finkelstein noted that Lewis used experiences at Fleet and MNBA as strategic models for Bank of America; they had made big acquisitions and grew bigger and more profitable. Thus, he acquired Countrywide for $4 billion and Merrill Lynch for $50 billion in the same year—acquisitions that were problematic. Experience may have hurt rather than helped Lewis in this instance. It’s not that having experience is bad; it’s that Lewis may have made a decision based on experiences that weren’t applicable to this situation. Sometimes we become slaves to a narrow band of experience. We’re not sure whether this happened to Lewis, but it does happen to a lot of leaders. CEOs and other senior executives, by definition, have enjoyed a great deal of success. In some instances, however, this success has been the result of specialized skills and experiences. They are brilliant at one thing and do it very well. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


Experience Is Just the Ante to Get in the Decision Game


They ride this ability to the top of an organizational chart, but they have never felt the need to or been coached to broaden their experiential base. Consequently, their unconscious decision-making mechanism relies on their narrow experience range for making all decisions, even those that are outside of that range. To the unconscious, this makes perfect sense. In the real world, though, it results in mistakes. In a more personal context, we are all in the grip of unconscious decision making. Most of us are prone to make cultural etiquette errors when we travel abroad. We assume that other cultures are like our own, or are at least similar in many respects. More to the point, we carry around unconscious scripts that determine how we say “hello” to someone we’ve never met before or how we communicate when we’re talking to a potential business partner. It is the natural result of numerous experiences that tell us how to act in similar situations. If we follow these unconscious scripts unquestioningly, though, we can make poor decisions about how to greet people, how to talk to them, and so on. Subconsciously relying on our past experiences, we shake hands instead of bowing or we interrupt another speaker to make a point (forgetting that to do so is a cultural taboo in another country). Even if we’ve been told to bow and not to interrupt, the unconscious script is sometimes so deeply embedded that it overrides those instructions. It is only when we are confronted with a poor choice (i.e., someone tells us we’ve insulted a foreign dignitary) that we are motivated to deviate from our reflexive choices. John Sculley offers another example of the impact of past experience on decision making. Sculley became CEO of Apple Computers after a highly successful stint as CEO of Pepsi. A superb marketer at Pepsi (his “Pepsi Challenge” concept helped the company take market share away from Coca-Cola), his methods proved less effective at Apple. He made a number of poor decisions, including introducing too many products with similar features and trying to compete for



28

29

business customers with IBM. It stands to reason that Sculley’s experience at Pepsi taught him how to compete with a market leader; he probably assumed that the strategy he used to counteract Coca Cola would work with IBM. While Sculley knew how to grow a certain type of business, he didn’t have the requisite understanding to grow Apple. His experience led him to assume that he was in the computer hardware business, when in reality he was in the computer software business (at the time, there was a lot more software on the market that was compatible with PCs than with Macs). He was making decisions based on a false assumption dictated by his relatively narrow range of experience. In many organizations, people are given decision-making responsibilities based on seniority and specialized performance. In other words, promotions go to the individual who has put in his time and developed knowledge and skills in a given area such as sales, marketing, operations, or finance. People are generally not promoted into these positions based on their breadth of experience, and that’s a problem from a case-based reasoning perspective. To make effective choices, especially complex ones, people should have the capacity to draw on a variety of cases. For instance, after his Apple experience, John Sculley was in a much better position to help grow an organization because not only had he learned what to do in the beverage industry, he had learned what not to do in the computer industry. Both success and failure contributed to his store of cases. Beyond experiential diversity, the ability to know (whether consciously or unconsciously) what cases are applicable to a specific situation is key. In the maritime industry, the sailors known as “old salts” don’t just have a lot of different experience, they possess the savvy to apply the appropriate experience to a new situation. If an emergency pops up or a problem is particularly difficult, the old salts know what to do.





Some businesspeople are like these old salts. They possess great business instincts and recognize what to do when facing both problems and opportunities. As we described earlier, they sense what decisions will be effective, and their intuition is most often correct. We look at how businesses can help their people use this sensing ability in decision making, but first we need to address a harsh reality: there aren’t enough diversely experienced people to go around.

Translating Case-Based Reasoning into Organizational Knowledge Organizations lack the financial resources to stock every decisionmaking position with savvy veterans, and there aren’t enough savvy veterans to fill all these spots even if companies have unlimited resources. As a result, companies can’t take advantage of case-based reasoning through hiring and promotion alone. While they can (and should) make every effort to hire and promote people with a wide range of experience, they need an alternative method for capitalizing on casebased reasoning from an organization-wide standpoint. As we’ll see later on, technology has advanced to the point that any organization can capture the key cases relative to major decisions and make them accessible to its employees in a timely fashion. Consider how a company might benefit if their decision makers had access to the most relevant stories related to the choices they faced. Before choosing a supplier, a purchasing manager can hear stories from purchasing experts about mistakes they made in selecting suppliers in specific situations, as well as their smart choices. Financial managers can hear stories about the effect of cutting travel and entertainment budgets on company morale and on the best approaches to making these cuts.



30

31

Notice that we used the word “stories”—not “lectures,” “checklists,” or other means of communicating information. Well-told stories, offered at the right time and directly related to the immediate situation, aren’t a substitute for hard-won personal experience, but they’re the next best thing. Stories are engaging and can have a vivid kick that makes them memorable. In addition, stories have embedded indexing mechanisms that are easily understood and far more sophisticated than the typical ways organizations attempt to communicate knowledge. The shipping industry provides us with a good example of this. In the shipping industry, the knowledge to make important decisions (whether to take a cargo to the Far East or remain in the Atlantic Basin) is not contained in a set of ship’s rules or an industry handbook. Instead, this knowledge resides in the minds of commercial managers. The best, most experienced captains may be able to handle many decision-making situations based on their personal experiences alone, but the majority of decision makers require relevant stories from others. People who work in shipping tend to be receptive to stories since apprenticeships and other forms of story-based experience transfer are common on most ocean-going vessels. For this reason, we (Dimitris) interview the people with crucial knowledge in major decision-making areas to collect their cases and incorporate them into software. For instance, we collect stories related to “managing corruption” decisions. In the worldwide shipping business, if you want to do business in a variety of countries, you need to figure out how their particular corruption systems work. In one country, we discovered that if you want to buy a ship, you purchase it through local brokers from stateowned oil companies. A system existed in which each broker had a turn at managing the sale of a ship, and this broker would then pay off the seller and ensure that everyone was happy. Interestingly, you could offer more money for a ship than a competitor offered and still lose out if you didn’t deal with the right broker in the right way.





These stories about managing corruption are invaluable for ship officers and executives when it comes to all sorts of decisions about doing business in foreign countries. For someone who has never worked with a particular country or who is trying to do a different type of deal in a new area, these stories provide guidance that isn’t available anywhere else. Theoretically, organizations could capture these types of stories on their knowledge management systems. In reality, these systems are set up to capture not stories but rules—the story is discarded in favor of the lesson learned (best practices, principles, guidelines, etc.) A company’s software may capture expectation failure—a description of mistakes made, with a warning not to make them again—but these aren’t indexed so as to conveniently pop up on a computer screen just when a decision maker could benefit from hearing about the failure. Knowledge management systems are proficient at data mining, analyzing reams of facts and figures to identify trends and probabilities. Correlating this data, therefore, is often substituted for stories related to the cause and effect of a specific data point, such as why 22 percent of the market switched from one toothpaste to another or why in the past year eight workers had been injured in certain types of factories. Even if these data-based systems contain valuable information relative to decision making, it is often difficult for the right people to access them at the right time. Even worse, the valuable information is frequently presented in boring ways. Instead of engaging users with real people telling real stories, the data is hard to get through and is out of context. Corporate knowledge should be a living organism within the organization, evolving over time. Old salts’ knowledge should be captured and presented in compelling ways, such as having them telling stories on camera rather than in unreadable written summaries. There should be an ongoing effort to add new stories and replace ones that are no



32

33

longer relevant. This means identifying the experts who have experiences to share and making sure their stories are captured before they leave the organization. This last point is especially important now, given the volatile employment picture at most companies. Years ago, when the savviest employees often stayed with a company for thirty years or more, these stories could be accessed more easily. During lunches or drinks after work, these veterans told their stories while direct reports and other colleagues sat around and absorbed them. Now, not only have many older experts been downsized out of the organization, but the ones who remain may not be so readily accessible. Many companies have been acquired once, twice, or three times until they are part of huge global organizations. People can no longer shout down the office hallway for help when they face a difficult decision. The person with the knowledge they need may be half way across the world; he might not speak English, and because of functional rivalries or other forms of siloism, he may not be willing to tell his stories.

Why It Seems Logical but Doesn’t Make Sense Most organizational leaders believe that they make well-reasoned decisions and provide their people with the training and tools to make sound, logical choices. We’re not questioning the sincerity of that belief, but the assumptions on which it rests. Consider that structure and order are important to most business executives. Rules help enforce structure and order. In a highly uncertain, unpredictable, global environment, companies depend on policies, processes, training regimens and the like to control the chaos that is always lurking nearby. While we do not advocate anarchy, we know that a rules-driven culture has difficulty giving people the freedom to trust their instincts. It prefers a false certainty to following a hunch. On the surface, this





creates the impression that a decision is based on cases and is the logical outcome of case analysis. But in reality, it is case-based in appearance only. For instance, budgeting appears to be a relentlessly logical financial function, yet decisions about who gets money are often highly subjective and ultimately result in money not going to where it will do the company the most good. Nonetheless, managers make logicalsounding arguments for their budgets—arguments that often rely on mathematical computations that look good on paper. Let’s illustrate this point with a story. Jack is the CEO of a small organization. His new chief financial officer (CFO), Tim, arrives with a budget for the coming year based on his financial projections. Jack looks at the budget and asks Tim how he arrived at the numbers. Tim responds that he went through their list of customers and prospects and next to each name noted the projected revenue—the amount of business they were asking for from each. Tim then used probability theory to estimate the odds of getting what they were asking for. For Prospect A, Tim said they had a bid out for $1 million worth of business, and given all the information he had, he estimated that there was a 50 percent chance they would get that business. Therefore, he put down a projected $500,000 next to Prospect A. Jack told him this made no sense. “With Prospect A, I don’t know if they’ll give us their business or not. But I do know there’s zero probability we’ll get $500,000. We’ll either get all of it—$1 million—or nothing at all.” If Tim were to use case-based reasoning to create his projections, he would rely on his experience with various customers and prospects and go with his gut. He would think about his interactions with Prospect A, what he’s been told about him, about other prospects in the past who were in similar situations, and then make a decision about whether he believed they would get the business. This method may



34

35

seem completely irrational and lacking in any sort of logic or experiential base, but in fact, the decision Tim would make would have a series of relevant cases backing it up. From an organizational perspective, however, these cases aren’t always visible—many might exist only in Tim’s subconscious—and so it may look like Tim is just pulling the decision out of a hat. Given the reality of most organizations, Tim isn’t going to get away with making a major financial decision and telling his boss that the reason he made it was because “it felt right.” He needs to justify his decision rationally and objectively. This can be done if Tim reflects on what his gut is telling him and realizes how his past experiences are shaping his instinctive decision; he can present a rationale for his decision if he identifies and articulates the subconscious cases that are shaping his choice. Similar to organizational policies and procedures, training is designed logically; it prepares people for the decisions they’ll face, especially the difficult ones. Typically, a training course or regimen evolves from other people’s experiences. Leadership training programs, for instance, are based on leadership best practices; trainers endeavored to find out what makes a great leader and attempted to incorporate that knowledge into everything from classroom sessions to role playing exercises. We’re not against training. It can provide people with the basics for doing certain jobs, for learning how to use new software, for thinking in new ways about complex problems. But it doesn’t foster case-based reasoning. Instead, what most training becomes is a futile effort to compress learning time. It attempts to teach people in three weeks how to learn to do a job that took an expert twenty years to learn. Because training often relies on cases, people assume that it is synonymous with case-based reasoning. In fact, it delivers cases in an emotional vacuum. The dry text of a case is experienced far differently—and far less effectively—than going through a real-life situation. Every case





is emotional, and when it’s experienced with feeling, then it is absorbed and indexed in a retrievable way. Being fearful, elated, anxious, and proud all embed and categorize the experience in people’s minds in a way the classroom can’t duplicate. If you’ll recall our example in the previous chapter, the ship captain going through the Suez Canal can be taught in training that he shouldn’t just stop the ship if it catches on fire. But what about the emotional impact of watching half the engine room catch fire and the rest being sprayed with fire hoses? If the rule about not stopping in the Suez Canal was the only rule someone was taught, and if it could be applied frequently in many different situations, the captain would remember it. But during this captain’s training, he’ll be taught a hundred different things, and this one rule will be lost in the shuffle if there’s no emotional experience behind it. Without an emotional component, experiences are indexed poorly and recalled inappropriately. Airline pilots receive the best training money can buy, but if they lack the requisite mix of experiences, they are likely to make poor decisions. I (Roger) took a regional jet recently on a calm day. We were flying above the clouds when all of a sudden the pilot turned left. Because I’m a veteran flyer, I knew immediately that the plane should not be turning left, that something was wrong. We flew into a thick cloud and the plane dropped like a stone. People were thrown out of their seats and banged their heads on the plane ceiling. Fortunately, the pilot regained control of the plane and we managed to land safely. Once on the ground, the airline announced that we had encountered “clear air turbulence” and there was no way to predict or avoid it. I knew, however, that the pilot had made a mistake; he had turned left and gone into a cloud (not clear air), where turbulence is more likely to be found. When we exited the plane, I saw the pilot. He looked like he was about sixteen years old. He obviously lacked experience, and because of that inexperience, his training was insufficient to prevent him from making a bad decision.



36


37

Ludwig Wittgenstein, an early twentieth-century philosopher, said that the essential things to understand about thinking were the three Bs: Bed, Bath and Bus. What he meant was that, when we’re in a relaxed, semiconscious state—when we’re falling asleep, relaxing in a bath, or riding on the bus—our mind is operating at peak capacity. It’s a misconception that our minds are at their best when we’re concentrating on solving a problem or trying hard to come up with a brilliant idea. When we’re consciously making an effort to think, we aren’t using our capacity for case-based reasoning. It is when we give our minds free rein to go in the direction they want that they produce insights and fresh ideas. Consider why a young baseball player becomes increasingly proficient as he makes his way through the minors and into the pros. Over time and with experience, he becomes a better hitter. It’s not because he has analyzed his swing, and every time he’s up at the plate he applies his analysis to his batting stroke. It’s that his mind accumulates experiences, including failures, and it filters this information unconsciously to his eyes and muscles and they adapt accordingly. Just as baseball players make better decisions at the plate over time, business people make smarter decisions at work with the right mix of experience for the right situations. We’ve italicized these words because experience alone isn’t enough to be a smart decision maker in every situation. Many highly experienced CEOs have made bad decisions in recent times—going on acquisition binges when they should have cut costs (and vice versa). A broad experiential base, however, serves business managers well in many situations, though not in the commonly assumed way. Perhaps there are business people who sit down at the end of each day and catalog what they’ve learned, but this isn’t how they become



Provide Sensing Opportunities


better decision makers. Their mind indexes their experiences during down times, labeling and storing experiences for easy retrieval in analogous situations. Right before they fall asleep or if they wake up in the middle of a dream, they can glimpse this process at work—their mind is working at high speed, creating possible scenarios and filing them for later use. They “see” this activity in these moments, though they’re not quite sure what is going on. Companies need to encourage people to tap into this cognitive resource. They should encourage employees to trust their gut, to do what they sense is right. This doesn’t mean that everyone should ignore facts or analysis, but analysis should be used to test an instinctive reaction; it should not be the sole determinant of a choice. A CEO who responds to a feeling that he should buy a company even though analysis reveals that the target company is on the verge of bankruptcy may be making a brilliant choice or an ill-considered one. Our point is that CEOs and other employees need to heed these feelings, subject the potential choice to scrutiny, and then decide if they want to go with their gut. Sometimes, though, no amount of objective analysis will surface the subconscious thoughts that produced a gut feeling. A salesperson may instinctively feel that a customer needs him to stop by that day and take him out to lunch. There may be no rational way for the salesperson to explain this feeling, but the odds are that it has emerged from case-based reasoning. In those semi-conscious states, his mind has recalled other situations in which customers were upset about something but never said anything about it or when they didn’t call or e-mail the supplier as often as usual, or when their facial expressions seemed to be hiding something. The salesperson’s mind reasoned that something was amiss and that he needed to make a personal visit to the customer to set things right. It is difficult for a salesperson to justify this customer visit in most companies, especially when the customer is located in another part of



38

39

the country, and he has to incur travel and lodging expenses based on a “feeling.” Yet, if organizations honored these feelings, their people would make more effective decisions. When we talk about relying on instinct or allowing unconscious thoughts to surface, some business people assume we’re encouraging brainstorming sessions. Unfortunately, organizational brainstorming or other formal creativity-generating approaches tend to shut down case-based reasoning. Typically, a group sits around a table and exchanges ideas through a civil discourse. The unwritten protocols of these sessions, however, prevent individuals from saying what comes to mind “naturally”—what their subconscious has pulled from a series of relevant cases. The spontaneity of normal one-on-one conversations that allows people to say the first thing that comes into their head doesn’t exist in most brainstorming meetings. People censor themselves. They don’t want to say something stupid. They don’t want to offend anyone. They don’t want to articulate an idea that they’re not completely sure about. On top of that, it’s bad form to interrupt. This means that people can’t articulate their ideas as they spring up, and when they have to wait they often decide that their idea was no good or that they’ve talked too much and should let others have a chance to speak. Brainstorming is a social activity, and social activities aren’t the best ways to capitalize on case-based reasoning. That’s why brainstorming sessions generally are unable to live up to their mandate to produce creative ideas. A much better alternative is for organizations to encourage people to take policies, processes, and other rules with a grain of salt. When companies give people permission to bend or break rules if the situation demands it, that’s when they follow their instincts or do what they sense is the right thing. No longer slaves to generic guidelines, employees make far better choices when they can draw from their experiences and remind themselves of a previous case relevant to a particular





situation. This is especially true when employees must make immediate decisions, lacking the time to consult with experts, talk to a boss, or investigate their options. They may be making a sales pitch and have to decide what to say to close the sale. They may be facing a choice between two vendors and have to pick one before the day ends. They may be dealing with a crisis and having to choose their words carefully when talking to the media. If they’re experienced professionals, they’re probably much better off relying on their own intuitive responses than on corporate guidelines or best practices. If the notion of encouraging people to take rules with a grain of salt seems dangerous, consider that most employees feel stuck between a rock and a hard place because of these rules. They know that if they follow all the rules to the letter, they won’t make effective decisions. They also know that if they ignore the rules, they’ll receive poor performance reviews and face negative repercussions, including being fired. Companies should follow the lead of professional coaches, who recognize that their players on the field or on the court are sometimes in a better position to make decisions than the coach can by watching the game from the sideline. These coaches may not like it, but most allow their quarterbacks to audible and change the designed play or permit the point guard to improvise because he senses a chance to drive to the basket rather than wait for the diagrammed play to develop. Obviously, if the rule-breaker makes one mistake after another and loses games as a result, the coach will put his foot down. In business, too, managers aren’t going to give their people unlimited freedom to ignore all rules. Giving a reasonable amount of freedom to do so, however, is a good business practice. Rules really are made to be broken, and organizations that give their people the opportunity to break them on occasion will benefit from the case-based reasoning that emerges in these circumstances.



40

Why It Matters: Greater Productivity, Profit, and Purpose

Consider the costs of one thousand bad decisions or the gains from one thousand good decisions at any given time. Some decisions are major, such as making a move to acquire a company, and some are relatively small, like revamping a policy in an effort to improve employee morale. The cumulative impact of all these decisions is enormous. Too often, organizations overlook the value of having an effective decision-making process in place. Obviously, they recognize the value of having astute decision makers in top positions who can make wise choices when a lot of money is on the table. What they sometimes fail to recognize, however, is the value of a sound decision-making philosophy—a creed of case-based reasoning that guides many types of choices throughout the company. When case-based reasoning guides employee thinking, the benefits accrue up and down the line. It enables an employee to make the best choice in a confusing situation. The employee is able to choose from two seemingly equal alternatives, each with a potentially positive and negative impact. It means that employees can make good choices quickly, especially during crises, when there is no time to do research, consult a series of experts, or have a series of meetings. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


Chapter 2


On the other hand, when rules-based decision making predominates, all sorts of mistakes are made. Perhaps the most egregious example is when a leader puts unwarranted confidence in the rules that govern his thinking and takes a bad risk. To help communicate the benefits that come with case-based reasoning as well as the benefits that are lost with rules-based thinking, let’s examine two recent examples.

Two Stories: A Shipping Disaster and the Restructured Company During the economic downturn in 2009, a shipping company financial executive decided not to make repairs on one of its ships because the repair estimate exceeded the company budget by 25 percent and would cost more than $1 million. He determined that the repairs would have to wait for the next fiscal year, when the budget would allow for such an expenditure. The financial executive’s decision was based on rules-based logic: a budget was a budget, and this figure exceeded the budget. Furthermore, because of the difficult economic climate, spending money on repairs seemed imprudent. Keeping the ship in service (which was possible even if repairs weren’t made) appeared to make sense, since it could keep earning money for the company in a time of declining revenues. The fleet manager, however, overruled the financial executive’s decision. The fleet manager, a case-based reasoner, had experienced many economic declines, and he recognized that the best time to take a ship out of service for repairs was when business was off, as it would likely be idle for most of the year. In addition, he reasoned that it was far better to have the ship ready to go when the economy picked up. This fleet manager knew from hard experience that to have a ship out of service during a boom period could be a financial disaster. Thus, this



42

43

manager adjudicated two conflicting goals—to stay within budget versus to repair the ship at an opportune moment—and made the right decision. Unlike many other shipping companies that made decisions similar to what the financial executive advocated, this one reaped millions of dollars in increased revenue because it had the ship ready to go when the economic turnaround began. Case-based reasoning not only helps businesspeople make good decisions but also helps them make them at the right time, as the following story illustrates. A CEO decided to restructure his company to deal with the economic downturn and reduced liquidity of his client base. As a veteran CEO, he demonstrated remarkable patience in embarking on this restructuring. Despite the recommendations by his board and other advisors that this restructuring take place a year earlier, the CEO reasoned that companies that make the sort of premature cuts he was contemplating often regret them. He grasped that, while a restructuring may provide short-term relief from the pressure to reduce costs, it also could do more harm than good. Having worked for organizations that had made premature cuts in similar circumstances, he understood that reductions would result in the loss of at least two or three clients since the company would be unable to provide these clients with an acceptable level of service. Just as importantly, at the time, he was courting one client in the hope that it would be willing to invest in the company. The CEO sensed that a restructuring might send the message that the company was in trouble and not a worthy investment. Even though he couldn’t articulate how he knew this to be true, his instincts (shaped by his experiences) told him that it would be the result. Therefore, he postponed the restructuring for more than a year. When he implemented the program, the company was in much better financial shape, had established a partnership with the previously mentioned client, and reaped maximum benefits from the cuts that came with the restructuring.



PRODUCTIVITY, PROFIT, AND PURPOSE


As these examples indicate, the benefits of case-based reasoning are many and varied. Case-based reasoning avoids blunders based on narrow experience; provides direction for structuring effective tactics (i.e., sales presentations); and gives leaders a way to resist easy options and stick to what they sense is the right strategy. These benefits will be especially noteworthy for processes where the process steps and goals are known. For instance, an organization may know exactly what types of customer service issues are likely to arise, what responses have been successful and unsuccessful over time, and how these responses relate to a specific customer goal. As a result, this company knows the type of expert with the type of experiences is ideal for customer service positions. They know what cases an expert or nonexpert needs to be aware of at the most common decision-making points. In this way, they make it likely that the customer service representative will have access to or be reminded of the right case at the right time to help make a good decision. Even when process steps and goals aren’t clear, case-based reasoning provides benefits. For instance, an organization may be launching its first group of cross-functional teams. They have never had this type of team before and no one in the company has stories about how to gauge their success. Further, this company may not have specific goals for the teams—the hope is that they’ll foster innovation and bring together more diverse perspectives for problem solving, but there is no clearcut goal. A case-based system can gather stories from experts in other organizations to provide decision-making guidance. The company can use these stories even though they may not be a perfect fit with the organization-specific decisions related to these new teams. Nonetheless, the stories will provide some direction as the company moves forward and people develop their own, organization-specific cases. Now let’s look at benefits from a more practical standpoint, identifying the six specific advantages case-based reasoning organizations possess.



44


45

Most people in organizations believe that they are being logical when they make decisions. In their minds, they’re doing what is right based on what they know. Unfortunately, their reasoning may be based on an irrelevant or false case. Research and development (R&D) comes up with a line extension for a cleaning product, which is designed to capitalize on brand strength and the market need for a product that more effectively cleans hard-to-remove stains. The product manager, however, decides not to pursue the line extension. He makes the argument that now isn’t the right time to introduce an extension—the economy is bad, the competition is attacking on another front, and so forth—and he probably believes it. It’s likely, however, that he believes it because four years ago, he was responsible for a line extension that failed miserably. Even though the situation has changed, he reasons based on that one case. If that case isn’t relevant—if the line extension failed for reasons that don’t exist in this current situation—then that single experience is pushing him in the wrong direction, even though it seems like the right one. Experts unconsciously rely on a wide group of cases and pull ones from their memories to match ones they are currently facing. An employee who lacks this expertise, on the other hand, is likely to reach back in his mind and pull out a case that is only superficially similar. Nonetheless, it seems to match, and without anything else to go on, he becomes adamant about letting it guide his decision-making process. This situation is analogous to how parents make decisions about their children. The first-time parent, for instance, believes that because she has been a parent of that child for five, ten, or fifteen years, she’s an expert. So she develops a theory that you should never correct a child because it might damage his ego. Perhaps this mom had an overcritical parent and felt her ego was damaged because of too much criticism.



Benefit 1: Brings Objectivity to the Process


Whatever the reason, one case makes her feel that she is an expert in this area. No doubt, she is sincere in this belief. Even though her child is obnoxious, lazy, and offensive to others, she refuses to criticize his behavior. To an outside observer, she isn’t making good parenting decisions. But her belief in this one case is so strong that it overrides common sense. Earlier, we noted that experience provides decision makers with cases to reason from, but here we’re suggesting that an overly narrow experience base can result in poor choices. One case does not an expert make. Even if an experience was powerful and memorable, it probably isn’t applicable in many other situations, even if those situations seem similar to that first one. A diversity or depth of experience is what helps people reason effectively from cases. In organizations, people often cling to their own pet theories based on a single false case. Every single one of a manager’s direct reports may believe that his theories about promotions, choosing vendors, or assembling a team are wrong, but this manager will refuse to listen to reason if they’re bold enough to challenge him. In fact, these managers cling to their own theories in the same way a baseball player will refuse to change his socks if he’s on a hot streak. Cognitively, decisions are nothing more than efforts to predict outcomes. There is always some risk, and so people like to fool themselves into thinking they can eliminate the risk of a negative outcome. Thus, it becomes difficult to convince these managers to recognize that their reasoning is wrong because it’s based on overly narrow experiences. The manager who is convinced that you should only introduce a product during the first quarter because once he was in charge of a successful first quarter product introduction won’t alter his mind-set. Actually, he will vary from this routine if he is fed other relevant cases at the right time. If he learns about five other highly successful product introductions made in other quarters involving products,



46

47

markets, economic environments, and competitive frameworks similar to what he’s facing, he might make a different and more effective decision. These cases can arrive in a variety of ways: a boss, mentor, or other expert can relate them verbally or in writing; they can appear on his computer screen; and they can emerge through collaborative decision making. A team of people can share experiences—ones where decisions resulted in both successes and failures—and thereby expand an experiential base. The problem with any of these approaches, however, is that the additional cases might not be the right ones. People can relate their stories in team meetings, yet without a guiding hand to make sure these experiences are relevant to the decision at hand, they may confuse the issue. Later, we’ll address this issue and demonstrate how organizations can ensure that decision makers receive a range of relevant cases. For now, though, the point is that a range of cases helps decision makers be more objective in most situations. If organizations can turn ten illogical decision makers into ten casebased ones, they will see a gain in more effective service, policies, processes, and whatever else these managers are responsible for. Benefit 2: Improves Hiring, Promotion, and Retention Decisions Organizations tolerate a certain amount of error when it comes to hiring and promotion. They accept that they’re going to hire some individuals who won’t live up to expectations and that they’ll promote people into positions for which they’re ill-suited. In most organizations, everyone knows the managers who are retired in place; who are in over their heads; who are competent enough to escape being fired but not sufficiently effective to contribute much. Just as alarmingly, companies routinely let go people they can least afford to lose. When companies downsize, they often target the employees with the greatest tenure. This is due in part because





long-term employees tend to be higher-paid people, and they know they can hire a young person to do the same job for less money. Yet in most instances, employees with the most years at a company are the ones with the most experiences. They’re the “old salts,” the veterans who can draw on a diversity of cases to solve problems and take advantage of opportunities. Their experience, however, is often discounted by management. They’re seen as too expensive, too old-fashioned, too idiosyncratic. They may not seem to fit with the new culture that the CEO is trying to create or with the new teams that the company is rolling out. Nonetheless, their decision-making capabilities are second to none, and their value to the organization is often underappreciated. A case-based reasoning system has the potential to guide organizations so that they hire the best people, promote the right ones to positions of responsibility, and retain those with the necessary savvy to make the tough choices. Such a system can’t be manufactured in an instant, but any company concerned about the war for talent should pilot test such a system. More specifically, here are three guidelines that will recruit and retain savvy case-based reasoners: ●

Focus on experiences rather than the job specs. Organization that embrace case-based reasoning will hire individuals who have accumulated the type of experiences that will help them deal with the challenging choices that comes with the positions for which they’re being hired. Rather than hire someone who is a “skilled communicator” and who has “good media contacts” for a public relations position because that’s what the job specs demand, the criteria should involve situations they’ve been in that are valuable for that job. In fact, the job interview should revolve around these applicants relating stories of what they experienced on previous jobs. If the PR position involves crisis management, applicants should be asked to describe the emergencies they faced in previous jobs.



48

49

A note of caution: these applicants should not be evaluated based on how successfully they navigated the crisis as much as the diversity of crises they’ve handled. From a case-based reasoning perspective, companies should be hiring people who have not only a track record of success but an earlier track record of diverse failure. ●

●

Use performance reviews to evaluate the experiences accumulated. These reviews often measure mundane responsibilities that have little to do with effective decision making (meeting deadlines, getting along well with others, etc.). Instead, these reviews should gauge if people have thrown themselves into a variety of situations, even if they were situations in which they struggled. People who willingly take on stretch assignments and volunteer for jobs that are outside their comfort zone generally develop a healthy load of cases they can draw on when they’re promoted to positions of responsibility. Value older employees. This doesn’t mean that companies should keep every employee who has been with the organization for a long time. It does mean that they should value age during the hiring, promotion, and retention processes. For a company to improve its overall decision-making effectiveness, they need a critical mass of older employees. These are the ones who are best able to function effectively in complex and confusing situations. They’re the individuals who can reason out the best solution under stress and when no clear path exists.

As an addendum to this suggestion, we would add that even in companies that haven’t downsized most of their older employees, a lot of them are pushed to the side and given busy work. In effect, they are removed from significant decision-making responsibility. Therefore, retaining older employees but retiring them in place is no better than




50


downsizing them. Even if they’re idiosyncratic and don’t seem to fit perfectly with a younger generation or a flattened organizational structure, their experiences should be used rather than ignored.

People at the top of companies generally have many cases to draw upon, but they may not be the right types of cases for a particular issue or their case-based reasoning faculties may be short-circuited by the unique pressures of their positions. In the former instance, they may be reluctant to admit to themselves or others that they need help—they don’t want to appear weak or inexperienced. Jim was the CEO of a mid-sized corporation who had enjoyed a string of successful CEO positions. His success was due in large part to his ability to cut costs; he was skilled at coming into an organization and spotting areas of waste or areas where cuts wouldn’t have a negative short-term impact on productivity. As a result, when a company was in trouble and the board felt the solution was cost-cutting, Jim was a prime candidate to replace the fired CEO. When he joined the mid-sized company, he did what he always did: identified areas where spending was too high and reduced costs accordingly. While some of this cost-cutting involved equipment and other capitalized investments, a significant percentage involved people. In the past, Jim never was adversely affected by his personnel reductions. In part, he escaped these negative effects because he generally only stayed at a company for a few years—the negative impact occurred after he had departed for a new job. In this mid-sized company, though, Jim stayed for five years. After four and a half years, his industry experienced a surge—their products were in great demand, especially in overseas markets. Unfortunately, as part of his cuts, Jim had reduced their overseas operations, eliminating offices in a number of countries



Benefit 3: Enables Leaders To Make Better High-Level Decisions

51

and reducing staff in others. Consequently, competitors were in a much better position to capitalize on the demand for products, and Jim’s company fell far behind the market leaders. His cases had not prepared him for this situation, and as a highly successful CEO he was overly confident in his ability to make the right decision. CEOs and other senior executives are often victims of their own success. Understandably, their confidence is high and their egos can be large, but without a history of small failures, they tend to make decisions based on their single-case successes. Like Jim, they make decisions that may fit one situation but don’t realize that they are illsuited to new circumstances. Case-based reasoners, on the other hand, recognize the value of listening to experts when an issue falls outside of their area of expertise. In fact, the best CEOs are acutely aware when their experiences preclude them from making effective decisions, and they not only call in experts for advice but they listen carefully to what they have to say. In the videos and photographs of President Obama meeting with cabinet members or other advisors, he seems to be listening with his entire being. His focus is absolute and it’s clear that he is receptive to hearing a variety of ideas from experts—he listens intently to Republicans, climate change scientists, military officers, and others whose experiences trump his own. Benefit 4: Facilitates Operational Effectiveness Case-based reasoning is not just for leaders. Hundreds or thousands of people in a given company make small but significant decisions every day. Each decision may not seem particularly significant, but cumulatively they have a huge impact on a company’s productivity and profitability. If one customer service rep decides to ignore a customer request because he doesn’t know the answer it may not have much impact on





the organization. If fifty reps make the same decision, it will have an impact. In fact, if you were to add up all the choices that line people in a large company make every week, you’d have a staggering number. A financial person decides to calculate accounts receivables in the traditional manner, even though he senses that the numbers are off. An assembly line worker notices a small problem in how the product is being assembled but doesn’t stop the line from moving (even though he’s empowered to do so) because he doesn’t feel it constitutes an “emergency.” A salesperson decides to focus all his effort on the three top potential accounts because that’s always been the unwritten rule in the sales department, even though he suspects he’d have better luck generating more sales if he targeted accounts with a bit less potential. A purchasing agent awards an account to the lowest bidder even though he knows that a higher bidder will provide better quality and service. Most of the people responsible for the day-to-day operations of an organization aren’t dumb—far from it. They are, however, script followers. Formally or informally, employees are trained to follow scripts. In the most literal sense, telemarketers follow written scripts prepared (presumably) by people who know how to sell over the phone. More commonly, however, these scripts are embedded in people’s heads. Some of these scripts are the result of training or stated policies and procedures while others are intuited from the culture. No matter the origin, they control how people behave in common work situations. It is almost as if they are programmed to make Decision A rather than Decision B, even if they sense it’s the wrong decision. These scripts come with expectations for how a situation will unfold. A manager gives his direct report a glowing performance review and expects the direct report to thank him, accept his raise, and continue doing good work. A salesperson goes into a meeting with a new prospect and expects to make a standard new customer sales pitch.



52

53

Consider what happens, though, when a situation thwarts these expectations. When the direct report responds to the review by demanding a raise far in excess of the norm, his boss is nonplussed and ends up making a poor decision—turning him down angrily and alienating a talented employee. When the salesperson is told by the prospect that he would prefer not to have a canned speech but instead wants his analysis of the prospect’s product quality, the salesperson gives a version of the canned speech anyway, believing that it will satisfy the prospect. In companies where rules govern most employees’ decisions, they have difficulty making decisions that aren’t in their scripts. In a casebased system, however, people are much better able to make good decisions when situations change. If the company hires people with diverse, relevant experiences, they have a variety of cases to make decisions from. If they developed a computerized system to provide these relevant cases to people at decision points, they will find it easier to vary from their scripts. But perhaps most significantly, organizations can train their people for script breakdowns. Scripts are fine when things go according to plan. They help people make good decisions because the script is based on expert advice on what to do in these common situations. In volatile environments, though, exceptions to the script are common. If these exceptions can be anticipated, training can provide people with stories about what to do if something goes awry. In this way, they are better prepared to identify a deviation from their scripts and make an alternative and more effective decision. We should emphasize that scripts are incredibly powerful. Management often doesn’t realize the hold these scripts have on their employees’ behaviors; how many decisions are rules-based reflexes and lack any basis in real experience. To illustrate the power of scripts, consider this true story. A business person rented a car from a well-known agency and was on the road for a month, traveling thousands of miles.





When she returned the car to the rental agency, she explained that she had put all those miles on the car, and the rental agent could see when he looked at the odometer and noted the increased mileage that she had done a great deal of driving. Nonetheless, he asked her, “Did you refill the gas tank?” Obviously, she had. But the script was so powerful that he was compelled to ask a question for which he already had the answer. Benefit 5: Helps People Learn Their Jobs Faster Learning curves at companies can be steep, and it can take weeks, months or even years before people can be entrusted with decisionmaking responsibility. Training attempts to compress this learning period, but most of the time, it is training in rules rather than cases. As a result, people may learn what they’re supposed to do and make decisions accordingly, but they will be lost when it comes to situations that they lack experience in or that require different decisions than what they’re been trained to make. A case-based system means accumulating the right type of experiences prior to assuming decision-making authority. While traditional training is generally not good at providing this experience (classroom lectures and exercises are too far removed from on-the-job activities, emotional responses, etc.), apprenticeships are effective for helping people acquire valuable experience relatively quickly. Apprenticeships have negative connotations today because of their origin in the Middle Ages where master craftsmen exploited young men, turning them into indentured servants. Nonetheless, the concept of apprenticeships is valid from a cognitive science perspective. Learning on the job with an expert to guide you is the single best way to acquire the cases necessary to make good decisions. Many companies have internships, and these are good ideas in concept if not in execution—too many internships



54

55

involve tasks that are tangential or trivial and don’t allow people to acquire relevant and diverse cases. If organizations recognize the value of case-based decision-making, they will implement various forms of apprenticeships in order to get their people up to speed quickly. In some professional service firms as well as the medical profession, apprenticeships are common (though they don’t term them apprenticeships). Young people follow around veteran, savvy senior members of firms and learn at their elbows; they have someone looking over their shoulder to correct them if they are doing something wrong; they have access to an expert who shares instructive war stories with them. In fact, a surprisingly large number of companies are starting to measure managerial performance based on how well they grow their people. In the past, the last thing managers wanted to do was “babysit” neophytes. Today, organizations are recognizing the value of their young people and how it’s much less expensive to help them learn, develop, and grow into exceptional performers than it is to hire outside talent. Managers are therefore becoming adept at mentoring their direct reports; sharing stories and giving them experiences that will help them grow. Benefit 6: Encourages Smart Risk-Taking Behaviors The best decision makers have experienced some failure—often significant failure—before they experienced significant success. As counterintuitive as this statement may seem, it’s a fact of cognitive science. Experts always have a history of trying a lot of different things early in their careers, and invariably they don’t do particularly well the first time around. But their willingness to try and fail is what’s key. The more they try and fail—and the more they think about and learn from their mistakes—the better able they’ll be to deal with similar situations the next time. It’s better to have a number of small failures in





order to have a number of large successes later on. In fact, even some larger failures should be tolerated. We’ve found that most successful business executives have stories from earlier in their careers where they made significant mistakes. Test this concept by reading an in-depth interview with a well-known CEO. If that individual is honest and open, he’ll likely tell a story about he decided to implement a program, hire a particular individual, or some other action that turned out badly. It’s also likely that this CEO learned from his bad decision and didn’t make it again. By tolerating teachable failures, organizations encourage people to take good risks. They will develop managers and leaders who won’t decide to play it safe all the time; they’ll take the gutsier option if their cases tell that the risk is reasonable and the reward is significant. We’re not suggesting that companies should accept all failure or give people carte blanche to take absurd risks; there are too many people without sufficient cases behind them to do this. Yet the principles of cognitive science demonstrate that “graceful failure” is a great learning tool. By graceful failure, we mean failure without shame or embarrassment. Going back to our apprenticeship concept, senior people should give others stretch assignments, allow them to fail but be there to catch them when they do. They can minimize the damage done by the failure, and just as important, they can turn that failure into a teachable moment. They can tell their people a story about how they experienced a similar failure early in their career and how they came to handle the same situation differently and more successfully later on. Perhaps most important of all, they can encourage people to reflect on what went wrong. When people fail, they are motivated to learn. They are eager to know what they might have done differently. As long as they aren’t humiliated by the failure, they are in a position to reflect on the experience. If a boss chews them out unmercifully, on the other hand, they may focus on the wrong things such as how much they hate



56

57

their boss or how stupid they are. While some people learn from the emotional impact of these situations—their embarrassment indexes the case in their minds and makes it retrievable when they’re in similar situations—others index it poorly because the humiliation obscures all other learning that might be gleaned from the experience. We’ve heard many leaders bemoan how their people are afraid to take chances, how everyone does their jobs competently but unimaginatively. Organizations that want their people to make moderate-risk, high-reward decisions need to let them make small mistakes early on without fear of punishment. A Business Week cover story (July 10, 2006) titled “How Failure Breeds Success” offers example after example of organizations that have recognized the value of failure. Or rather, the article notes that “. . . intelligent failures—those that happen early and inexpensively and that contribute new insights about your customers—should be more than just tolerable. They should be encouraged.” The article describes how companies like Intuit and General Electric are making formal efforts to learn from their failures and to turn failure into opportunity rather than making it a corporate taboo. While this article is more concerned with the learning that is possible when products or services fail rather than individuals, they make the applicable point that when smaller failures are tolerated or even celebrated, employees are much more likely to try something new or risky.

Less Tangible But No Less Significant Benefits In many organizations where rules and regulations prevail, people make decisions out of necessity or duty rather than because they believe in them. They decide to fire (or not to fire) an employee because of a legal requirement, not because they believe he deserves to be fired or that





he’s not contributing to the company. They embrace a trendy strategy because they want to appear “with it.” They launch a program because they know it’s the type of program their boss loves. When people make decisions they don’t believe in, they don’t feel good about themselves or their organizations. They lose their energy and commitment. Even when they make a decision they believe in—that feels right—they have to justify it with a rules-based argument rather than a case-based one. They can’t articulate that they decided to promote Joe rather than Jill because they half-remember once passing over Jerry for a job and have regretted it ever since, and like Jerry, Joe has the relevant experience and they get along great with him. Instead, they must argue that Joe fits the specs of the job (whether or not he really does). Making this argument is enervating. At best, it feels like a belated rationalization. At worst, it feels like a lie. However, when organizations prioritize cases in decision making, it allows people to go with their gut, to rely on their experiences or other people’s expertise, to act in a way that just feels right. It’s liberating for managers to work for an organization where they aren’t constantly thinking about how they’re going to justify a choice or whether they’re making decisions that feel honest. Though there’s no way of proving this point, we know empirically that when employees feel good about the choices they make, they feel good about the employers who allow them this freedom. These working environments are superior to those in other organizations, and at a time when everyone is warring over talent, this is a significant benefit.



58

Software Based on the Science of Decision Making: Tools Organizations Can Use

While case-based reasoning has numerous benefits for organizations, at first glance it may seem impractical to put cognitive science tools into practice. For instance, companies may lack the budget to staff all key decision-making positions with people who have the preferred relevant experience. They may tell their experienced people to rely on their gut but have various rules and cultural prohibitions that mitigate against such decision making. Employees might also believe they possess the savvy to make appropriate case-based choices, while in reality their experience is not always applicable in a given situation. We recognize that organizations that have relied for years on rules to guide decision making may view these obstacles as significant. Their policies and procedures serve as a security blanket—managers can always justify their choices based on corporate-mandated best practices. To a certain extent, transitioning to case-based reasoning is an act of faith. It requires working without the net of rules that catches managers when they make an error. However, the challenge of case-based



Chapter 3


reasoning is not as formidable as it might appear. For one thing, it is a transition—every corporate rule won’t be eliminated immediately. The process can be tested in one department or around one decisionmaking area, and when there’s clear evidence of its success, others in the organization might be more willing to follow suit. Secondly, pain is a powerful motivator for shifting from a rules-based to a case-based system. Companies that have made a series of strategic or other blunders have much less faith in their sanctioned rules than they once did; they’re open to new approaches that might have more success. Though, perhaps the most significant incentive to move from a rules-based system to a case-based one is the computer. Computer software can incorporate case-based reasoning into its design. It can provide users with a way to make faster and more effective decisions than was ever possible with rules and procedures. Admittedly, most companies don’t currently have case-based reasoning software. In fact, most organizational software is antithetical to human thought processes. In a moment, we’ll demonstrate how this is so. First, though, we want to emphasize that cognitive science and computers are a perfect match. Cognitive science principles can be and have been used to design software that facilitates decision making, and we’ll refer to examples of this later in the chapter and throughout the rest of the book. The Artificial Intelligence community has taught us how to create software that mirrors the way people think, that takes advantage of concepts we’ve discussed, like indexing, case-based reasoning, and reminding. Instead of receiving reams of undifferentiated data to help us make a choice, computers now allow us to receive stories from experts that are relevant to particular situations, alerting us to common mistakes made in these situations and suggesting how others have made astute choices that weren’t always obvious. Secondly, we should note that when we refer to software here and elsewhere, we’re referring a range of software types, from unstructured



60

61

exchange of information (such as e-mail) to inflexible process control systems (such as a purchasing system). We make this distinction because decisions are impacted by the convergence of different types of software—exchanges with colleagues over an in-house system, dashboards that provide access to external and internal databases, and department-specific systems that provide process control. Few cognitive science principles govern any of these software types, partly because many organizations aren’t aware of these principles and partly because software designers create software that has little to do with the human thought process. Invariably, however, as organizations become more aware of cognitive science and how software can capitalize on it to facilitate decision making, things will change. In fact, the rise of knowledge management systems is a sign that change is already starting to occur, even if most knowledge management approaches aren’t cognitively congruent. Nonetheless, companies now recognize the value of storing corporate knowledge in various domains and being able to retrieve it. The next step is for organizations to understand they need a new way of storage and retrieval.

Minds That Understand Computers, Not People Software can be anything but “user-friendly.” Despite the ubiquity of that phrase, most software is designed by computer scientists for computer scientists. All it takes is a little understanding of computer history and software products to realize how true this is. Consider that when the first personal computers were produced, the manufacturers seriously doubted that they would be embraced and used by the general population. Up until that point, computers were designed for numbers crunching. All sorts of arcane computer programming language existed, and to make the early PCs work, users had to type all sorts of



TOOLS ORGANIZATIONS CAN USE


symbols to do everything from creating paragraphs to scrolling down a page. Consider, too, early word processing programs. For years, these programs were incredibly frustrating. It took a long time before designers realized that what users saw on the screen should mirror the actual document; that the screen should not be littered with symbols. It took programmers a long time to realize that users wanted and needed a “What-You-See-Is-What-You-Get” (WYSIWYG) design. Even in much of today’s business software, human thought processes are ignored. On any given day, hundreds of decision makers in an organization will search for information that impacts their choices. Using Google or another search engine, they type in terms and receive a potpourri of sites, most of which are irrelevant to what they’re seeking. The results seem to be compiled in an almost random fashion, without regard for expertise or the nuances contained within the search terms. Work computers should know everything about users—their job types, their typical tasks, their goals, etc. All this information should help the computer direct a search so that it’s relevant to an individual’s decision-making process. This is relatively easy to do, but it isn’t done because of people like Curtis. A software engineer for a huge corporation but working out of its third world country office, Curtis was applying for jobs in the United States and contacted a former colleague now was running his own business. This former colleague thought highly of Curtis’ technical expertise and requested that he make a written argument for how skills could help this business owner’s company make money. Curtis responded with a long document containing spread sheets and numbers. When asked how the document demonstrated that he could make money for the company, Curtis said, “Just look at line 17”—a line that was mostly numbers without any clear explanation of what they meant.



62

63

Curtis, like many software designers, is highly intelligent in a very specialized way. His ability to write and document hugely complicated software for large companies is a valuable skill, but his understanding of how the mind and people work was poor. Yet, Curtis is the one who designs supposedly “user-friendly” business software, even though it is only “friendly” if the user is another software designer. Perhaps even more significantly, software today is too broad an area for the narrow skill sets of software engineers. Consider this analogy: an aeronautics engineer may know how to design the wings of the plane better than anyone on the planet, yet he knows nothing about seat design, the primary interface with the airline’s customer. What this suggests is that software designers are only one small piece of the bigger whole. They may create a piece of software that delivers information about purchasing quickly and accurately, yet fails to integrate any of the other important elements that impact a purchasing decision. When a purchasing manager is trying to decide between Vendor A and Vendor B, he doesn’t receive advice from other purchasing managers in the organization through the computer about what they decided in similar situations. No historical record of dealings with Vendors A and B pops up on his screen. There is nothing in the system that automatically reminds him that he should consider a third type of vendor when certain factors are at play. In short, software designers rarely see all the elements of any significant decision from a holistic, integrated perspective.

Documents Versus Stories Organizations of any size typically have knowledge management systems, but in reality, these are nothing more than libraries on steroids. These vast and ever-increasing data files are helpful for certain





functions, but they are relatively useless when it comes to making anything more than simple decisions. Nonetheless, companies encourage employees to rely on knowledge management systems to help them with all manner of choices. The logic is that since these systems are able to provide many documents to many people with great speed and facilitate exchanges of information across global networks, they can help people make better decisions. However, for decisions of any complexity, documents are useless, no matter how voluminous they might be or how fast they arrive. Of course, for clerical tasks these systems are effective. The airlines, for instance, handle reservations with greater speed and fewer errors than in the pre-software era because of the systems that govern flight bookings. Corporations’ purchasing and personnel software provide the details about pricing and employees (date of hire, benefits records, etc.) that help these companies run with much greater efficiency. Knowledge management systems, therefore, promise a great deal but deliver relatively little when it comes to significant decisions. The corporate message to employees is that they can use these systems to access valuable organizational knowledge related to all functions and processes, that they can search and find nuggets of information that will help them make better-educated choices about everything from responding to a customer complaint to implementing a growth strategy. But in reality, these systems rely on a key word search method that makes it difficult for people to find such nuggets—they can retrieve data about a given subject, but they can’t retrieve the stories and cutting edge expertise that offers the insights and ideas that yield superior decisions. Perhaps most detrimental is the inability of these systems to facilitate decision making when a situation is anomalous or even mildly complicated.



64

65

Purchasing systems don’t help purchasing managers recognize that by buying a thousand units from Company X, they are making a similar blunder to the one made by the former purchasing manager three years ago. His story is neither indexed nor “recalled” by the software as the current manager tries to decide which vendor to buy from. Personnel systems don’t help a human resources manager recognize that Employee A is driven by stretch assignments and flourishes when placed in positions that offer major challenges; these systems don’t match what drives Employee A with jobs that open up and provide these challenges. Besides recalling stories, the systems don’t help users make the right cause-and-effect comparisons; they don’t remind a system user on the cusp of making a big purchase from a vendor that components bought from this vendor in the past have not always functioned properly or that they have been especially problematic when used in the type of equipment targeted by the current purchase. The computer knows little about the user and his enterprise activities and goals and treats the process as a way to record actions but not a way to aid people in making good decisions. Similarly, software providers don’t design systems to help users deal with conceptual obstacles to making good decisions, such as conflicting goals. These systems don’t know about and connect the activities of all relevant individuals (employees, clients, etc.) pursuing similar or conflicting goals. Activity models (step-by-step descriptions of behaviors from the start of an activity to its conclusion) are missing from most corporation software system. For instance, software can be designed to hold the activities of salespeople who experience a particular type of problematic sales call. It could capture what happens at the start of the activity (i.e., the salesperson follows up a qualified lead), in the middle (i.e., the salesperson sees the prospect lose interest in the middle of his presentation), and at the end (i.e., one salesperson loses the sale while another salesperson makes it).





The system could capture all these activities, index them in a retrievable way and present them to users on the verge of an important decision. They might hear the story of one salesperson who found that discussing price in the middle of the presentation tended to turn off a certain type of prospect; they might hear another story from a superstar salesperson describing how he circumvented this problem by talking about price at the end of the presentation. All these stories help create the activity structure around this sales process, presenting users with the right story at the right time. In 1968, California Institute of Technology professor Frederick B. Thompson wrote an article in the Journal of American Documentation where he coined the phrase, “the organization is the information.” What was cognitively true then is cognitively true today: Organizational activities are conduits for information; they make information useable. It follows that the activities of employees past and present hold the key to successful decision making. This information has to be organized correctly in order to be accessible and useable, and it is neither if it’s contained in thousands of electronic documents. Retrieval of the right information at the right time and in the right form is crucial. Indexing information is the solution. Unfortunately, when it comes to most companies’ software, it is also the problem.

The Indexing Problem: The Cognitive Science Solution We talked about indexing briefly in the previous chapter, but we need to delve a bit deeper into cognitive science to fully explain its role in software design. Indexing is all about labels. For instance, an automotive industry consultant needs to know how to structure a proposal on innovation to a committee of Ford executives. To determine how to do



66

67

this, he conducts a search using the words “Ford” and “innovation.” What the search engine gives him are sites dedicated not only to the car company but also to President Ford’s attempts to stimulate innovative economic measures and ingenious ways to ford a stream. This is a rather primitive way of indexing information, one that operates at a far lower level than our cognitive processes. While business executives may be able to find bits and pieces of information that are relevant to their decisions using this method, the time and effort required to locate small nuggets of relevant information makes it a tedious exercise. What’s more, they are unlikely to gain any insights from past cases that will allow them to make even moderately difficult decisions effectively. Another indexing method is the Dewey decimal system that libraries have used for years. In this system, numbers label specific types of information. For instance, all biographies fall within a certain range of numbers. Retrieving information in this manner is fine if you’re looking for a biography, but it is obviously limited in terms of providing the expert cases relevant to a particular situation. For example, you want to know how celebrities dealt with depression, but you lack any tool for finding this knowledge in ten key biographies of famous people. The human mind indexes at a much higher level of abstraction; it labels experiences in ways that aren’t always obvious to an “outside” observer but that makes it relatively easy to retrieve these experiences when they’re needed. This indexing process becomes clear in this story from Roger that he calls “the steak and the haircut”: Years ago, I was sitting out on the lawn at Yale eating lunch with my friend, the psychologist Bob Abelson. I was complaining to Bob how my wife never cooks my steak rare, which is the only way I enjoy eating it. He responded, “I could never get my hair cut as short as I wanted in England 30 years ago.” This response might seem like a non sequitor





at best and bizarre at worst. In fact, this statement makes perfect sense if you understand how the mind indexes experience. In Bob’s mind, he was thinking that Roger was complaining about someone in a service position who did not do something to the point of extremity that he desired. Similarly, Bob recalled that at that time in England, barbers didn’t provide crew cuts, which was the style he desired. Bob’s mind had indexed the story with the label, “extreme request.”

In the old days in business, people put reports and other written documents in manila files and stored them alphabetically in vertical black filing cabinets for later use. Most of the time, these files gathered dust and the drawers were rarely opened. The same holds true for today’s computerized documents: housed in the dusty electronic drawers of knowledge management systems. Important information and stories may exist in these files, but they aren’t naturally retrievable— the right one doesn’t pop open at the exact moment when people need to hear it. We’ve found that despite all this, many business people are stubborn about their antiquated filing systems, whether they’re vertical metal cabinets or electronic files. They have spent many years putting information away in alphabetical and subject files and retrieving them in the same way; this is what they’re accustomed to doing, despite the fact that it’s a tedious, time-consuming process. For instance, they want all information related to innovation to be stored in a file labeled “Innovation.”. This is a word or concept-based system, and such language tools are sometimes confusing and often irrelevant to the way the mind indexes information. In addition, most documents belong to many categories, making it almost impossible to categorize them under one simple subject heading. To grasp the non-language manner in which the mind indexes, think of the play West Side Story. For most educated people the play reminds them of Shakespeare’s Romeo



68

69

and Juliet. On the surface, the modern musical and the classic tragedy written hundreds of years earlier have little in common. The former involves singing gangs in a working class New York neighborhood. The latter involves wealthy families, soliloquies, and Renaissance Italy. The style and substance are quite different from each other. Yet the mind subconsciously indexes both with the same label: “Warring factions destroy lovers’ plans and lovers themselves.” The mind sorts by four factors: goals, plans, goal conflicts, and conditions. Steve is a top corporate executive with a public company contemplating an acquisition. He’s debating between three possible acquisition targets, but one of them seems far better than the others because of its sterling revenue performance in the past three years. Though it comes with a high price tag, it also seems like a bargain given future revenue projections. Steve brings in one of the leading consultants in the field of mergers and acquisitions, and he explains how acquiring this company will help the organization achieve its long-term growth objectives; that they want to buy it quickly before one of their competitors moves in; and how their only hesitation is that it was not a good year for the company and they are worried about media and stockholder criticism if they make the purchase. The consultant is immediately reminded of a smaller private company in a different industry that he worked for seven years ago. He tells Steve about how they invested a significant amount of money developing a hot, new product, hoping to capitalize on an emerging trend in their industry. Their CEO at the time was highly ambitious and wanted to take the company public and believed that a successful launch of this product would help achieve this goal at some point in the future. Even though his decision to develop the line alienated a number of board members who felt the strategy was overly aggressive, the CEO moved forward. Unfortunately, the trend was short-lived, and though the new product made a great deal of money for the company initially,




70


● ● ●

●

Goals: Both stories are about achieving long-term growth Plans: Both individuals wanted to strike when the iron was hot Goal conflicts: Both companies wanted to achieve growth but there was a potential downside for being overly aggressive Conditions: Both stories involved appearances that belied realities

Indexing in this way can be extraordinarily valuable for decision makers. In this instance, the consultant’s story demonstrated to Steve that the acquisition might not be as attractive as it seemed, and that he should consult other experts about whether the acquisition target was likely to sustain its superior revenues. Additional stories from other experts convinced him that they were unlikely to do so, and he wisely decided not to recommend the acquisition.

Why Software and Indexing Are a Natural Fit Given the previous example, it may seem that if you have a trusted consultant or other expert, you don’t need to rely on computers or your own limited experience to make decisions. Yet most businesspeople don’t have immediate access to such an expert. More to the point, the person with just the right mix of experiences for a given decision may be in an office a continent away . . . or this expert may be inaccessible to the majority of a company’s employees . . . or it may require a combination of different experts that is almost impossible to create at the crucial moment.



it quickly became an albatross and hampered rather than helped the company’s effort to do an IPO. Here are the four indexing factors that reminded the consultant of this story:

71

Perhaps even more importantly, we work in an era where situations are constantly changing and it feels as if every decision is without precedent. No single person is a repository of the right mix of experiences to advise decision makers. There are always new elements entering the picture that never existed before. Many times, even if people had unlimited resources and could bring in any expert they wanted for advice, they wouldn’t know who to call. Fortunately, computers and software are ideally suited to indexing cases as they relate to decision making for the following reasons: ●

They can be programmed to remind users of the right cases at the right time.

As long as organizations have activities models, they have a basis for creating software that funnels experts’ stories and other information relating to a particular decision. If the computer understands the typical situations an employee faces, relevant stories can be taped and transferred to electronic files. For instance, if a manager describes one of his responsibilities as “promotion decisions,” he can describe all the factors that go into making these decisions as well as the good and bad ones made in the past—the reasoning and information that resulted in positive and negative outcomes. The computer “knows” details about what a user does—the particular tasks that are his responsibility and how he goes about doing them—so that it is reminded of a case that relates to the decision. It’s not just the right case that’s important, but delivering it at the right time. Employees may attend training seminars where an expert gets up and shares war stories, some of which may be highly relevant to their jobs and could help them make better decisions. However, the vast majority of employees will forget these stories long before they are faced with a decision similar to what that expert encountered. On the




72


●

They don’t forget cases.

People forget the cases they were told in training seminars. They also forget their own experiences. A human resources manager may have handled a particularly tricky employee discrimination matter three years ago, learning it was better negotiate with employees in this instance than take an inflexible stand. While this case may be stored somewhere in her unconscious, company culture and rules prevent her from going with her gut. She tries to reason out solutions to problems based on what she consciously remembers, and this particular case escapes her. As a result, she decides to take an inflexible stance in the discrimination negotiations, and her choice ends up costing the company a lot of money and negative publicity. The beauty of computers is that they don’t forget the cases they’re programmed to remember. Ideally, they can provide every organizational decision maker with a case base superior to the sum of the individual’s remembered experiences. ●

They are emotionally neutral.

In most companies, people routinely make decisions out of fear, anger, and other influential emotions. A CEO is furious that his competitor has introduced a new technology before his company and, driven by competitive rage, cancels all other important projects to bring the company’s technology up to speed. Whether or not this is the best decision in this situation is secondary.



other hand, the computer can convey his story at the ideal moment for an employee—on the verge of making a decision. This is the prototypical teachable moment, the window where people want and need to hear this story.


73

●

They separate the wheat from the chaff.

When facing decisions, people are often overwhelmed by data. They may not only be drowning in written reports, but may also be bombarded with conflicting advice from bosses, direct reports, consultants, and others. Sorting through mounds of largely undifferentiated information in order to make a decision is generally futile. This is especially true if a decision takes place in ambiguous, complex, or rapidly changing circumstances. Data usually doesn’t help people make effective choices. Cases do. Software can take into consideration a user’s goals, plans, conflicts, and conditions to deliver one-to-a few germane cases offering insight into the decision and its consequences. To paraphrase the old saying, a case is worth a thousand pieces of data. ●

They are a superior delivery system to connect decision makers with experts and cases and to promote “conversations” about them.

The best way to hear a story is sitting at the foot of an expert. Unfortunately, this isn’t possible for most employees, especially at a time where employees are spread across continents and even if experts reside in their home office, at least one party is often on the road. Technology is now able to capture stories from company veterans–the former consultants and professors who are the world’s leading authorities on a given subject, or the one person in a company of thousands who knows about the ins and outs of a particular company issue. More to the point, software can be programmed in such a way to recognize when a given story is relevant to a decision and draw attention



Computers reduce emotional bias. They externalize the decisionmaking process, focusing on cases as the primary decision-making factor.


to it. Through indexing, it can also communicate to the decision maker that he should talk to Joe in the Hong Kong office who experienced a similar problem last year. And instead of drowning the user in data, it can rifle through the recorded corporate memory and send him a few key cases might help him make a better decision.

More Than Storytelling This isn’t just about stories for their own sake. A story is only as good as its relevance to a given situation. It must have conceptual resonance in the decision maker’s mind—. Any old story won’t do. If the story seems irrelevant, feels like a lecture, or only operates at a low level of abstraction, it’s not going to have much impact. To illustrate “low level of abstraction,” consider this example: John is trying to decide whether to grant a subordinate’s request of a 25 percent budget increase for his team, knowing that he’s going to take flack from his CFO who has issued a moratorium on team budget increases. John’s boss tells him a story about how he granted a similar increase to his team a few years back and their performance improved dramatically. But John ignores this story because there’s only a simple and literal relationship. A deeper and more complex story would be indexed under “granting request with long-term benefits and short-term pain.” In this instance, John’s boss tells a story about how he once promoted an assistant to a plum position even though she never graduated from college, and was widely criticized in the company for putting someone without the right credentials in this job. At first glance, this story seems unrelated to John’s current dilemma. However, from the perspective of cognitive science it is highly relevant because the goal conflict is similar. A story like this one is memorable and retainable. That’s why software can’t simply deliver the moral of the story and skip the story itself.



74

75

If you choose this approach, all that will remain is an eminently forgettable and unconvincing rule. A story’s lesson may be “never award a contract to the lowest-cost bidder reflexively and without thoroughly investigating possible service shortcuts inherent in the bid,” and for most employees, it will have little impact when they make a decision. For one thing, it’s just one rule among many and easily forgotten. Secondly, it has no credible context; it lacks the drama and the involvement of a good story—people find it difficult to relate to or identify with. Third, and most importantly, it’s difficult for our minds to index such a lesson. Remember that indexing involves goals, plans, goal conflicts, and conditions. When people hear a story, their minds label it according to the goals, plans, goal conflicts, and conditions inherent in the story. Earlier we talked about scripts and how in organizations, people often follow them unquestioningly. The telemarketer follows a literal script given to him while the middle manager follows a series of rulesbased scripts related to hiring, performance reviews, delegating, and the like. These scripts are the enemies of good decision making, since they allow people to make choices without really thinking about them. Just as the telemarketer recites the words without considering the prospect’s responses or nuances of tone, the CEO pursues an aggressive growth strategy because he is known as a growth-oriented leader and wants to reinforce that reputation. They do what the script dictates and ignore what doesn’t fit with it. Stories are the change agents for scripts, providing alternatives for actions (and decisions). They give us a way of dealing with complexity, of comparing one situation to another. Stories are memorable in the best sense of that word. Not only do they contain a lot of information, they also contain a lot of indices. Because the information imparted is not just facts but has a dramatic arc with goals, plans, goal conflicts, and conditions, the mind retains stories in a manner that makes them readily comparable to future cases.





We don’t want to make it seem as if telling one story will solve every decision-making problem. It has to be the right story at the right time—or the right set of stories at the right time—combined with the right conversations and the right examples from the company’s history (or from related histories of vendors, customers, manufacturers, etc.). More importantly, the software is responsible for bringing these stories, experts, conversations, and examples to the fore when a decision maker is facing a choice. Here’s a shipping example that illustrates how the process should work. George is a Fleet Manager who arrives at work and logs onto his computer system. When he left work the previous day, he was dealing with two issues: a crew situation on one of his ships, the Chimera, and a status meeting for which he needed to do some research. However, when George looks at his computer, he sees both of these items on his “Risk” list, but notices that the computer has listed them as priorities two and three; a new issue is assigned priority one. The chief engineer of another ship, Pegasus, reports hearing an unusual noise in the engine, and the software has indexed this report under engine safety and propulsion capability. This indexing automatically triggers a number of actions designed to help George reach a decision about what to do about the situation on Pegasus. First, the system alerts a number of experts within the shipping company about the problem. Second, it creates online discussion among these individuals about their roles in dealing with the issue. Shortly thereafter, George receives more detail about the engine noise as he reads over an online discussion between the superintendent of Chimera and the chief engineer of Pegasus. This convinces George that he should become directly involved in the decision rather than delegating it to someone else—the discussion clearly communicates that the noise could indicate a serious problem. George spends time



76

77

reviewing all the linked information and experts available to him— information and experts that the system is programmed to send him through the indexing capabilities of its software. He has a list of the experts who have been brought up to speed on the situation as well relevant information—vessels in the shipping company with the same engine, commercial commitments of Pegasus, and so on. George pays particular attention to the stories from the superintendent of Chimera, since his ship’s engine is similar to the one on Pegasus, as well as the Pegasus superintendent. Though he’s never heard the noise the chief engineer is describing, he tells instructive stories about other engine issues that help George think about the problem from a comparative standpoint. The Pegasus superintendent recalls an instance in the past when the engine had a broken exhaust valve but no root cause was assigned. Later, George receives another message from a participant in the discussion that there was another, similar valve problem with no root cause. At this point, George and the other participants are inclined to allow Pegasus to continue to its destination without stopping for inspection and possible repairs. Yet the software system still is indicating that serious risks to the engine and the ship’s profitability still exist because of this noise. This is because the software’s indexing notes that this ship’s engine had two previous unresolved defects without root cause—it retrieved these cases because they were similar at this higher level of abstraction (even though the previous two cases did not involve a noise). This input makes both George and the chief engineer more concerned that a significant problem with the engine could exist. Another participant in the discussion—a retired chief engineer with a great deal of experience—notes how noises of this type are never a good sign, and tells a story of how an unaddressed engine noise led to a major engine breakdown and significant costs. The red flag, though, is finally raised by the software. Embedded in the indexing





are the classic causes of most machinery damage; not following manufacturers’ recommendations and cover-ups by manufacturers of flaws they have discovered in their design. To avoid liability and admitting that a flaw exists in the design, a manufacturer often recommends a seemingly excessive protocol. Upon being warned of this cover-up possibility by the software, the superintendent of Pegasus notices that the manufacturer had sent a circular suggesting the replacement of exhaust valves regardless of condition after relatively few hours of use—a very unusual recommendation. He also notices a valve stem clearance at the time was slightly excessive but the manufacturer provided no conventional means to reduce it. When he makes all this known to George, they have a potential cause for the noise and the other two earlier damages. After a discussion between George and the ship’s owners, he makes the decision to put the ship into a nearby port and an engine specialist is found to do an inspection. He discovers that the noise is related to past valve stem problems and that they must be replaced immediately. This is done, the noise disappears, and the ship is back in service. Without software congruent with cognitive science principles, it is highly unlikely that this decision would have been made. In fact, with a traditional software system, George might not have even become involved in this decision. It was the software’s knowledge of processes, its historical record of engine problems and noises and its awareness of all the key people who should be involved in this discussion that helped identify the problem. Even if George had become involved, he probably never would have been aware that manufacturer cover-ups of design flaws and failure to follow manufacturer recommendations to the letter cause many engine problems. In short, he probably would have allowed the ship to continue to its destination without repairs and the engine would have broken down at sea, creating huge and costly problems.



78


79

Most organizational information systems are adept at providing lists of information. They can track inventory levels and compare them to inventory levels in previous quarters. They can note quality errors in certain plants and determine that they crop up whenever a customer puts in a “rush” on an unusually large order. This data is fine, but it’s not particularly useful without the expert stories, conversations, and historical examples that make the data truly useful. The following story illustrates how software can pull disparate elements together to help managers make better decisions. A large advertising agency found that it was losing a number of major clients after they had been with the agency for between five and ten years. Though this problem was endemic to the advertising business, the agency principals were concerned that they were losing more clients than most and wanted to change their approach to increase retention rates. One faction argued for beefing up client services such as visits to client headquarters and increased online and phone communication; they based their recommendation on an industry study that showed this fostered stronger client/agency relationships. Another faction argued that they should provide clients with more creative ads, since that was the reason one major client cited for firing the agency. The agency CEO was astute enough to realize that both factions were basing their recommendations on isolated evidence. To counteract this behavior, he began working with his information system people to compile a database of expert stories and other types of knowledge related to the situation. As part of this database, he videotaped key account supervisors talking about why their accounts had departed the agency within that five-to-ten-year period. He also taped interviews with account supervisors telling stories about why some accounts had stayed with the agency over this time period. He hired a top marketing consultant with



Focusing Cognitive Processes on an Issue


extensive experience advising agencies on client retention tell a broader range of stories about agencies that had failed to sustain client relationships. And he contacted some of the clients who had departed and asked them to talk about what had prompted them to leave. Though the software system that helped the agency access all this knowledge was not cognitively sophisticated, it still provided them with some insights about what was going wrong and what they might do differently. From all the stories and other knowledge, a predictable pattern emerged— relationships were great at the start and great advertising was produced, but over time people became complacent about the relationship and key creative people would often leave the agency and go elsewhere. Consequently, many clients felt they were being taken for granted and that the commitment and quality of work the agency provided decreased over time. All this helped the agency make decisions that increased the client retention rate. With cognitively sophisticated software, they probably could have increased the rate that much more, since people responsible for client retention would have automatically received stories and other information at just the right time, helping them avoid the mistakes of the past in a more consistent and more comprehensive manner. The following story from the shipping industry—about shipping inspection checklists—demonstrates how software can pull together different sources of knowledge in a highly proactive manner. Shipping is one of the most frequently inspected industries because it’s a global business and many different regional stakeholders are concerned about the quality of management and conditions related to safety, speed, and so forth. During one inspection, the inspector notes an ashtray full of cigarette butts outside the designated smoking area. A decision has to be made about smoking policies, and an overly alarmed captain might decide to ban smoking and enforce the ban with harsh penalties. On the other hand, an overly lenient captain might decide to ignore the incident entirely.



80

81

A good software system, however, can bring all the pieces of the puzzle together, increasing the odds of an effective decision. The software can bring up similar stories from the past that help the captain determine what to do. One story may have nothing to do with smoking but be about a ship’s officer that overreacted to a minor incident. The software might recognize that a retired captain is particularly insightful about compliance issues and should be consulted. It might also call up a relevant report on safety issues. And it might connect the captain with a consultant who is expert in the area of line worker morale and what happens when managers are perceived as treating their employees arbitrarily or pettily. The system might prompt an online discussion that revolves around the questions underlying the smoking incident: is there a real danger to the ship if a spark from the cigarette lands somewhere in the off limits area? Is this type of behavior indicative of people who flout the rules in other, more serious ways? What has happened on other ships when smoking was banned and the bans were enforced? This software won’t force a decision based on statistical data but on cases, whether they are delivered by an expert or emerge as part of an electronic discussion. The software might direct the captain to the story of a previous captain who banned smoking and how he lost 35 percent of his crew within the year. Or it might reveal that a safety inspection conducted by an industry group determined that under specific circumstances, the design of this area has resulted in a number of serious fires that spread quickly throughout the ship.

It’s Easier Than It Looks What all this boils down to is capturing the key stories and directing relevant ideas and information of decision-making value for a given organization. Granted, complexities exist at a micro level—the activity





model for a senior vice president at IBM is different than that for a young manager at a family-run manufacturing business—but from a cognitive science perspective, the stories and issues are relatively simple. Most people in business are facing similar types of decisions, at least at a macro level. Should they promote Mary or John; should they buy company X; should they restructure their team; should they move aggressively to deal with a crisis; should they confront a difficult customer? Think about business decisions from a caveman perspective. More specifically, think about the day of a typical caveman from a cognitive science perspective. The caveman rises in the morning with a very specific goal: hunt for food. But there is a potential problem, since his overarching goal is to protect his wife and small children from predators and he can’t do this when he’s not at “home.” Thus, the caveman makes plans for the hunt. He recruits a fellow caveman to protect his wife and children while he’s away. He brings along an expert in hunting woolly mammoths to assist him, a crude map of the area, and weapons. He also starts on the hunt extremely early because the color of the sky and the massing clouds on the horizon suggest that it will rain heavily later in the day. As you may have guessed, we’ve just described the goals, plans, goal conflicts, and conditions that enter into the decisions made by the caveman. As you may have also guessed, these are not all that different from the goals, plans, goal conflicts, and conditions of business employees. The typical business decision maker enters the workplace with a goal: select a new member for his team. A goal conflict exists, since there are two qualified candidates, and picking either one will result in potential negative outcomes. This person must make a plan, and as part of the plan, he recruits an expert who has extensive experience in the team member selection process. The businessperson arrives at work early, knowing that his boss is going to demand a decision by their scheduled three o’clock meeting.



82

83

Though the world has become far more complex than it was in prehistoric times, the activities and decision-making process remain remarkably similar. For our purposes, that means that organizations don’t need to reinvent the wheel when it comes to combining cognitive science with software to facilitate decision making. There really aren’t that many different goals, plans, goal conflicts and conditions to deal with. Activity models for decision makers and their processes can be mapped. Experts are readily identifiable. Organizations can create software that assists at least some decision makers in key areas with relative speed and ease. If they just tape some experts telling relevant stories around common decision-making points and index the stories in a way that they pop up on a user’s screens when he faces particular choices, they will make a quantum leap in decisionmaking effectiveness. Knowing where to start is the first step. Let’s look at this step, which involves identifying and designing around the pain points.







The Software Argument



Section II




Start with Activity Maps, Proverbs, and Goal Conflicts: Creating Software That Functions the Way the Mind Works

Software may have some knowledge about the users—their job title, the people in their network, the databases they usually access—but it possesses scant understanding of job responsibilities, the particular issues a company is facing, decisions made in the past regarding similar matters, and so on. While a company’s knowledge management system may contain millions of documents, only a handful of them are useful for a particular person in a particular situation facing a particular decision. In most instances, the knowledge management system will overwhelm the decision maker with data and make the decision more difficult—or at least more confusing—than it already is. Generic software won’t “know” to tell a decision maker to talk to a guy in the company’s Hong Kong office who faced a similar decision the previous year. It also doesn’t alert a manager that given the company’s track record in this area, he’s likely to run into a particularly challenging goal conflict and that he should hear a story about how another manager in another division resolved this conflict.



Chapter 4


Computers are perfectly capable of helping people make good decisions, but their capability largely rests on how well they know an industry or organization and its various interconnected activities and goals. With this awareness, software can figure out what data, people, and stories a decision maker needs in a specific situation. Recall our shipping engine noise example from the previous chapter, and the various ways in which the software facilitated a good decision. This included: ●

●

●

●

Alerting George, the fleet manager, about the engine problem by reprioritizing his risk list. Bringing relevant people in to discuss the problem and facilitating the exchange of information. Identifying the processes that might be impacted by that particular engine noise and referencing past problems with these processes. Making the fleet manager aware that the superintendent of another ship was discussing possible risks involving the ship with the noisy engine and might have something valuable to contribute.

The system capitalized on all the knowledge of the industry, shipping fleet, and activities and responsibilities of individuals within the fleet by reminding the right users of what they should think about in this set of circumstances. This software was able to provide all this and more because it had been designed with these relevant activities in mind. In other words, it knew what the fleet manager’s responsibilities were, how they connected with other people’s responsibilities, and the relevant experts and cases for this kind of problem. It was able to connect the dots of a challenging puzzle, anticipated how to bring together people and information in order to facilitate a good decision. Every organization can create this type of software, and the first step involves creating a map of activities that form the foundation of the software design. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


88

MAPS, PROVERBS, AND GOAL CONFLICTS

89

Organizations use object-based software. This means it is designed to help manage things such as inventory reports, budgets, purchase orders, data files, and so on. While it’s obviously useful for a manager to have access to financial data before making an important budget decision, it is insufficient for making a good decision. That’s because the business world is not a static, object-based world. All around the decision maker things are constantly moving. At this very moment, a manufacturing manager may be making a choice that will have a huge impact on the budget. A particular industry trend may be unfolding with significant budgetary implications. But the recently retired vice president of finance may have dealt with some of the same perplexing issues now faced by this manager, and it would be worthwhile to know what the former executive did in a similar situation. Organizations are complex, evolving organisms with histories, and when software is designed as if they’re inanimate objects, it does more harm than good to the decision-making process. No one takes into account what has taken place in the past or who is doing what in the present. To be effective from a decision-making standpoint, the software must be designed with past and present activities as its base. The software must recognize that John in marketing has seven key responsibilities that intersect with Mary’s five key tasks within the corporate communications departments, and that their assigned tasks combined with other employees’ all nourish the decision-making process. Companies are very good at creating organizational charts that map the fixed relationships within a hierarchy, but they should be equally adept at mapping their people’s assigned tasks and how they feed into major business processes. Practically speaking, large organizations can’t map every activity that takes place in their corridors, so they need to identify the purpose of the software. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


A Map of Who Does What, When


The activity models should flow from the purpose of the software. If the system is built to facilitate budgeting decisions, then the activity map must identify the key people responsible for them, their areas of responsibility related to them, the tasks that are part of these responsibilities, and how all this connects to budgeting processes. Mapping is a commonsense activity, and you can get a good idea of what needs to be mapped by drilling below the larger purpose of the software and focusing on the common decision types. For instance, let’s say the decision involves selecting a service provider like an advertising agency. To map the activities involved in this decision, ask and answer questions such as: ●

●

●

●

●

Which marketing employees are responsible for choosing and working with an ad agency? What are their specific responsibilities; what are the most common tasks they perform relating to the ad agency? How do they measure the work of the ad agency; what sort of research do they do to determine if the agency is creating effective advertising? Has any of these people been involved in choosing an agency in the past; what were the specific activities involved; what mistakes did they make; what stories are there related to these mistakes? What roles do people outside the marketing process play in helping select an ad agency; are there people who have left the company but might be useful to include in this process; how do people in parallel activities (i.e., public relations practitioners who select outside agencies) conduct their searches?

These and other questions can help organizations create a map of interrelated activities that impact decisions. All of this can be factored into software design so a decision maker’s computer recognizes who



90

91

does what when it comes to making a particular decision and make sure the right people receive the right information at the right time. Consider an organization that is attempting to decide whether they should hire additional salespeople in order to compete more effectively with their industry’s market leader. The sales vice president responsible for this decision is struggling with the reward of increases sales effectiveness versus the risk of a major expenditure of funds (a typical goal conflict, a topic we’ll discuss later in the chapter). The software doesn’t simply allow him to research sales-versus-close ratios but facilitates an information exchange among seven key people in the department and two outside it on this issue. A veteran internal sales person notes that they have plenty of good salespeople but that some of them—especially those new to the company—are not well-versed in industry issues and often come across as not understanding the prospect’s business. He suggests a new training protocol based on one the company used to have in place but discontinued because of its expense. A retired vice president— someone who was not in sales but had been with the organization for twenty years—relates a story of a company that tried to compete with a market leader in a different industry by bulking up its sales force and how and why the effort failed. A customer service representative included in the online discussion says that customers have complained about how many of the salespeople seem to lack sufficient knowledge about the company’s products and the competitive framework of the industry. All of this sways the sales vice president to invest money in training rather than in adding new salespeople. In normal circumstances, when software is all about objects rather than activities, it is unlikely this decision would have been made. The customer service representative would not have been included in the discussion; the retired executive would also have been excluded. It was only through the mapping of their activities related to this type of decision that they were included in the decision-making process.





Software can be programmed not only to coordinate the efforts of all the right people to make a good decision, but it can remind this decision-making circle of knowledge and stories that might be relevant. As long as the software recognizes what people are doing within the framework of a process or a decision, it can be programmed to remind people of an instructive incident, study, or other experience that could affect what they choose to do. Software can be programmed to do this if it mimics the way the mind works rather than the way a machine works. There are two general ways for software to achieve this objective: from the top down and from the bottom up. A top down approach focuses on the main concerns at the highest level in the enterprise and frames these high level goals, plans, and conflicts within the enterprise as a whole. The bottom up approach involves examining a specific organizational area where new conditions require better quality decisions. In our engine noise example, this bottom up modeling has been applied to the machinery maintenance and procurement part of the business that already has software in place for purchasing and scheduling repairs. Our cognitive modeling, therefore, is applied to the existing software so that it can highlight issues like unresolved problems and excessive recommendations from suppliers.

The Art of Reminding: Software That Works Like the Mind Think about how the mind works. Or rather, think about how the experts in your organization—those “old salts”—make good decisions in complex, confusing situations. Imagine a company’s veteran human resources manager, someone with extensive experience handling



92

93

employee complaints, is dealing with diversity-related issues and resolving discrimination claims before they turn into legal actions. The company has had to downsize 7 percent of the workforce because of falling profits, but a number of the older employees who have been downsized are threatening to file an age discrimination lawsuit. This HR manager is called in to negotiate with them. If you could peer into this manager’s mind, you would see that this negotiation is reminding her of similar cases and experiences. Some are similar because they involve negotiating with other disgruntled groups—where she sometimes negotiated successfully and where sometimes her mistakes caused negative outcomes. Other experiences relate to the current situation more abstractly, such as when she negotiated with her children about their bedtimes because they thought going to sleep before 10:00 p.m. on weeknights was unfair. In that instance, she felt that her kids made some valid points, but at the same time she knew that they would be too tired if they stayed up past 10:00 p.m. Ultimately, she decided to allow them to stay up until 10 if there was a special program on television they really wanted to watch. Even though her kids were complaining about the unfairness of the early bedtime, she knew the real issue was a certain Thursday night TV show that they really wanted to watch. Similarly, the HR manager understood that the downsized older employees had some valid points and that though they were threatening all sorts of legal action, what they really hated was the feeling that “they were being put out to pasture.” After some tense negotiation, she suggested that as part of their exit agreement these employees would be put on a list of “favored consultants” and could expect at least ten hours of work per month. This satisfied the employees and prevented any lawsuits from being filed. This HR manager was reminded of two different stories at two different levels of abstraction. On the lower, direct level, she was reminded





of parallel negotiations—both failures and successes—that provided her with insight into the current situation. But her mind also unconsciously reminded her of an experience that took place in; outwardly, the interactions with her children and with these employees seemed dissimilar, but her mind linked them together conceptually. This kind of “cross-domain” reminder exists at a higher level of cognitive abstraction. To communicate how software can be programmed to remind on both lower and higher levels, we need to explain the concept of “dynamic memory.” People are natural knowledge managers. They receive new information daily, and they decide what to retain and what to ignore, who to pass what on to because they would be interested and what to consider as a problem that needs more thought. They do this effortlessly and, for the most part, unconsciously. They learn and get smarter as a result of every experience. The dynamic memory of the mind is the opposite of the static memory of most knowledge management systems. The latter stores knowledge much as a library does, cataloging information though a traditional group of subject categories—marketing, finance, human resources, etc. Data is entered and updated, but the system never gets smarter through adding experiences and comparing them. There is never an “A-ha!” moment where it recognizes how comparing two different documents can shed fresh light on a problem or expose an opportunity. Comparison and coordination of dissimilar processes and people, therefore, must be designed into the software. It’s not just coordinating all the activities within purchasing, for instance, but coordinating purchasing’s activities with those of manufacturing, customer service, and other departments. Even more than that, systems should be designed to recognize goal conflicts between people and processes, identify these conflicts for users, and also be able to suggest solutions based on them.



94

95

These systems should also tap into what’s going on within the enterprise and the industry—perhaps there’s an overarching corporate goal that might help resolve a conflict between processes or an industry trend that impacts a managerial choice. The human mind, unlike the corporation, manages information well. The corporation drowns people in data, much of it irrelevant to a given decision. The mind, on the other hand, often brilliantly recalls the right case at the exact moment to make a good decision. Software can emulate this cognitive process. Our minds store new information and save old information to make it accessible, albeit sometimes on an unconscious level. We don’t have a look-up procedure like a library does. Instead, our memories change dynamically in the way they store information by abstracting significant generalizations from our experiences and storing the exceptions to these generalizations. The more experiences we have, the more we alter our generalizations and categorizing to meet our current needs. That’s why if we’ve had a sufficiently broad range of experience in the right areas, our minds provide us with the right memories to facilitate good decision making. To create software that mimics the mind’s dynamic memory, we need to structure knowledge differently. Instead of building a knowledge management system that invents categories to store documents, we need to build one based on the categories our minds use naturally. We’ve already mentioned one common knowledge structure: the script. It organizes all our knowledge about event sequences in situations like restaurants, air travel, and certain basic business interactions (i.e. with a banker teller). Our minds unconsciously send us these scripts when we’re dining out, for instance, so we know without thinking how to navigate the menu, order, leave a tip and so on. When someone unusual happens to us in a restaurant—something that’s not anticipated by the current script—we’ll remember it later





through different indexing methods. We might recall the unusual event if we go back to the same restaurant a few months later. We might be reminded of it when we’re with the same dinner companions at a different restaurant six months later. It might come to mind should we run into our waitress from that night at a movie nine months later. In all these instances, the mind uses the knowledge structure or index of “people, props, and places” to recall the unusual incident. However, there is a more abstract indexing method that is especially valuable for knowledge management systems. It has to do with “actions, results of actions, and lessons learned from actions.” One abstraction in this category revolves around roles and tasks. A bank supervisor recalls dealing with a difficult customer who insisted on receiving the incorrect amount of money after cashing a check, and he is reminded of this when he is called on to deal with another difficult customer (his role is to deal with difficult customers). People can abstract at an even higher level when they organize information around plans and goals. Let’s say our unusual restaurant experience was that the waitress dumped a plate of spaghetti on a customer’s head. Someone might recall that incident when they’re in another restaurant and another waitress spills food on a customer’s head—this would be our basic “3P’s” indexing method. On a higher level, one person might index this event as “female rage”; another as “justifiable retribution”; still another as “slapstick comedy.” Learning takes place at this higher level of abstraction. When a new, similar memory joins the one we already have, it expands our understanding of what has taken place. We learn more about waitresses, or about women in general, or about what might be justified as an act of retribution. New events modify existing beliefs by adding new data to what we know or by contradicting what we know and forcing us to come to new conclusions.



96

97

Software can function at the same high level of abstraction. It can learn and get smarter through interacting with users. While scripts efficiently structure knowledge around roles and tasks, higher-level structures facilitate sharing of knowledge across boundaries. Consider the concept of “fixing something.” Within an organization, fixes are going on all time. Managers alter teams, engineers fix broken equipment, HR executives correct people, and so on. All these fixes are different and have individual scripts attached to specific roles and tasks. But at a higher level of abstraction, a system can generalize across boundaries. In other words, the human resources person can learn about correcting people from the engineer fixing machines. And software can learn and become better at facilitating fixes in the same way. This means that the software is capable of self-modification. It absorbs new events that differ in some way from normative events a script describes. Over time and with the integration of differing events, the software modifies knowledge structures so they become smarter. Initially, the software may have only been moderately helpful in helping users fix broken systems. But in time it will have learned a lot about how to fix things, and this knowledge is passed on to all users. It is not particular difficult to design this type of software, as long its foundation rests on scripts that describe specific processes, roles, and tasks within an organization and industry. Generic scripts won’t work—the script for a salesperson at a seven-person firm is different from the script for a salesperson in a Fortune 100 manufacturing company. The software system must be programmed with a great deal of enterprise knowledge—and not contained as data within documents but mapped from activities, processes, people, and all the connections between them. This high-level indexing is akin to principles or proverbs that enable decision makers to gain access to stories and advice from different domains.




98


While it’s obviously important to design software that provides situation-specific cases and advice, it’s just as important to extrapolate general principles from them as well. Many times, business people’s decisions are limited by their experience. As valuable as these experiences are, they can box people in, preventing them from thinking more creatively about situations or considering untraditional solutions. A software system that indexes knowledge at a higher level can provide decision makers with insights gleaned from other employees that they might not ever think to communicate with (because of different offices, different functions, etc.) or stories from diverse areas that may not seem relevant to the decision at hand. Through various experiences, a company’s experts discover truths or overarching principles about their work that can be invaluable. For instance, a manager working on strategic development has spent years competing with a company for market share. For as long as he can remember, he and others in his group has viewed this competitor as the enemy. In the past year, however, the industry suffered a downturn, necessitating a lot of belt-tightening. During this time, a university researcher contacted companies in the industry about funding an effort to develop a new material for use in industry products. No company was able to fund this effort by itself because of limited budgets, but a number of companies, including this strategic development manager’s and their hated competitor, cooperated to fund the research. Eventually, the research yielded a new material that was such an improvement over the former standard that manufacturing costs decreased and quality increased. The principle extracted from this experience can be expressed in the proverb: “make your enemy your friend.” Maxims like this can inspire a company’s software design. They’re valued by employees working in



Pirates and Plants: How Decisions Are Helped by Unlikely Comparisions

99

completely different areas facing completely different decisions. They provide a universal wisdom that can positively impact all types of organizational decisions. For instance, a manager is struggling with a highly talented but high-strung direct report, and he is using his company’s knowledge management system to obtain information about the best way to deal with this type high-potential, high-problem employee. This system, if it’s programmed in a cognitively-astute manner, will not only provide him with relevant advice, but will also share the story of the strategy development manager and how he learned the advantages of cooperating with his enemy. “Make your enemy your friend” was the proverb that connected the two dissimilar situations. Without it, it’s highly unlikely that this manager with a problematic employee would have ever heard that particular story. There’s no guarantee that this story will help the manager make the right decision regarding his direct report, but it will help him think about the issue from a fresh perspective; he might consider the benefits of getting the direct report on the same page and getting more out of his talent. There are proverbs to be gleaned from and applied across all industries. In baseball, there’s, “if you think long, you think wrong.” In other words, if you spend too much time contemplating your moves and fail to just act or react, you’re likely to make mistakes. Don’t think about how you’re going to swing when he throws you a curve; just swing. The batter’s experience will tell him how and when to hit the ball. This wisdom is applicable in all sorts of decision-making situations—analysis paralysis is the bane of many businesses. Similarly, in the shipping world, companies have been struggling with decisions related to piracy on the high seas. For this reason, Roger asked a biology professor the following question: What do plants do about piracy? He wanted to know how plants defended themselves from an invasive species, damaging insects, and so on. The professor responded with scores of successful plant defenses. Clearly, a shipping





company couldn’t directly translate a plant’s defenses against damaging insects to a ship’s defenses against pirates. Yet at a higher level the wisdom is applicable. Or rather, thinking about the way plants defend themselves can provide shipping company managers with fresh perspectives on how to protect their ships. In fact, Dimitris’ shipping enterprise has a list of principles indexed within their software that serve to remind decision makers of key stories and advice when they enter relevant situations. These are essentially shipping proverbs, and include: ● ● ●

Money in the bank and ships on the water Good market bad buy; bad market good buy The trend is your friend.

In fact, every organization prior to designing case-based software should use proverbs as a way to think about indexing. It provides a window into the way the mind works, offering software designers an alternative to traditional ways of retrieving information, such as alphabetically or by key word. By thinking in terms of proverbs, designers can focus on indexing information at a higher level of abstraction. For instance, try the following exercise. Here is a list of common proverbs. Choose one and see if you can translate it into indexing language applicable to your organization. For example, “a stitch in time saves nine” translates to “preventative maintenance on machinery now saves money in the long run.” Then break down this “corporate proverb” into plans, goals, tasks, and roles. The goal is obvious: spending a little money now to save a lot of money later. One plan might be to create a team of free-floating mechanics whose priority is to repair certain machine defects as soon as they become apparent. To coordinate and implement this plan, it’s important to assign the right people (roles) to this team and be clear



100

101

about what they’re supposed to do (tasks). Through this proverbial approach, companies can organize information (stories) around these indices. There may be a story about how a team in the company’s Hong Kong office created this type of team and how it dealt effectively with computer breakdowns. In this way, someone in the London office facing a similar issue will “find” this story and be provided with insight for a decision about their own machinery breakdown problems. Here are some common proverbs to use in this exercise: ● ● ● ● ● ● ● ●

A stitch in time saves nine. Don’t cry over spilled milk. A bad penny always turns up. Every dog has his day. First things first. Penny wise, pound foolish. Take a hair of the dog that bit you. The nearer the bone, the sweeter the meat.

To Find Pain Points, Find Underlying Goal Conflicts As we’ve emphasized, software that adheres to cognitive processes must be tailored to specific organizations and industries. It must be anti-generic, shaped by the often idiosyncratic issues and situations common to an organization. Many of these issues and situations revolve around what we call pain points. As the name suggests, these are areas that hurt companies because they aren’t dealt with effectively. A company may have product quality difficulties; they may fail to capitalize on growth opportunities; they may develop a reputation for poor customer service. Beneath these larger hurts, there are numerous bad decisions that cause the pain. Product quality problems may result





from deciding to buy low-cost materials in order to increase profits; or it may involve a decision to increase assembly line speed to meet customer demands. Beneath the pain points and decisions are goal conflicts. Software design needs to identify these conflicts so that when they occur, the software will remind them of the conflict and suggest stories and advice that helps them adjudicate the conflicts effectively, thereby easing the pain. For example, an organization’s pain point may be poor customer service. Over the past year, the company has received numerous complaints from customers about overly aggressive reps. From an organizational standpoint, management wants the reps to sell hard to maximize profits from its various services. At the same time, they want to build long-term relationships with customers that are not merely transactional but involve transparency, honesty, helpfulness, etc. Software can help the reps adjudicate these conflicts on a situational basis. When a rep is dealing with a customer and he isn’t certain whether to sell aggressively and risk alienating the customer or take a softer approach and risk being ignored, the software can be alerted by the goal conflict and provide expert stories relevant to this conflict; it can alert key people within the organization in real time that this conflict is occurring; it can suggest a conversation that might help clarify matters for the rep. In this way the rep is better able to decide if this is a situation where it pays to sell hard—whether the risk of being aggressive is worth it. To understand what pain points and goal conflicts look like, recall the noise-in-the-engine example from the previous chapter. In that example, George, the fleet manager was contending with a number of pain points and goal conflicts. The most obvious pain point was an engine that might have problems, and the most obvious goal conflict was between stopping the ship for inspection/repairs and catching a potentially dangerous problem versus finishing the trip and delivering the ship to port on schedule. Within this framework, a number of other of smaller but significant pain points were identified: 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


102

●

●

●

103

Excess information. When signs of an engine problem surface, decision makers can be inundated with data. Information overload can create an inability to separate relevant and tangential data. Coordination snafus. The issue here is when people are excluded inadvertently from the communication loop; the decision maker isn’t talking to the right people to help him with his decision or the right people aren’t informed of the problem in the first place. For instance, the supervisor from another ship isn’t informed of the noise problem with the engine and never has a chance to tell George a story about how a similar thing that happened to him in the past. Time constraints. An engine noise can be a ticking time bomb; the fleet manager has a small window in which to make a decision. Similarly, time is an issue from the customer’s perspective. If products aren’t delivered to a given location by a certain day, then customers will be upset and money will be lost, directly or indirectly.

All of this was anticipated in the software design and coordinated to key employees’ activities. It isn’t particularly difficult to figure out the pain points for a given decision maker based on his responsibilities and tasks. While it may not be possible to anticipate the specific type of noise an engine makes in the design phase, it can index stories and coordinate communication based on common categories such as “warning signs”.

Relevance: Recognizing What People Need to Know When Computer can be made to be smart. They can be programmed in ways that ensure that pain points and goal conflicts are accounted for. As 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway




long as the computer is aware of who knows what and who does what, it can coordinate the flow of stories, information and communication channels when a decision must be made. Instead of just providing access to vaguely relevant documents, it can make sure the right people are in the communication loop, it can bring in the right experts at the right time and it can warn decision makers if they’re forgetting or ignoring something that seems relevant to a given decision. All this is easier to do if there is operational specificity. Clear operational procedures, responsibilities and activities exist around enginerelated processes on a ship. If organizations want to create software for top executives in the category of “leadership decisions,” for instance, the effort will probably fail since the category is too generalized and the activities too diverse and diffuse. If, on the other hand, the pain point is high-risk, high-reward acquisitions, operational specificity is much easier to identify—activities of executives are clear in the acquisition process and stories can be indexed relative to the common goal conflicts. This is why the activity mapping process is so important. When software is designed by delineating roles, tasks, plans and goals, when pain points and goal conflicts are accounted for and when knowledge is indexed in retrievable ways, people receive effective decision-making information. More specifically, it is relevant to the decision at hand. So much of the software currently in organizational use provides irrelevant data; it’s irrelevant to the activities and goals of a particular decision maker. The software doesn’t recognize that a particular decision maker isn’t responsible for the data in a given document; it doesn’t realize that there is another area of knowledge that is crucial for him to do his tasks and adjudicate his goal conflicts. Relevance isn’t determined by job title or area of specialization but by specific goals and plans, roles and tasks. Relevance involves what a decision maker is struggling with at a particular moment in time.



104

105

Software can be programmed in such a way to recognize what he’s struggling with and plug him into people, information and cases that are absolutely essential for making a highly specific choice in a highly specific situation. Consider all the areas we’ve covered in this chapter—activity maps, reminding, proverbs, indexing, goal conflicts, and pain points. All these areas provide software designers with ways to give decision makers relevant knowledge. These factors are usually ignored when business software is designed, and the result is software that delivers information that is often tangential or irrelevant to the decision at hand. We have covered a great deal of cognitive science ground here because we want organizations to start thinking about software differently. It takes practice to become skilled at creating software that reflects the way the mind thinks, and implementing even one or two of the concepts advocated here can facilitate that practice. Instead of creating software where information is organized and retrieved by subject or by key word, consider how it can be organized and retrieved by cognitive principles. By reframing the software discussion in these terms, organizations possess fresh perspectives and directions to create more effective decisionmaking software. With this perspective, we can also recognize why the decisionmaking mind responds so well to experts’ stories that are relevant to a particular situation and that are delivered at the moment when they need to be heard. Let’s examine the area of experts and their stories and how they can be integrated into enterprise software.







Identify the Experts and Gather Their Stories

A plant manager is grappling with a decision to implement lean manufacturing methods as a way to reduce waste and increase productivity. She has read a great deal on how lean methods achieve these goals and is concerned about how the processes in the plant have slowed and mistakes have increased. Still, she knows that implementing these methods will be a costly and time-consuming effort. She is aware of other, more incremental, approaches that might yield similar results with a much smaller expenditure of time and money. Her boss is pressuring her to address the plant’s problems, and she has to make a decision quickly. In a typical company, this manager would have a team of direct reports study the issue. She might also call in a consultant who specializes in reducing waste and increasing productivity. The manager or the consultant would benchmark best practices at plants that have implemented lean manufacturing processes. She would also use the company software to provide her team with data and her consultant with past and present productivity numbers as well as projections about dollars lost to waste. She might also do some online research about lean methods.



Chapter 5


And then she would probably make the wrong decision. That’s because it is unlikely that she would hear the right stories from the right experts at the right time. Her knowledge management system is document based, so there are not stories stored on it. Even if it did, this system isn’t programmed to understand the role and objectives of this manager or the others she works with, so relevant stories wouldn’t be indexed in a retrievable fashion. The consultant may have had personal experience in similar situations, but it’s highly unlikely that it’s really applicable; he has little knowledge of this manager’s company and perhaps not even much knowledge about the industry itself. From a cognitive perspective, his experiences may be too limited or narrow, making his case-based reasoning flawed. Benchmarking may yield some good stories, but it’s a hit-or-miss proposition; there’s no guarantee that the stories of this situation in other plants will be useful to what this manager faces. Another plant manager may tell her a wonderful story about how he cut waste by 25 percent using lean methods, but translating that experience to her plant may be impossible because of time or budgetary constraints, different types of equipment used at her plant, its different culture, and so on. However, if this plant manager had cognitively designed software, the system would have recognized the stories she needed to hear based on her roles and objectives. When she got to work, turned on her computer and began discussing the issue with her people on line, she would have received a videotaped interview with one of the foremost authorities on lean methods in her industry relating a story of how a similar company confronted similar issues. She might watch another expert, another plant manager for the company who is located in another country, discussing how he reduced plant waste using an incremental method. Perhaps a third expert, a plant manager who left the company a few years earlier, would tell a story about how the company’s



108

109

conservative culture worked against a successful implementation of a lean program when he tried to carry one out. All these stories are good substitutes for or supplements to real experience. They provide diverse of examples that are relevant to a specific decision-making situation. They can be programmed around common goal conflicts, anticipating which stories will prove useful when these conflicts arise. Where are these experts to be found, how are their stories elicited, and how can a company ensure that the right story is told to the right person at the right time? Let’s first address the question of how to identify these experts.

Old Salts: Who Employees Turn to When There’s a Problem Tracking down experts in a large organization may initially seem like a daunting task. While it’s true that many different employees have many different areas of expertise, most of them possess knowledge that is either so specialized or common that they are not “experts” in the larger sense of the word. Similarly, top executives usually aren’t experts. In many instances, they have been in “generalized” leadership positions for a long time. While they may be very smart about how to lead a large company—how to set forth a vision, strategize, motivate, and inspire—they usually lack the hands-on experience that is crucial for specific processes and functions. To find experts, therefore, organizations need to look elsewhere. Asking employees the following questions will generally produce names of people who know the ropes better than anyone else: ●

When a significant problem occurs, who do you usually turn to for help?



IDENTIFY THE EXPERTS

●

●


When there’s a particularly confusing or complex decision that has to be made, whose input is sought first to help make it? Which veteran employee has seen and done it all; which one is able to tell great stories about the company—its idiosyncrasies, its culture, its way of doing things?

Experts get their hands dirty or, in cognitive science terms, they accumulate a variety of relevant cases. Be aware that experts, at least as we describe them here, aren’t necessarily the smartest people in the room, the ones with “high potential” and corner offices. In large, multinational maritime enterprise, for instance, the veteran mariner chief engineers have the best mix of experiences to handle any mechanical and repair problem. In large organizations, the equivalent of chief engineers exists in every function or department. If a budget has to be revamped to squeeze an additional 5 percent savings out of the year’s projected expenditures, there is an individual who is practiced at this financial art, someone with a knack for finding innovative ways to reshape budgets when the organization is putting on the pressure to do so. If there’s a glitch in the supply chain, there is one person in distribution or purchasing or elsewhere who has seen all sorts of glitches and found ways to deal with them. If R&D is tasked with creating a new product from new technology, there is one person in R&D who has done this more than anyone else in the department. Be aware that all these experts have failed to deal with similar problems in the past. An organizational expert isn’t someone with an unbroken string of successes. That individual probably has constantly worked within a narrow band of experiences, rarely venturing outside his comfort zone and risking failure. He may be good at one thing, but anything that falls outside that small area of expertise is beyond him.



110

111

True, experts have failed, but they have learned from their failures and used them to succeed when a similar issue recurs. A marketing manager may have done a poor job with a product introduction a few years ago, but then followed up with two successful product introductions. Failure followed by success is an identifying trait of experts. While many organizational experts are employees, some will be found outside the organization. In some instances, internal expertise will be in short supply in certain decision-making areas. Your organization may have few people with extensive global experience, yet the company is embarking on a global strategy. You may have once possessed considerable expertise in a given area but because of downsizing or outsourcing you no longer have it. Whatever the reason, you should consider the areas in which you are missing knowledge and skills, and then look for them among the following three external groups: 1. Former employees. One of the great sins corporations commit is failing to tap into the wealth of expertise existing among veteran employees who have retired or left the company. These individuals often understand the organization and industry better than current, less-experienced employees. Knowing how to apply expertise within a specific context is called “savvy.” Being a brilliant engineer is one thing, but being a brilliant engineer who knows how to design products despite the company’s particular cultural and structural roadblocks and with the available resources (or lack thereof) is something else entirely. Former employees are a great source of stories about what happened when the company tried x, y, or z. They know what mistakes have been made when a given manager decided to pursue a particular policy or tactic as well as when savvy choices were made. 2. Academics. These university-affiliated experts have more than theoretical knowledge. They have done more than study a





subject. They have applied what they learned in laboratories or actual workplaces. Often they have had a chance to apply their knowledge as consultants or employees. Because of their academic background, they may bring a greater depth and breadth of experience to bear on an issue. They aren’t as limited as other who may have worked for a handful of companies all their lives. These professionals have integrated their work experience with broader academic study of a particular area. 3. Consultants. As with academics, the advantage of using consultants as experts is that they may have had a greater range of experience than do employees who have only been with a few companies. Consultants who have worked for fifty or a hundred companies in a given area can develop an expertise that can’t be matched by internal people. However, the danger of consultants is that they have broad horizontal expertise but almost no vertical expertise. In other words, they know how to deal with an industry-wide problem, but they have little knowledge of your company. Therefore, their expertise is generalized and may not apply to one specific company dealing with its own unique set of variables. It’s important, therefore, to consider the appropriateness of using a consultant-expert to help with an organization’s problems and opportunities. Do their stories apply to issues the company is facing or do they seem tangential or even irrelevant to your company’s managerial decisions?

Eliciting Their Stories Some experts are voluble and articulate. They are able to tell the perfect story. Others are more reticent. Still others are longwinded or simply don’t know which story to tell. Some of these issues can be dealt with



112

113

in the editing process. Ideally, organizations tape live interviews with experts, since the impact of a story told by someone tends to be greater than one that is written down; Decision makers can better relate to the teller’s struggle by looking into their eyes or hearing their voices. Even people who aren’t natural storytellers make an impact on a live recording if they speak naturally—their authenticity compensates for a less-than-dynamic storytelling style. Editing can compress or reduce digressions in a story that goes on too long. The bigger challenge is extracting the right story from these experts during interviews. Every experienced businessperson has hundreds of stories about his or her area of expertise. The trick is to extract the one story that will be of great use for a decision maker struggling with conflicting goals; a story, in other words, that illustrates what should or should not be done in a given set of circumstances. Here are some tips on how to elicit this type of story: Focus the Questions on Extremes One of the best ways to prompt experts to tell stories with pertinent advice is by asking them questions about extreme experiences. For instance, let’s say the interview subject is an expert in mergers and acquisitions. You might ask —What was the worst decision you ever made in terms of buying another company? —What was the best decision you ever made in terms of buying another company? —Did you ever initiate a merger that seemed great on paper but had disastrous consequences? —Did you ever take a significant risk that resulted in the best merger strategy of your career?





People remember extremes, in large part because they were highly emotional experiences. They took pride in their greatest successes and felt shame, fear or embarrassment over their biggest failures. Because these stories are so dramatic, they are both memorable and impactful. They seize a decision maker’s attention, alerting him to dangerous mistakes as well as to opportunities for achievement. In general, experts like telling extreme stories, and they will do so with enthusiasm. In addition, stories about extreme situations tend to offer the most clearcut lessons. Knowing the worst or best thing you can do in a given situation provides far more useful guidance than knowing a “somewhat good” or “somewhat bad” thing to do. When experts tell their extreme stories, they may need some prompts to get them going. If they provide only a statement about the experience rather than a full-blown account, ask them a follow-up question that forces them to explain. For example: “You say that your decision to merge your company with Enron looked good on paper but turned out poorly. Why were you gulled into believing that things would turn out well? What was it that looked so promising about this merger that you overcame your reservations and gave your approval?” Challenging the causes of an extreme statement motivates the expert to elaborate. He responds defensively to put a bad decision in context or responds with pride to describe how a good decision came about. In either case, he is compelled to tell a story to elaborate on his initial answer. Encourage Talking about Mistakes Some of the most interesting and instructive stories an expert can tell are related to mistakes he has made. Any organization can increase the number of good decisions made if they insist decision makers listen to stories of bad choices from experts who supposedly should have known



114

115

better. Hearing someone who is considered the best in her field recall her blunders is compelling. The listener thinks, “If someone that good at what she does messed up, then I’d better pay attention.” We’ve found that some experts are eager to speak about bad judgments and poor decisions while others are reluctant. If an expert comes from a culture like the U.S. Army, he’ll be more than happy to discuss how he “messed up” in response to a question like, “Tell me about a mistake you made in your job that you really regret, something that in hindsight you know you shouldn’t have done but at the time seemed like the right choice.” The army culture encourages an open and honest approach to mistakes, to analyze them, understand them, and prevent them from being repeated. In some organizations, however, people are reluctant to confess to doing something wrong. In these instances, interviewers must press experts harder, explaining that stories related to mistakes are essential for the software to be effective in decision-making situations. It helps, too, if a company’s CEO or other top executive communicates to experts that they won’t be penalized for admitting they were wrong. To coach experts to tell good stories about mistakes, encourage them to: —Explain what their logic was that led to the mistake; what reasons did they have for making the choices they did. —What actions did they take that resulted in negative outcomes; what did they say or do? —What lessons did they learn from the experience; what did their mistake teach them that they used in other, similar situations? —Insist on the specifics of the story. When you ask experts to tell stories, they may respond with theories or generalities. Not only do theories and generalities lack the impact of a





good story, but they are almost impossible to index properly. When people are facing decisions, a good indexing system allows the software to present users with stories related to their activities. If someone is responsible for dealing with quality management and a minor but troubling defect keeps recurring in the production process, a well-indexed story will appear on this employee’s computer screen as he’s trying to choose the proper response. An expert who is vague or overly theoretical in his discussion of product defects will have his “story” indexed in a way that it won’t dovetail with this employee’s activities—the trigger of a real story won’t be there to be brought to this employee’s attention. Stories have concrete details that allow them to be indexed in a relevant and retrievable manner. Therefore, require experts to tell stories with a beginning, middle, and end. Make sure the focus is on what was said and done rather than theoretical explanations. A story about manufacturing should be rooted in the details of the manufacturing process and not manufacturing theory. Typically, a story starts with a problem or pending decision; it builds through a conflict between two opposing goals or ideas; and it ends with a problem solved or made worse, a decision with a good or bad outcome, a goal achieved and another goal not achieved. All of this detail is essential for a story to work. To satisfy these criteria, you might think that stories have to be long and involved. But actually, they can be relatively brief and still be highly effective in cognitive terms. Consider the following example of an expert story, told by Roger Fisher, a Harvard Law professor and labor mediator who ran the Harvard Negotiation Project. At the time, Andersen Consulting wanted to teach their consultants how to negotiate more effectively, but they didn’t want to send them en masse to Harvard. The following story from Fisher was incorporated into the Andersen teaching software: The union leader was demanding very hard terms. He demanded this and this and that. I met him privately away from the company and 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


116

117

talked to him a bit. My judgment was his real interest was in getting reelected as a union president by looking tough. I said to him, “Suppose you called a press conference and you demand the president of the company come and sign your terms just the way they are without changing a word. Suppose you knew the president would do that.” He smiled at this idea. I said, “If these are your terms, the president will sign it.” He got credit for looking tough and making it his proposal. It was named after him and drafted in the company’s office.”

As you can see, the story has a beginning, middle, and end. It is very specific in terms of who said and did what. It describes an extreme situation—a very difficult labor negotiation. Perhaps best of all, it suggested a fresh perspective on how to adjudicate a goal conflict. Typically in labor negotiations, the conflict is between one party wanting more money and other concessions and the other party wanting to give less. Fisher redefined the very notion of negotiating, providing an alternative approach to negotiating effectively. Here’s another story from an expert, this time a former employee at a large consulting firm. His story is not only detailed, but it also has an emotional component. The consultant is obviously upset at the subterfuge employed by his former employer and his anger makes the story more memorable. He doesn’t sugarcoat the experience, making it far more believable and resonant with an audience: The firm didn’t do consulting in the usual sense of the word. When I went to work there in 1989 I was astonished to see that they really sold software and they managed software installation and use. What they did was so complicated that it required an army of “consultants” meaning young kids who knew nothing to come in to run it. They did a good job of insinuating themselves into the company they were selling to so one could get rid of them. Their clients hated them, though they loved the top person in the consulting firm who had taken them on 100 golf junkets. They charged big prices and had no interest in making better 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway



118


This story is filled with specifics and provides valuable advice for other companies that want to compete with this large firm. It suggests that better software and more experienced consultants would provide a potential competitive edge. Finally, here’s a story from a shipping industry executive about the “game” of buying ships in a certain part of the world: You buy ships from state owned oil companies by knowing local brokers who know which broker’s turn it is to sell. We bought one ship. A guy bought the sister ship from a certain broker and we knew that it was another broker’s turn to sell the next ship. We knew that we didn’t have to bid higher than the price for the sister ship or as high as the market, because the brokers who were paying off the seller, a government agency, had made sure that everyone was happy with that price. They had set up the right incentive for us to be the buyer even at a reduced price.

The story is short, but it offers clear advice to people facing shipbuying decisions. It suggests that the “game” of buying a ship isn’t governed by the usual rules in some countries, and that in a state-run company, brokers are not as interested in the price of a ship as in getting their cut and avoiding trouble.

The Right Stories to the Right People at the Right Time Expert stories are only worth as much as their ability to be delivered in a timely manner to the people who most need to hear them. This



software. In fact, bad software was at the heart of their ability to have big consultants on board to fix it. Their research lab was entirely for show to make it look as it they were inventing things when they were not.

119

means that the software must recognize that an employee is involved in a task or is facing a decision where an expert’s advice is pertinent, and it needs to understand this as the situation unfolds and a decision is imminent. This isn’t a problem in a small company with a limited number of employees, expert stories and tasks, and processes and decisions. When there are hundreds or thousands of employees spread out in different offices around the world, however, it becomes more complicated. As we noted earlier, the easiest way for software to deliver the right knowledge at the right time is when employees are engaged in operational tasks. This means that when people are interacting with the software for daily tasks such as purchasing, personnel issues, budgeting and the like, the software can provide useful knowledge when they’re on the verge of making a choice. In shipping terms, for example, this means that in a small shipping company where one person is responsible for technical tasks, the software knows to send certain stories should he encounter some problems with the ship’s ability to turn. In a large shipping company, however, there may be twentyfive people responsible for technical tasks, with only one recognized expert in solving diagnostic mechanical problems regarding turning. Because each of these twenty-five people has a different set of technical tasks task in turning the ship and each possess different levels of decision-making authority and experience backgrounds relative to each task (and because one story is more relevant to one of these technical specialists than another because of each individual’s particular roles, experiences, etc.), the story delivery process needs to be blended into each person’s daily software use. In other words, stories have to appear on the computer screen as a result of the daily execution of tasks. This integration of story, software, and daily tasks ensures that people experience these stories at the time when they’re working on a problem and must make a choice.





Some decisions, too, are not tied to specific tasks or known processes. When a company is making the transition from domestic to global, introducing a new product for the first time in years, or restructuring the organization from a traditional hierarchy into a flattened, team-oriented structure it is more challenging to design the software so that it can link the right expert story with a more amorphous decisionmaking process. The good news is that correct indexing can help organizations with all these situations, from the simplest to the most complex. When a story is filed in a way that makes cognitive sense, it is easily retrievable based on what a decision maker is doing at a moment in time. Let’s examine a story at a higher level of indexing abstraction. An expert in international software outsourcing was trying to resolve a conflict between software development centers of a company with offices in Northern Europe, Southern Europe, and Asia. Each of these centers wanted to take lead responsibility for the innovative design part of software engineering and the software expert had to choose the right region for the task. Because innovation in general is so poorly understood, specifically as it relates to software engineering, this international software specialist didn’t have much to go on. As he worked on the problem, however, he recalled a number of stories about innovation and listened to others share their experiences in this area. He discovered that most innovations in history occurred under intense peer pressure and the need for people to differentiate themselves. He also found that this pervasive culture of intellectual peer pressure is unlikely in low cost outsourcing regions like Asia, where the demand for conventional skills is so high; they are much more adept at following best practices and excelling in conventional skills. He also found that innovation isn’t a priority in southern Europe because the people there tend to be better at producing software that meets needs rather than improving on software that is adequate. The northern Europe group, on the other hand,



120

121

was in a very competitive environment and had a history of coming up with highly creative software solutions, making it best suited for the innovation assignment. This international software expert had recalled the stories that led him to this decision using two abstractions: “If it ain’t broke don’t fix it” and “Necessity is the mother of invention.” The former abstraction brought him the story about southern Europe’s accepting attitude toward software that was functional but not exceptional. The latter abstraction helped him recall how intense competition among software developers in northern Europe forced them to become highly innovative. These abstractions also helped him index the information about the situations most likely to foster innovation. The point is that abstractions like these help decision makers retrieve knowledge from a variety of sources that probably wouldn’t have been retrieved by indexing at a lower level. Software indexes knowledge in more rudimentary ways than this expert’s mind. For instance, let’s say a shipping company had an experience with stevedores discharging in Iran in the late 1970s. The critical features of this story could and should be applied to many similar cargo problems in other regions. If the shipping company had actually bothered to record expert accounts for use by its employees, the stories could serve as an early warning system to help them avoid these problematic situations. There might even have been a story from a captain of a ship talking about a similar problem he experienced when dealing with stevedores in Mumbai. Yet if the indexing was poorly abstracted, it would be indexed in a way that the story would only appear as an additional voyage expense and be seen only by finance people. It would not be delivered to captains who could use it to make better decisions. Activity models are the solution to the indexing problem. As we saw in the previous chapter, when activities are mapped correctly, the software can be designed so that stories are linked to them. This can





be done on a purely operational level—the person with steering system expertise receives stories related to this subject—or more abstractly— stories are indexed conceptually. The latter ensures that decision makers receive expert cases that relate to the goal conflicts they face as well as cross-domain stories. When activity models have been the basis for software design, the computer knows that John in accounting is responsible for deciding whether or not to implement a new accounts receivable system to create greater efficiencies; it recognizes that John is grappling with whether to implement the costlier but more flexible system or the cheaper, more rigid one; it can give him an expert story about resolving a similar situation involving an accounting system; it can also provide another expert story related to the cost versus quality goal conflict. We understand that companies don’t routinely map the activities within their organizations and even less frequently use these maps as part of software design. Without them, however, even the best expert stories will get lost within a vast system. It may seem as if filing stories alphabetically, by function, or in some other simple way will make them accessible, but we can tell you from hard experience that this is false. People don’t know where to look for the stories they need or even know that they exist. Remember what we explained about how the mind works—when people try to make good, conscious decisions, they end up enslaved by flawed logic. They want to make a good choice between vendors, but ultimately choose the wrong one because they’re relying on limited experience or adhering to company rules or policies. In other words, don’t expect decision makers to know the stories they need to hear for a given situation. They know unconsciously, of course, but this means little when they’re searching the knowledge management database for stories applicable to a particular set of circumstances. However, software designed in a cognitively right way can use activity models to effectively funnel stories to those in need of them.



122


123

Some organizations tend to rely on one expert to tell the same story ad infinitum. By that we mean that when in doubt or in need of answers, people will turn to one authority figure for help. Sometimes this is the CEO. In other instances, it’s a veteran in a particular office. The company leadership may also subscribe to the expertise of a well-known business guru. Similarly, certain stories have been told so often within a culture they attain the status of verities that no one challenges. They may be stories about an enormously successful new product or a tremendous effective growth strategy, but they’re always about what the company has done best. We advise using an unbiased and wide range of experts and stories. Seek out the experts in-house who emerge from the criteria we’ve suggested, the ones clearly acknowledged as sources of wisdom among their peers. Don’t blackball one expert because she doesn’t always toe the party line or another because he lacks hierarchical authority and political clout within the organization. Too often in large, politicized companies, multiple points of view aren’t heard. Decisions will be made without an expert advocating the unorthodox choice. Choosing an expert based on superior expertise rather than any other criteria ensures that people will be hearing the right stories—if not necessarily the politically correct ones. Stories should also be chosen because they provide insight and knowledge essential for good decisions and not because they reflect the corporate vision. A story that teaches it’s sometimes necessary to take shortcuts around the chain of command in order to get things done may seem heretical, but the real world value of its advice should trump the occasional heresy.



A Diversity of Experts and Stories


Finally, we cannot overemphasize the importance of providing decision makers with access to the very best experts and stories when they face tough decisions. Consider how many times an organization’s managers struggle with “right-versus-right” decisions; or how often it seems that no matter what they do it’s like choosing the lesser of two evils; or how there is so much ambiguity and complexity surrounding decisions that it’s impossible to know what to do. In this era, we need the best and most objective experts we can find. Tough decisions require nothing less. By integrating them into software design, organizations preserve the knowledge that is most meaningful for their people. Every company has expertise, but much of it is inaccessible or underutilized. Retrievable expert stories indexed properly give companies a huge decision-making advantage. It doesn’t matter whether people are making decisions in corporate headquarters, on the road thousands of miles away, or a satellite office in another country. Software gives them access to the experts and stories they need to hear, and they can access them through the computer on their desk or a hand-held device. As long as organizations make sure they have chosen their experts and stories correctly, every decision maker in every part of the organization will benefit.



124

Finding Information versus the Information Finding You

We have focused the need for software to be activities-based and to integrate experts and their stories with these activities, but we have only touched upon an issue that is of great concern to decision makers within an organization: using software to obtain relevant information and engage in useful online discussions on the verge of a choice. In most companies, decision makers spend a great deal of time and effort searching for information and sending, receiving, and wading through e-mails to help them make tough decisions. They may dimly recall receiving an e-mail from Fred in the Los Angeles office a few months ago about a problem they’re handling or they may find themselves in a situation where they need information about competitors’ moves in an emerging market. Whatever they require, obtaining it is a chore at best and a nightmare at worst. They can’t locate the e-mails they deem important; they don’t remember other e-mails that have a bearing on a decision; they don’t realize that John or Mary in some other corner of the company has the knowledge that they are actively (and often, futilely) seeking; they locate the information that they are searching for but don’t realize that it is incomplete or that other people



Chapter 6


in their organization have additional knowledge that puts that information in a much more useful context. When organizations are relatively large, valuable information is lost or inaccessible for a variety of reasons. The sheer number of e-mails most business decision makers receive makes it difficult to separate the wheat from the chaff. The typical manager in a large company receives hundreds of daily e-mails; it is often impossible to know which ones are important and demand top priority and which are secondary or tertiary. Some get skipped; some are read, but people either forget to respond or don’t realize that they need to respond. Because everyone feels compelled to “cc” scores of other people on almost every e-mail the volume proves overwhelming. While much valuable information is contained in e-mails, this information is rarely integrated into a company’s knowledge management system and retrieving it days, weeks, or months later becomes difficult, if not impossible. Searches, whether of internal corporate documents or external sites, tend to bring up a great deal of irrelevant or tangential information. Perhaps most alarmingly, decision makers aren’t connected to the other employees within the organization who possess vital knowledge for a project or issue; e-mail and search processes don’t naturally alert these individuals to the decisions they’re facing and the help they’ve sought in making them. However, the cognitively based software system that we’ve been describing can solve these problems. Let’s begin with the problem of e-mail and what good software can do about it.

Smarter Than the Smartest Secretary Most of the e-mail systems used in organizations are not as smart as even the slowest-witted, most inexperienced secretary. As useful as



126

127

e-mail is as a communication tool when compared to snail mail, it is slow and inefficient and often does more harm than good, especially when it comes to decision making. Typically, companies don’t even view e-mail as a facet of their knowledge management systems; they see it as something apart. For these organizations, e-mail is little more than electronic memos and letters, having no relationship to the strategic dispersal of knowledge to key employees. They have minimal expectations of e-mail, and they aren’t disappointed. In fact, e-mail can and should be an integral part of enterprise software. It should not simply be an electronic secretary but a new, higher form of administrative assistant; it should remind, prioritize, and coordinate. Consider what secretaries can do for managers that a typical e-mail system cannot. They can screen calls. They recognize the priorities a boss has and can help figure out a schedule that fits these priorities. They can listen to a boss complain about a problem or struggle with a project and suggest who in the organization has expertise that might help. These prioritizing, reminding, and coordinating functions help a boss work more efficiently and effectively. Computer software can also prioritize, remind, and coordinate, but it can do so on a scale and with prescience unachievable by even the best secretary. While secretaries have certain advantages over computers, computers have some advantages over humans. This is especially true when it comes to the way people use e-mail in business settings. In their personal lives, people use e-mail randomly and idiosyncratically. There is no predicting whom they might e-mail at any given time. They might write to an old college friend in response to an offer to buy their car or to communicate with a fellow hobbyist they met on a Web site. In large enterprises, however, employees do not act as free agents. As we have seen, they generally do what is dictated by their roles and responsibilities. Their e-mails reflect their tasks within a well-defined



FINDING INFORMATION


process. They send messages to the people they are expected to, often to request that the e-mail recipients take a certain action. Unwritten e-mail protocols exist based on job roles. For instance, a manager is expected to copy his manager and three other people when he sends e-mails relating to a budget decision. Therefore, e-mail is not a freeform exercise but part of a routine set of processes that fit together very specifically within the enterprise. While software may not be able to coordinate, prioritize, and remind people when it comes to personal e-mailing, it is adept at doing so in business because of well-defined roles and processes of corporate culture. If activity models are part of software design, the computer knows what is important to various managers. It can recognize that one e-mail is more important than another, that five people in the company must be copied on an e-mail about subject A, and that it is urgent that one manager respond to a certain e-mail immediately. Most software allows e-mail to be free-form text, but it would be far more effective from a decision-making standpoint if it were structured text. Company software enables people to write whatever suits them in any form and at whatever length they choose. Consequently, indexing is impossible because these e-mails lack any cognitive logic. However, if organizations imposed a structure on e-mail communication, it would be easy to index. The software could require employees to write in a clear format: tasks, plans, and goals, allowing the system to retrieve relevant e-mails automatically. If it knows that you are working on a plan to increase profits in a plant by installing new equipment, it will show you e-mails related to your specific plans and objectives. E-mail software should know how information flows within a process, to whom and why, and what goals are related to different pieces of information. In this way, it can catch omissions to an e-mail list and remind a sender that she has forgotten to copy a key person in



128

129

the company. Or it can communicate to a decision maker that he has neglected to act on the information he’s been sent—he forgot or perhaps didn’t want to and “nudges” him to do something about it. Similarly, when employees compose e-mails, they do so within the context of relevant information and not in an informational vacuum. In other words, the software recognizes the situations and subjects of their e-mails and provides them with related information. The contents of an e-mail trigger a response from the software in the form of stories and other knowledge. The software can then send e-mails that provide the right people with the right information at the right time. Once again, it is a case of information finding people rather than people finding information.

Two E-Mail Scenarios The value of a cognitive-based e-mail system to decision making becomes apparent when we contrast its performance with that of the traditional e-mail system. The following is a real situation from the shipping industry. Scenario 1: Traditional E-Mail System Tom, a shipping company executive, has been temporarily placed in charge of five fleet vessels while the company searches for a replacement for someone who recently quit to join another shipping company. During this period, Tom receives an e-mail from one of the ship captains requesting assistance about a problem with the propulsion system. This problem, if not resolved quickly, will create costly delays and other difficulties. Tom has a number of alternatives for dealing with this situation, but his experience in this area is limited, and he needs to contact other people in the company before making a decision.



FINDING INFORMATION


One of the first things Tom does is e-mail other shipping company employees around the world who might know the best course of action to take. Back-and-forth e-mails with eight different company employees produces nothing of value; Tom wastes a lot of time searching for someone with relevant experience. Because the propulsion system issue is a relatively infrequent problem, there is no obvious person for Tom to turn to for assistance. Because there are numerous options for dealing with it, Tom can’t decide on one easily. He has one of his assistants use the company’s knowledge management system to scour corporate history for anything related to this propulsion problem, but all his assistant finds is tangential documents about the technical aspects of various systems used over the years. What Tom really wants is someone to help him analyze the pros and cons of each alternative for dealing with the problem, and no one seems to be capable of helping him in this regard. He recalls that his predecessor had to deal with a somewhat similar problem two years ago, and he knows that there must have been e-mail correspondence between his predecessor and others about it, but when he logs into this former employee’s e-mail, he finds it impossible to locate what he’s hoping to find—there are thousands of e-mails to wade through and the subject lines provide poor guidance for locating the desired information. Eventually, after consulting via e-mail and phone with other shipping company executives, he chooses to fix the propulsion system immediately at the next port. While this solves the problem, it is a costly fix because the ship is out of commission for a lengthy period and other significant costs must be incurred. Three months later, Tom is at a meeting at the company’s headquarters and runs into Nick, a retired ship engineer doing consulting for the company. During their conversation, he relates his experience with the propulsion system. Nick tells him that he faced a similar problem two years ago—it was the one Tom’s predecessor had been involved



130

131

in—and that there had been no need for an immediate repair since he had found a temporary fix that held until the ship was due for its routine maintenance service. Later, Nick sends Tom an e-mail detailing this case. Unfortunately, when Tom goes back to work and a replacement takes over the five ships, this e-mail is never forwarded to the new hire. Even worse, it is never indexed in a retrievable way within the company’s knowledge management system. Thus, if the propulsion problem ever recurs, it is likely that no one will benefit from Nick’s knowledge. Scenario 2: Cognitive-Based E-Mail System When Tom receives an e-mail informing him of the problematic propulsion system, he is able to use his software and focus in on the topic, “Trouble-shoot and diagnose machinery issues.” This “task-and-role” software is then able to refine his search and zero in on propeller problems, providing Tom with a collection of stories and information related to this issue. More to the point, it shows him who within and outside of the organization should be included in an online discussion of the problem. It presents him with a group of e-mail addresses and information about each individual on the list—Nick is one of those included. Tom then sends an e-mail about the situation to the people on this list. The software includes a feature that lets Tom know whether the e-mail has been read or not, allowing him to follow up appropriately and quickly. Everyone on the e-mail has access to the same information. Because the e-mail is connected to enterprise software, everyone can view expert stories and see the historical data that will influence their recommendations. The system is aware of everyone’s roles and tasks, and it makes sure that only appropriate individuals who are likely to have relevant experience are included in the mailing.



FINDING INFORMATION


The system also provides Tom with access to his predecessor’s e-mails, and in this way he is able to locate the similar problem from two years ago and see how it was handled. This precipitates a conversation with Nick who Tom now knows was involved in that incident, and their correspondence allows him to reach the good decision within twenty-four hours after the captain requested his assistance. Just as significantly, the e-mail system records this recent situation involving the propeller and indexes it properly, making it easy for the next shipping company manager to encounter this issue get up to speed on what to do.

Retooling Search Engines Managers facing a tough decision need relevant information quickly, yet when they conduct a search they often receive irrelevant information slowly. As much as the media hypes Google and other search engines, these operate within the framework of 1950s-era technology, firmly rooted in old information retrieval concepts. Organized around key words, search engines often misinterpret requests and retrieve irrelevant data. The classic example is someone who wants to discover something about Ford Motor Company and instead receives information about President Ford or how to ford a stream, or receives “hits” that are about the history of Ford Motor Company when what the searcher really wants is information about the redesign of the Taurus, or finds data about the Taurus design but not about the process by which Ford incorporates this design into its branding message, which is what the researcher, who works at Chrysler, needs to make a decision. While it’s true that some people are better than others at refining searches to find what they need, most end up with the wrong information because the search engine misinterprets their “precise” words



132

133

and sends them one type of irrelevant data, or their “imprecise” words retrieve another type. In some instances, people don’t even realize how bad their searches are because they won’t know what they really need until they find it. They conduct a search, the information retrieved seems somewhat relevant and they’re satisfied. In fact, if they had a truly effective search engine, it would bring them information they wouldn’t even have thought to search for but will a huge impact on their decision. The new CEO trying to decide about restructuring a division may not realize that three years ago his counterpart at a competitor undertook the same sort of restructuring with disastrous results. A good search engine would have indexed this information and made it easily retrievable because of its knowledge of the CEO’s activities, his company, and the industry. Unfortunately, most CEOs in this position would search with the words, “company restructuring” and be inundated with mounds of irrelevant data. All this wastes time. When people are trying to make quick decisions, searches delay rather than speed up making choices. This is true even when it’s relatively easy to narrow the search field because the search is conducted on a proprietary site or because a unique domain name helps target the inquiry. Managers may be searching for demographics in a new market or technical information about an emerging technology, but they will receive information that isn’t quite right, such as demographics for the wrong year or data that is missing important details, or information for the previous generation of technology rather than the most current. There is always something in the search that frustrates and delays. Fortunately, cognitive science combined with innovative software design provides alternatives. Searches, like all the aspects of enterprise software that we have been discussing, should be organized around the way the mind works—via tasks, roles, plans, and goals on the most basic levels. A manager may be searching a knowledge management system for information about



FINDING INFORMATION


how to reduce overhead by reducing capital expenditures incrementally. However, when he conducts a search, the system gives him all sorts of documents related to reducing costs but none have the specifics he is searching for. Because of the way the system indexes information—by subject, such as “cost-reduction techniques”—it is incapable of going through the millions of documents to find that needle-in-the-haystack report he needs. However, if the search were organized cognitively, it would recognize his specific goal—reducing capital expenditures incrementally—as well as his role and tasks in achieving this goal and direct him to the information he needs. Searching should be “computer-intuitive.” By that we mean that it should happen as a result of what a decision maker is doing on the computer. If the system understands a user’s tasks, roles, plans, and goals, as well as how they fit into the larger domains of the organization and industry, it can recognize the issues this user is dealing with and anticipate his search needs. It essentially turns “search” into an ongoing activity, something that happens automatically based on what an employee is doing on his computer—it searches in response to an e-mail, a spread sheet, or any other sort of computerized activity. Let’s use another shipping example to explain how this works. A ship captain is arriving in a port and logs onto his computer, noting that he is approaching the port of Hound Point, he asks for information under the term, “arrive in port.” The traditional search engine immediately retrieves hundreds of documents—everything from general instructions for preparing for an arrival to information about ports that have nothing in common with Hound Point. Even the information retrieved through the enterprise portal is flawed, containing out-of-date information as well as data for ships dissimilar to this particular one. While the enterprise portal may have a more detailed understanding of the company and its ships, it still has little concept of what this captain requires for his decision making at this place and this time.



134

FINDING INFORMATION

135

●

●

●

●

●

Information about the Hound Point port that the captain would not even think to search for but might be relevant, such as liability conflicts. It would recognize based on the system’s activity models that such issues might be relevant to the captain as he’s arriving, and it would look beyond the web (in corporate databases and other private sites) to find them. Knowledge about arriving at Hound Point related to events and trends in the shipping industry. Specific obstacles related to arrival in this port, including detailed information about water depths, dredging activity, etc. A history of what happened last time this captain’s ship or a similar one with similar cargo arrived at Hound Point, highlighting the differences and similarities between now and then. New procedures the company has instituted relative to arriving in ports, especially Hound Point and similar ports.

This type of search will not only save the captain a great deal of time because he won’t have to wade through irrelevant information, but it will also deepen his knowledge to the point that he can make a better decision about whatever issues crop upon arrival. If a search engine is incapable of finding relevant knowledge, the ship captain is better off making a call to a colleague or the port agent than depending on a search to find what he requires. Most searches are akin to looking for the proverbial needle in a haystack. Unless a manager is using an unusual domain name (i.e., key words “singer, Englebert Humperdinck”) it is difficult to find the precise information that will facilitate a decision. This is especially true for business decision makers when they’re confronted with millions of internal documents. They need to find a



Now let’s look at what a cognitively-programmed search engine would find and where it would find it:


manufacturing white paper and two thousand exist within the system. They want to locate an e-mail they sent to a customer, and they’ve sent that customer thousands of e-mails over the past few years. They are interested in knowing the results of a customer study that they vaguely recall provide insight into a customer service issue they’re facing and there are hundreds of such studies in the database. Even more problematic, if they are able to find these documents, they sometimes aren’t what being sought. They may think they are searching for information about customer service, but what they really are concerned about is adjudicating a goal conflict involving their limited budget and customer complaints. Software that is designed based on activity models can anticipate what a decision maker is really searching for and provide it. To understand how this software is designed, we need to tell you about a hypothetical octopus.

Eight Arms, Eight Brains As you know, an octopus is a sea creature with eight arms. Imagine this octopus doing something with one of these arms—catching a fish, for instance. It stands to reason that an octopus can parallel process; it knows what each arm is doing so it doesn’t have two fighting over which gets to grab the sea urchin it finds. It is also reasonable to assume that the octopus’s mind is like a central processor that absorbs the experience of each arm and tracks its given goal. For instance, if the second arm is struggling with something and needs help, a signal is sent to the eighth arm, which is in the best position to provide that assistance. It might be that the third arm has already confronted this situation and has a helpful idea for the second one, so the octopus’s central processor relays that idea. And it turns out that the sixth arm is trying to fend off a predatory fish while all the other arms are otherwise engaged.



136

137

Now imagine if this octopus has eight brains instead of one. This would make efficient use of all the arms more problematic. Eight brains means eight different sets of experience, and if the brains didn’t have a central system coordinating them, then the arms would not operate effectively. Many tasks would repeat and there would be gaps in useable knowledge. Arm number 2 might spend a great deal of time digging out food from the sea bed while arm number 7 is doing the same thing instead of helping number 2 in its task. On the other hand, if this octopus had a central processor to control all eight brains, it would be a rather brilliant octopus, defending itself and finding food better than any octopus has ever done. You might say that it would enjoy a competitive advantage. Organizations are like the octopus with multiple brains and no coordinating central processor, only instead of eight brains and eight arms, there are thousands. While this lack of coordination results in duplication of effort and people dropping the ball when action should be taken, it also has a huge and negative impact on decision making. Joe in one division never received the e-mail from Joan in another. Joan was looking for employees to join a cross-functional team to address a critical organizational issue; Joan assumed that people in Joe’s division would not be interested in or qualified for the team, when in fact Joe was not only interested but had the perfect mix of experiences to help the team. Joan decided on her team members and didn’t include Joe, but she surely would have if he had been on that e-mail. A central processor would have connected the dots. Even if Joe were left off the e-mail list, the processor would have known about Joe’s particular experiences and roles within a division and communicated to both Joe and Joan the opportunity of the cross-functional team. Many organizations expect their knowledge management systems to act as this central processor and control all the arms of the octopus. In fact, that is the promise that sellers of knowledge management



FINDING INFORMATION


systems often make. We recognize that your organization may have invested significantly in such a system based on this promise. We also understand that this creates a vested interest in finding a way to make the system work. Unfortunately, it will only work in a limited fashion. It is not designed to fulfill the cognitive mission of having knowledge find people; it is not built so that searches and e-mail flow to decision makers are guided by their roles, tasks, plans, and goals. To help you understand the limitations of a typical knowledge management system, let’s dig a bit deeper into what such a system entails. Here is what the Lotus software people think knowledge management entails: Based on its experience and on the existing large body of literature on the subject, the team decided that knowledge-management software should provide virtual “places” where users can organize information, services, and tools to support their particular needs while simultaneously maintaining and updating information in a more general context.1 In other words, Lotus thinks knowledge management is the creation of a communal library, and it seems as if IBM shares this view. Here is an IBM publication touting Spandan, a system that Satyam developed for the petroleum industry, “a complete knowledge management (KM) portal built from several IBM Lotus and IBM WebSphere software products”2: Spandan consolidates all the knowledge in the R&D organization into a central knowledge repository, organized in a taxonomy that makes sense to everyone,” says Agrawal. “It captures lessons learned and best practices as they’re created or refined. It enables users to quickly find 1

W. Pohs, G. Pinder, C. Dougherty, and M. White, “The Lotus Knowledge Discovery System: Tools and Experiences,” IBM Systems Journal 40, no. 4. 2 Satyam’s IBM Lotus KM Solution Helps Petroleum Company Fight Change With Knowledge, www.ibm.com.



138

FINDING INFORMATION

139

This may sound good, but it presumes that people will want to contribute to the knowledge depository, that they will want to use it, and that they will know how to look for and find the exact information they need. Knowledge is not like Mount Everest; people will not climb a mountain of data just because it’s there. While they may occasionally search for and find an obvious file, their searches are generally inconsistent and often ill-conceived. If they had elephantine memories, they might be able to recall five e-mails sent or received during the past few years that are relevant for a decision and could be retrieved from the library. If they knew every veteran in the organization, they might be search and find the right expert with the right story to facilitate their decision making. If decision making were a conscious rather than an unconscious activity, they might recognize that they needed to explore cross-domain sources to help them think about a decision in a fresh way. When we are faced with an important decision our minds search unconsciously, but they don’t need or use key words. Instead, the present decision reminds them unconsciously of an analogous experience and if their mental index of cases is wide and relevant, more often than not they will make a good decision. In this way, the information finds them. Computer systems should be designed so that information finds decision makers, guided by the following three principles: 1. They help information find decision makers by knowing what these people are doing and therefore knowing what information they might need.



both explicit knowledge, such as knowledge in documents, and tacit knowledge, such as knowledge in discussion threads or in an expert’s mind through a single unified search. And it combines all these functions with collaboration features, such as instant messaging and teaming that help people work together in context with knowledge.

140


Corporate memory is what this system provides and many companies lack. It’s not just the static memory of numerous, alphabetized documents but continuous tracking of daily events as they relate to what has taken place in the past. The system must know the roles and tasks that every individual in the company has to perform, and it must know that given any action, it is reasonable to expect another particular action to follow. In this way, it can effectively index a huge, diverse group of knowledge. Recall our octopus metaphor and know that the challenge is not coordinating the operation of eight separate entities but thousands of them. When you consider the thousands of e-mails that flow through a company weekly, the historical events—both failures and successes— that provide insight, and the many expert stories relevant to a wide range of decisions, you grasp why vast document files, no matter how well organized, are relatively useless. On the other hand, cognitive-based software uses its activity model to maintain predictions and expectations about the flow of events in an organization. If an expectation derived from this structure fails to be met—or more specifically, if a decision to do something results in a negative outcome—then this information is captured and indexed. The next time a decision maker faces a similar situation, she will receive the “story” of this failure, including all the relevant e-mail exchanges about it and the wisdom gained from it. If a manager is considering firing a senior executive who is over fifty-five years old and will be fully vested in the following year, the system will automatically search, find, and send him information about what took place in previous years when



2. Decision makers do not ever try to add information into the system. Their work is added to the system automatically. 3. The system knows what it knows and is getting smarter all the time.

141

a manager attempted to fire a senior person in similar circumstances. He can see the e-mail exchanges between HR and the legal department that preceded that earlier decision, the expert stories related to both this case and others outside of this domain, and other related knowledge. As point 3 suggested, the system is always getting smarter because every decision builds on another and impacts the knowledge indexed and what is sent to the next person facing a similar decision.

Communicating to Solve Goal Conflicts What makes many important decisions so difficult is underlying goal conflicts. The CEO of a public company is torn between pleasing Wall Street by cutting staff to make his numbers look better and devastating company morale by firing good people who are the future of the company. Often, CEOs and other managers make the wrong decisions when conflicts occur, not only because they lack the requisite experience in an area, but also because no one is helping them adjudicate the conflicts. Cognitive-based software is well equipped to adjudicate through its communication capabilities. This is true whether or not decision makers are aware of these conflicts. In many typical business situations, people are so caught up in their own issues that they don’t even bother to assess the conflicts between one stakeholder and another. They simply decide based on what seems best from their perspective, and what is best for them may not be best for the organization. It may simply be politically expedient or relieve a short-term pain in exchange for longterm problems. A software system can be programmed to be aware of the common goal conflicts decision makers face. While the specifics of the conflicts may change, the types of conflicts are relatively small and thus



FINDING INFORMATION


recognizable by the computer. The system would track all online communication and analyze the goals underlying a specific decision maker’s message and monitor the messages of other people involved in the same activity for conflicting goals. When these conflicts are identified they are automatically brought to the attention of the decision maker and all related parties (i.e., the decision maker’s boss). Past similar conflicts that had led to major failures are also surfaced and communicated. In this way, managers can recognize common mistakes made when dealing with goal conflicts and use this to make better decisions. In the shipping industry, goal conflicts are common around decisions points. Typically, the conflicts involve safety versus speed. The charterer, for instance, is focused on getting the maximum amount of cargo shipping to a given port on time. The operations manager wants to achieve this goal, but not at the expense of hurting the ship or any of the crew—safety is his priority. Many times, decisions must be made where there’s no clear choice between speed and safety; where in an operation manager’s mind, a small risk means the ship needs to slow things down for inspections and repairs; where the charterer believes the risk is so minimal that any delay is unacceptable. But there are many other people who are involved in the conflict, making a decision more complex than it might seem on paper. Fortunately, aspects of the process are predictable because the goals of the individuals involved are well defined by their jobs. Here are four categories of participants: 1. Those responsible for the maintenance of the vessel. Their goals are simple. No accidents. No spills. If it were up to them, ships would never leave port except under perfect conditions. 2. Those who are solely responsible for business. These may be charterers or ship owners. They want the vessel to be moving all the time as quickly and as cheaply as possible.



142

143

3. Those who have their hands in both categories. These are ship owners who both want to make money but also want to have a happy and healthy ship. Such people often are in conflict with themselves. 4. Those who are caught in the middle responsible to each of the above three categories. They want to make money and they want the owners to be happy and they want the agents and charterers to be happy. But they also want the engineer and captain to be happy. No matter what title this person has, his role is that of negotiator. Software can facilitate communication among all these individuals as it relates to their roles and goals. In making a decision about safety versus speed, the software can remind the charterer that a safety problem will impact his reputation, citing examples of how this impacted other charterers in the past. It can remind the owner that the charterer stands to lose a significant amount of income if a delay occurs and that in the past, this loss has been reduced or eliminated by transferring cargo to other vessels in the fleet. Without this software, people don’t communicate effectively about their conflicting goals. They are unaware of the similar past experiences they could learn from. They leave out key people from the discussion. They forget why another person is so adamant about their stance; it’s only when they’re reminded of why that they become more open to alternative solutions. They also fail to frame the discussion in terms of the goal conflicts so it’s harder to take the other person’s requirements into consideration and arrive at alternative courses of action. Cognitive-based software can encourage the right people to talk about the right things at the right time, thereby arriving at a decision that is truly reasoned rather than rationalized. This software is



FINDING INFORMATION


situation-specific, unlike the generic “balanced score card” approach. That approach often relegates situation-specific hazards to “details” rather than recognizing them as the main hazards of a process. For this reason, a balanced scorecard decision-making methodology would not discover that the local pilot and agents in a specific port make money off ships going aground—a practice that was stopped centuries ago in other ports. This allows reason to drive the decision-making process, providing people with situation-related knowledge critical to determining the best course of action.

Design Software with an Octopus Central Processor Forgive us for extending this metaphor, but it an essential one to guide software design. The concept of coordinating decision making among multiple arms is infinitely preferable to storing information into files by types. The central processor design of the octopus revolves around five mental abilities. These same abilities should be built into a software system: ● ●

●

●

●

Storage: As information comes in, it must be put somewhere. Labeling: By slapping a label on each experience, it helps the system to find it again. Modification: As more knowledge comes into the system, it modifies what is previously known. Failure; All modification to a procedure is rooted in failure; something has gone wrong, which is why a new procedure must be created. Explanation: Assessing what went wrong so the same thing won’t happen again.



144

145

These five abilities describe a dynamic rather than static way of indexing new information. When fresh information is available, any relevant arm must be made aware of it right away if, and only if, it will be using it right away. Otherwise it should be told of that information when it does need it. If this knowledge is relevant to a given procedure it must be indexed in terms of that relevance. If it has relevance in more than one place, it must be indexed multiple times. Processing relevance means having a memory come to mind just when it is most useful for what is going on at the time. Software can be designed to have processing relevance. It can ensure that e-mails are incorporated into the central processor, indexed properly and recalled when the information is most needed by a decision maker. It can automate searches to be ongoing and proactive—when a decision maker needs a particular piece of knowledge, it appears on his screen. It can also foster the type of online dialogues that help people find smart solutions to goal conflicts rather than make random choices.



FINDING INFORMATION




Decision-Making Training: More Experience through Software

Our focus in this section has been on using software to facilitate performance-supporting choices, the idea being that employees need information, expert stories, and other people’s input to make better decisions in their jobs. We’ve demonstrated how the principles of cognitive science can guide software design to maximize the value of this software to decision makers. However, these principles and software can also be used to help people make better choices in another way. Quite simply, people can be trained to become more effective decision makers. Training may seem better suited for straightforward tasks rather than the complexities of decision making, but if it incorporates cognitive principles it can also be useful in the latter. This last point is important, as many companies have tried to train people to be better problem solvers and make more innovative choices but have not been satisfied with the results. That’s because the training has attempted to teach through instruction rather than action. As we’ve emphasized, people cannot be instructed to make effective decisions; they have to learn it themselves through doing rather than just reading or listening.



Chapter 7

148


Hi, In our last meeting with the CEO Dara Griffith, we discussed the strategic benefits the planned e-commerce initiative would bring to the organization. Following that meeting there was more discussion on the subject and the Moffett board has decided that our task force should carry out an in-depth analysis before an investment in e-commerce can be committed. The report on this analysis should propose specific e-commerce initiatives and the related benefits to Moffett Foods. So, here’s what we need you to do: Produce a report that justifies going ahead with an e-commerce initiative at Moffett Foods. (You may consider a null solution acceptable if it leads to the best outcome.) Provide answers to the following questions/statements as part of your analysis and recommendation: 1. Identify the inefficiencies in the existing distribution system and supply chain of Moffett Foods that the e-commerce initiative will address. 2. Design a solution to enable online purchasing of Moffett Foods products by retailers. What business benefits would your solution provide Moffett and its retailers? 3. Design a solution to enable online purchase of inputs by Moffett from various suppliers. Which specific inputs (for example, raw materials or packaging material) are suitable to be part of this system? What advantages would accrue to Moffett and to suppliers if they participate in this initiative?



From: Len Walsh Subject: E-commerce initiative benefits to Moffett

DECISION-MAKING TRAINING

149

●

●

●

●

●

●

●

Will the e-commerce activity generate only cost savings, or will it generate additional revenues? Will revenues come from enhanced market reach, from new market segments hitherto untapped, or from both? What are the cost implications of setting up this e-commerce initiative? Is it justified to make an investment in this initiative? Will it provide Moffett a competitive advantage? Will the advantage be short-term or long-term? What are the possible ways of creating long-term competitive advantages, if any? What will be the impact on the organization’s processes? Will they change drastically? If so, will a change-management effort be required? How technology-proficient are the suppliers and immediate customers (retailers) of Moffett? Will a change-management effort be required at suppliers’ and retailers’ ends to get them to participate in Moffett Foods’ e-commerce initiative? Will Moffett need to make an investment on behalf of players in the supply chain?

Identify and elaborate on the strategic, financial, technical, and implementation risks of the proposed e-commerce initiative.

Please use the attached template for preparing this report. Thanks and good luck! Len Walsh VP, E-commerce Initiatives



The following aspects need to be evaluated and elaborated upon in the solution:


It is possible to create training that revolves around learning by doing. “E-learning” and “e-training” are terms that provide a general category for what we’re referring to, but these words often conjure up software programs or online courses that are nothing more than digital lectures or manuals transferred to the computer screen. Here, however, e-learning involves cognitive-based software design. All the case-based reasoning principles we’ve discussed—failure as a catalyst for learning, the value of a diverse and relevant range of experiences can be incorporated into training software. This software probably won’t contain the training programs most organizations are used to. It relies on simulations, online teams, and mentoring rather than rote learning and rules. While it has some limitations that we discuss at the end of the chapter, cognitive-based software can provide everyone from line employees to senior managers with a broader range of cases upon which they can draw when facing both small and big decisions. Furthermore, it gives them a chance to make and learn from mistakes in simulated settings rather than on the job, avoiding the negative impact of real time errors. Let’s start out by describing what this cognitive-based software training looks like and the different ways organizations can use it.

Decisions Can Be Simulated The difference between traditional and cognitive training is the difference between telling employees how to make good decisions and letting them practice making them. That might be an oversimplification, but the point is that most training essentially tells trainees what and what not to do. We’re suggesting that organizations can use a combination of software, teams, and mentors to place their people into realistic decision-making simulations, allowing them to make mistakes, fail, and ultimately learn from these failures.



150

151

We’d like to share with you one such training scenario, designed to facilitate making a strategic decision. It begins with trainees receiving the following memo on their computers: As part of the software-run simulation, trainees work in online teams to arrive at an effective decision and have an assigned mentor to help them if they become stuck or have questions. As they prepare the report that will include their recommendations on how to proceed, trainees access online stories from experts related to the decision they face. They may find a story directly related to e-commerce from an e-commerce consultant. They may hear from Moffett’s former CEO talk about how he once tried to launch a similarly bold initiative and the problems he ran into because of corporate culture. And they may listen to an executive from a company in another industry relate a story that has nothing to do with e-commerce but provides cross-domain knowledge—this helps the trainee bring a fresh perspective to the issue because it involves a similar abstraction. The team holds meetings and takes preliminary actions online and the simulation responds to these actions. In other words, if they are considering launching a time-consuming and costly study before making a decision, they might hear from an expert who talks about the inherent problems with such a study. When they finally make their recommendation, the scenario continues, showing them the consequences of their actions. It is quite possible that these consequences are negative; that they’ve made errors in judgment and poor decisions. They may recommend that the investment in e-commerce isn’t worth it, and the simulation may have them called into their boss’ office when a competitor launches an e-commerce effort that increases their profits dramatically to receive a stern lecture about their failure. They may then be given another chance in a similar decision-making situation where they go through the same steps as before, and again they may fail and have to start over again. There are different ways to





navigate a simulation, and so they may go through the scenario more than once, encountering different people and consequences each time based on their decisions. Through repeated experiences in simulations, trainees have the opportunity to encounter expectation failure, learn from these failures, and practice new skills so that they can be successful in the future. While these simulations are not exactly the same as real experience, they come remarkably close. In the same way that a video game player often becomes so involved in the “reality” of the game that they lose the sense of artifice, so too do trainees feel like a simulation is the real thing. The team aspect of the simulation, the participation of mentors, the way the software “responds” to the choices they make, and the sharing of stories from well-known experts all contribute to the verisimilitude of these scenarios. Verisimilitude is a key concept when it comes to creating simulations. For people to gain valuable decision-making experiences through these training exercises, they must adhere to certain real-world principles. Let’s look at these principles and how to incorporate them into software design.

Five Keys to Effective Simulations E-learning technology has made it possible to create remarkably realistic simulations. Software can be programmed so that trainees must make a series of choices, and each one taking them down a different programmed path. Consequences of decisions both negative and positive play out in various ways, from being reprimanded by the boss to the company losing money to the team achieving its objective. These simulations provide trainees with the opportunity to solve problems as they would in their business lives. A menu on the computer screen offers them the option of consulting an expert, reading a report, or holding an



152

153

online meeting with other team members before taking action. In short, their experiences in the simulation mirror their experiences at work. Sophisticated systems also make it possible for trainees to navigate a scenario in different ways. One person may move through it slower than another. One person may prefer to ask an online coach a lot of questions, whereas another may just want to keep going on until he or she gets it right. Someone else may want to repeat the simulation once it’s completed and make different choices. Versatility is the premier attribute of well-designed simulations. The following sections discuss the four other key traits.

Expectation Failure Wee alluded to this trait earlier, but we want to emphasize that people will not learn how to make good decisions if the simulations aren’t clever about making them think a decision will lead to A and it turns out to be B. For example, a simulation on hiring asks trainees to make a choice among five candidates, they choose one who seems to have the best credentials by far, and he ends up being the worst choice possible for the job—the simulation reveals the new hire quits after less than a year on the job. Expectation failure of this sort is emotional and therefore memorable. Cognitively, the point of training is to index a case in a way that it’s easily retrievable when it’s needed in a real business situation.

Ambiguity Decision making isn’t about right and wrong. Training that attempts to convince people to follow decision-making rules won’t work. These rules may have some validity in some situations, but trainees often forget the rules under the stress of real working conditions. More importantly, a rule that works in one situation won’t work in another. Using the same merger or hiring or growth strategy every time is doomed to fail. On a smaller scale, managers should not respond the same way





every time a direct report asks for a raise or when mediating a conflict between two of their people. Remember that decision making is an unconscious activity, and we need to train people to have a sufficient diversity of relevant cases so they can learn to make good decisions in all types of situations. We depend on our unconscious to guide us toward the right decision in a given situation and that will only happen if we have the right type of experiences—simulated or real. For this reason, ambiguity should be a simulation ingredient. In a simulation for the Environmental Protection Agency, for instance, trainees have to deal with a caller who complains that the ground is polluted in his area. An expert pops up on the screen and suggests that if they don’t feel the call is serious or significant or they’re busy with other matters and should consider doing nothing about it. Another expert, however, advises that they should treat callers like friends and attempt to work with them. The program communicates there’s not always one right decision. It invites trainees to learn to use their judgment when making decisions, sorting through conflicting advice and relying on their instincts to make a choice that is far from obvious or easy. At times, simulations need to convey definitive “dos” and “don’ts,” and that’s fine. Corporate knowledge can help provide good guidelines for making decisions. In a simulation for a British water utility, one clear “don’t” was frightening customers about polluted drinking water. During the simulation, if a trainee scared a customer unnecessarily, an expert came on the screen and related a story about how a past customer terrified about polluted drinking water had raised a hue and cry about the situation that resulted in negative publicity for the utility.

Goal-based Scenarios People need to be motivated to participate in the training. If they are doing it just because they’re told they have to or with little enthusiasm, they will learn very little. Again, from the cognitive perspective, 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


154

155

meaningful goals prompt people to learn. Children want to learn how to ride bikes, and this goal motivates them to practice through a series of scraped knees until they master this skill. Simulations can be designed so that clear, meaningful goals exist. When the goals are vague (a training program on general leadership skills) or when they’re tangential (a simulation designed to familiarize employees with corporate policies), they don’t activate the learning impulse. If, on the other hand, the simulation promises to provide knowledge that will help people do their jobs faster and more effectively or increases the odds of promotion or favorable performance reviews, they’ll be much more invested in learning.

Fun Training shouldn’t be boring. People need to be mentally and emotionally engaged if they are to maximize learning, and simulations are not automatically engaging (though they are inherently more engaging than training that involves lectures on the computer screen). Certainly the previous point about goal-based scenarios is essential here, in that if people are motivated to learn, they’re unlikely to be bored. More than that, though, designers should incorporate an element of fun in their software. This means injecting humor, drama, challenge, and competition into the simulations. It isn’t difficult to do, but many training professionals still labor under the idea that learning should not be fun. They have been brainwashed by an educational system that goes out of its way to limit rather than encourage fun in subject-based teaching. However, cognitive science has found that people learn more effectively when they’re having fun doing something.

How to Focus Training on Key Decisions To design effective decision-making training software, organizations need to adopt a new perspective. As we just noted, turning simulations 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway




and other online training into school classrooms is a reflexive response. Using state-of-the-art equipment and software with bells and whistles is no substitute for cognitively consistent software design. Lecturing trainees and asking them to memorize material and take quizzes to demonstrate their understanding of the material will not help them make challenging choices. Consider this example from Roger about the time his organization was contacted to create “new hire” training software to help neophyte employees get up to speed faster and make better choices in their jobs. I met with a group of people from a large European organization that wanted to develop e-learning for its new employees, including a top HR person who specialized in developing company initiates. I noted that the two initial steps in building any training program was having an expert tell stories and understanding what needed to be taught. They didn’t get it initially. After much uncertainty about what stories might be significant and what was critical to teach, the expert pointed out that there was an employee manual containing all the information someone new to the company should know. I pointed out that knowing information wasn’t the point; that what these employees quickly forget. Nonetheless, when I pressed the group for good stories and insight about what practical skills might be relevant, they kept reciting passages from the new employee manual. Finally, I asked, “What is the biggest mistake that new hires make when they are first on the job?” The expert’s face lit up. He began to tell a story about some complex software that kept breaking. New hires, uncertain about how it worked, wound up frequently providing customers with erroneous advice about how to deal with this problem; they also failed to connect customers with the company’s tech people who could offer advice on fixes. I realized that “new hire” was a misnomer for the E-learning training they sought. This is not an uncommon issue, in that companies



156

157

slap general labels on training protocols and often fail to address the specific decisions that their people are struggling with. The new hire label connoted everything from education about the company culture and policies to summaries of benefits. In reality, what they wanted to train new employees in was handling the most common and significant customer service decisions they would face: making good recommendations when frustrated customers called about the software was at the top of the list.

In Chapter 4, we recommended identifying the pain points when designing performance supports software. This is essentially the same recommendation. Training should hone in on pain points—the decisions that employees find most vexing and that have the most impact on a given unit within the company. To focus the training software on the right decisions, ask the following questions: 1. What decisions are employees having trouble with? 2. Can you tell me a story of when an employee made a poor decision and it caused a big problem for the company? 3. Under what circumstances do employees make the wrong decisions even though they’ve been told what to do in these situations? 4. What types of decisions are causing the company significant problems (other than the one previously mentioned)? 5. What are the key things employees need to know how to do to make good decisions? Too often, training focuses on what people do well and tries to communicate what will make an individual successful based on best practices. As you probably noticed, most of these questions revolve around





mistakes made. Mistakes, failures, problems, and other negative events provide great opportunities for employees to learn how to make good choices. Every mistake carries an emotional, memorable lesson, while every success is far less emotional or memorable. That’s why expectation failure is an essential component of simulations. For this reason, simulating expectation failure is a key component of simulations. Cognitively speaking, expectation failure is indexed well by our unconscious minds and retrieved readily when we’re in similar decision-making situations.

Overcoming the Roadblocks to Good Training Software Training employees to make better decisions through e-learning is not always a smooth process. Even if an organization embarks on this training with a significant amount of enthusiasm and resources, they may find themselves facing a variety of questions and obstacles as they develop the software. To help organizations deal with these issues, the following roadblocks should be addressed. ●

No way to design training courses on specific decision-making areas.

This is only a roadblock if trainers are trying to teach a particular decision-making skill. In other words, it’s tough to design a lesson plan around how to make better budgeting decisions or how to make more effective customer service decisions. It’s also a fruitless exercise, in that professional trainers, like teachers, place too much emphasis on what they have to say versus what trainees/students can learn on their own. If software places trainees in situations where they have to make certain decisions—where they have actually decide something rather



158

159

than study it—they’ll acquire the requisite case-base to help them in the future. If the E-learning incorporates the traits we’ve discussed— versatility, goal-orientation, expectation failure, ambiguity, and fun— they won’t require instruction. What professional trainers should focus on is making sure the software they create facilitates the following actions: ●

●

●

●

Practice. The more times an employee grapples with a decision, the better he’ll be at handling in his real business life. The software should find ways to help him practice, whether that means repeating the same simulated decision-making scenario or doing other ones. Practice results in expectation failure that not only helps people index the experience but tries to make a better decision the next time. Feedback. Whether from a mentor or coach or from an online source, feedback is crucial for a training protocol. When people practice and fail, they’re motivated to learn; their ears and minds are wide open. That’s when a credible decision-making expert should be available to answer people’s questions about what they did wrong and how they might do it better. These are teachable moments, so trainers should build immediate feedback into their designs. Reflection. For this decision-making training to work, it has to encourage people to think about the feedback rather than just react to it. A mentor can tell trainees, “Don’t do anything based on what I’ve just told you for at least a day. Spend time thinking about what happened and the feedback you’ve received. Then make a decision.” Reflection is good for the mind as well as the soul. It helps people integrate a recent experience into their brains so that the unconscious will recall it when it’s needed. Not enough time. Some organizational executives might argue that it’s a lot faster to compress everything people need to know





for a particular decision into a lecture or a list of bullet points than it is to create a simulation around it. They will suggest that by creating an online course they can teach people how to make a decision in an hour rather than have them spend ten hours working through a simulation. The problem is that if people don’t retain what a course teaches them—and they won’t—then the course is worthless. Courses provide false reassurance to organizations, convincing them that they are providing decision makers with the knowledge they need to act accordingly in a given situation. What they don’t realize is that telling someone what to do doesn’t mean that they’ll do it, or that they’ll have the experiential base to adapt their decision when a situation changes (as business situations invariably do). In an era where every organization is trying to do more with less people, time is a precious commodity. But if companies take a longterm view, they’ll realize that training people to make effectively decisions has a huge payback—they will waste a lot less time not having to undo the damage caused by bad choices. ●

No experts available. A common complaint about this type of training software is that the company doesn’t have a particular expert in a particular decision-making area to provide stories and advice—either the expert is busy with other things or doesn’t exist within the organization.

The solution is to capitalize on the experts used in performance support software. Assuming organizations follow our earlier recommendations about taping expert stories for on-the-job decision-making advice, they should have a ready supply of experts to draw from. In fact, every organization should make it their business to place as many expert stories on file as possible. Such an archive will have great value for years to come. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


160

161

Many of the experts will not be available in the near future; they’ll retire, join a competitor, or be unable or unwilling to tell their stories for other reasons. As important as these experts are to support on-the-job decision making, they are just as important in training exercises. Experts impress trainees; they will listen to their stories with much greater involvement than if an HR person was recounting the same experiences. ●

No way to include learning objectives. This is another holdover from the academic arena. It allows course designers to set a series of “learnings” around which they can create courses that communicate them. However, these objectives taint the process in two ways. First, they result in an overly-long list of objectives; everyone is constantly adding to it to make sure this or that bit of knowledge isn’t ignored. As a result, no training process could ever impart everything that’s been included. Second, many of the objectives are too vague or conceptual. “Be more innovative” or “be able to think globally” are two typical examples, and what they end up creating are courses that list ideas about how to be more “innovative” or “global.”

We realize that professional trainers need objectives to measure the work done, if this is the case, set a very limited number of performance objectives or things that the training will help people do. Instead of being more “innovative,” the goal would be to “create at least five unorthodox or provocative new product ideas annually.” Better yet, link the performance objective to the decision-making process: “Become skilled at finding orthodox new product solutions when old products have run their course.”

Limitations and Applications Training isn’t a panacea, and we’re not suggesting that even the best designed e-learning is a substitute for performance support software. 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway




Many of the decisions managers make during the course of a day involve complex, situation-specific issues. In other words, training can’t prepare a corporate executive for the media frenzy after a product tampering incident or choosing between selling the company or downsizing it to a shadow of its former self. And it can’t prepare an executive for how to respond strategically when a third world competitor blindsides everyone by introducing a new product that revolutionizes the industry. This is when performance support software is essential, providing not only expert guidance but timely information and online conversation facilitation. All this helps decision makers deal with a developing situation, one that training may not have anticipated. Training is limited by this factor, as well as that its inherent lack of timeliness. An individual may receive training in 2009 that neglects key decision-making issues that develop in 2010. In addition, simulations are still simulations, and the artificial experience of being chewed out by a boss over a mistake doesn’t carry the same weight as in real life—the emotional impact is greater in an actual business situation, since actual embarrassment, shame, and anger are more intense and thus more memorable. On the other hand, training of the type we have discussed can prepare people well for anticipated decision-making situations. Organizations know that their salespeople will face common choices such as when to keep pursuing a lead and when to move on to a more viable prospect. They know that their HR people will face a common set of choices such as to how to handle a valuable veteran employee who has been accused by a direct report of discrimination. Training using the simulations and other tools we’ve discussed can ensure that these decision makers won’t be making their first choice in a given area without any previous cases to rely on. The last thing any organization wants is virgin decision makers—people who are



162

163

responsible for important business choices without any relevant experience. Nine times out of ten, these people will make the wrong decision. It is better for them (and the company) to get these mistakes out of the way during the training process. Perhaps the most significant benefit of cognitive-based training, though, is that it can help employees change certain perceptions or habits. While training can’t change personalities or values—it’s not going to make a shy person extroverted or an inherently conservative individual a risk-taker—it can help employees make small but significant adjustments in the behavior that impacts their decisions. Moose, for instance, is a shipping company engineering superintendent who is extremely knowledgeable about his field and generally makes sound technical decisions. Yet despite his superiors’ requests and admonitions, Moose makes poor choices when it comes to relationships with people. Because Moose, as his nickname suggests, is a big man with poor social skills, his interactions with those who don’t know him and work with him closely tend to be awkward at best. At worst, his manners harm relationships important to his shipping company. In one instance, a marine surveyor did this shipping superintendent and the company a favor by providing them with a certificate that would allow the shop to pass an inspection and delay minor repairs until the ship docked at a more convenient facility. In return, Moose invited the surveyor for dinner aboard the vessel. At dinner, however, he was unintentionally rude and intimidating, and the surveyor left upset at Moose’s behavior. Maintaining a good relationship with this surveyor would benefit the company in a number of ways, but Moose’s behavior made that possibility unlikely. Through relationship-building training that uses simulations and other software tools, Moose was put in situations similar to the one with this inspector and asked to make decisions that would impact the relationship. When he made poor decisions—demonstrating a lack of





tact or acting like a bully—the software brought a communications expert on the screen who related relationship-destroying stories that resonated with this shipping superintendent. Because part of the training involved an online team, Moose also received suggestions from team members who he knew and trusted about how he might act differently. Though Moose was resentful at first, his failure to complete the simulation successfully and the stories and comments he received made him think long and hard about his behavior. It took a few runs through the simulation until he learned what would build a relationship instead of hurt it, but he eventually got it. The training included the three key ingredients necessary for learning—practice/expectation failure, feedback, and reflection—and they taught Moose how to make some important changes in attitude when he was trying to build relationships. This individual was never going to become suave and diplomatic, but he was able to change enough to make smarter decisions about interacting with individuals outside the shipping company.



164

Implementation



Section III




The Human Factor: Achieving True Usability

Because of advances in cognitive and computer science, we are now able to make our software highly usable. Unfortunately, because of diminished expectations for our misguided notions about software, companies often fail to capitalize on its new capabilities. Therefore, the first step in creating highly usable software is to define what this “highly usable” actually means. Most computer users think about usability from a navigational standpoint—how easily they can move from screen icon to computer function. They want icons that are visually attractive and transparent in purpose. When they click on an icon, they want the desired application to open seamlessly. When they start working in an application, they want to be able to move from one task to the next quickly. In short, they want software that functions as efficiently as any tool, and that’s important. But this is level 1 usability. The level 2 variety is far more important, in that it’s about facilitating the process of making a good decision. When software is highly “usable,” it anticipates what the user needs to know when he needs to know it; it suggests who else would be helpful to communicate with in a given situation; it reminds



Chapter 8


him of relevant situations in the past. It is as if the software is the best coach/consultant money can buy; someone who knows the user’s company, industry, and the decision maker better than anyone else. This knowledge enables the software to make suggestions and provide information crucial for making a good decision. Thus, as the decision maker works at the computer, it feels as if the software is almost reading his mind—anticipating his needs, leading him to experts, stories, and helpful colleagues with great speed and accuracy. Usability is important at all organizational levels and for all types of decisions, but it’s especially critical for choices where there isn’t a lot of time or resources devoted to them. When a CEO is facing a major decision such as how to grow the organization, he has teams of experts analyzing his options and the time to gather the right people to help him choose one. Most organizational decision makers don’t have this time or luxury. They are more dependent than the CEO on their software to provide the resources they lack in a compressed time frame. If the software isn’t highly granular—if it doesn’t recognize everything from the common mistakes the company has formerly made about a decision to the other employees who should be contacted before taking action—then the system won’t be very usable. For too long, industry software has settled for level 1 usability. This software is perfectly adequate for routine tasks—accountants can do their basic work efficiently using QuickBooks or other software and salespeople can handle general customer issues using CRM systems. Designing software that helps organizations carry out essential but essentially unambiguous work is level 1 usability. The challenge is taking this usability to the level of decision making—especially complex, ambiguous, and innovative decision making. This means software that anticipates people’s needs and issues surrounding a decision and automatically provides this knowledge based on what they’re doing on the computer. Specifically, it allows users to



168

ACHIEVING TRUE USABILITY

169

Desktops: The Wrong Visual Metaphor Software employs the desktop metaphor to translate computer functions into layman’s terms. It’s reasoned that people understand the concept of indexing and storage, of alphabetizing files or putting them in chronological order, of using “trash cans” to dispose of old files. On the surface this makes sense, since most people have used desks and filing cabinets at some point in their professional lives. In truth, desktops are an artificial construct that have nothing to do with how the mind organizes and retrieves information. When we need to make an important decision, the folder with the right information doesn’t automatically highlight itself and direct us to the crucial paragraph in the right file. Instead, we stare at a series of folders on our screen and try to figure out which one might have relevant information. Or we ask a search engine to use a key word to find the knowledge we need but instead receive a great deal of knowledge we don’t require. Consider Microsoft Word, the dominant word processing software. Microsoft used their marketing muscle to make this program a huge success, following their tried-and-true formula of acquiring a company with promising software and then branding it as their own. Because their strategy is generally to sell the most products to as many people as possible, they favor generic software that lacks any tools specific to business functions or industries. For this reason, Word is the antithesis of the type of software we are advocating. It is usable in the level 1 case rather than the level 2 sense. It has a spellchecking feature, but it is



direct their energy toward the problem at hand rather than the mechanics of using the computer to find what they need to know. How to design software with this capability becomes clearer when we understand what makes software “unusable.”


unable to adapt this feature to the spelling requirements of a particular industry or the idiosyncrasies of a particular user. Perhaps more to the point, it doesn’t help writers with the decisions that are often part of the writing process. Let’s say one business executive is using Word to draft a business proposal to his company’s leaders, recommending the outsourcing of a function. The writer is struggling with the wording of the proposal—he wants to create a convincing argument in print without coming off as unrealistic in his expectations or too conservative in his projection. A good word processing program would know this user’s writing history; it would recognize that he tends to write in a grandiose style that doesn’t work well in proposals and would suggest some alternative writing samples to help him modify his style. It could provide him with some successful proposals from the company’s corporate history. It might also propose he talk to another executive in the company skilled and experienced in writing this kind of proposal. This would be highly usable word processor. However, Microsoft wants software that makes economic rather than cognitive sense. So do other major software producers, and it’s difficult to blame them for wanting to make money. But organizations should recognize that while generic software may be fine for some simple applications or decisions, it’s not suitable for anything beyond the basics. People forget that computers were originally designed as numbers crunchers and the software that has followed reflects these origins. Consequently, software is generally very good when it comes to providing statistics of various types; systems can compare and contrast various numerical reports with ease. Similarly, software is good for simple clerical tasks; this too was part of software’s history and it became efficient at helping users create reports, do spreadsheets, and so on. But when businesspeople try and use their computers to help them with significant decisions they become frustrated. Here are some



170


171

●

●

●

Can’t find what they need to know. Does anyone know what happened when the merger fell through in 2006? Do we have any understanding of the risks in doing business in Bulgaria? Is any other company in our industry currently implementing the type of promotion we’re also considering? These are relatively simple questions, but people in organizations often struggle to find the answers in their systems. Maybe they are able to find partial answers, such as—a memo about the failed 2006 merger that provides a frustratingly small amount of information. Wrong thing is retrieved. In many ways, finding the wrong information is even more aggravating than finding nothing at all. The most obvious examples involve the type of search we referred to earlier—the employee seeking information on Ford Motors receives documents related to President Ford. More insidious is wrong information that seems right at first glance. For instance, a company’s knowledge management system provides a manager with contact information for an expert in mergers and acquisitions who has worked with the company before, and this manager decides to go ahead with a merger based on this expert’s advice. However, this was the wrong expert to contact on this issue because his M&A experience was in a different area and he knew little about this company’s industry or history. Lack of contextual knowledge. This is when the knowledge gleaned from software is not situation-specific or individually tailored. The person sitting at the computer in her office receives a great deal of data and suggestions pertaining to the issue she’s facing, but all of this knowledge betrays a lack of insight into her role, the business’s goals, and the larger industry context. What is so frustrating is that people want knowledge suited to their situation



examples of these frustrations:

172


Other smaller frustrations exist, ranging from computer freezes to software that is difficult to operate. Slowness is also a problem, in that not only is time an issue with many business choices but we’re accustomed to fast response times from our personal computer use and from real world tasks like writing a post-it note. Ironically, slow response time may be due to software designers who equate usability with multiple features. Too often, they overload software with unnecessary options, providing people simply trying to write someone with hundreds of concurrent functions like synchronizing junk-mailboxes, detecting networks that users aren’t seeking and downloading updates. Organizations can design software that eliminates these minor annoyances as well as the major frustrations. Let’s examine how they can.

Five Design Requirements Designing usable software for decision makers isn’t rocket science; it’s brain science. The cognitive principles we’ve presented can guide designers so that they allow decision makers to use their software without thinking about it—to find the expertise and information they need without struggling to obtain it. Here is how to translate these principles into usable software. First, ensure that graphical user interfaces (the icons and labels on the screen) reflect the way the mind works in topographical memory. Until we can make software follow our every thought, we will need interfaces and the graphical one is fine for now. Using enterprise software should be an intuitive experience; people shouldn’t have to spend



but only receive information vaguely relevant to everyone in their position and specifically relevant to no one.

173

a lot of time figuring out how to find the functions that relate to what they are about to do or locating expert advice or relevant reports stored in a vast knowledge management system. Instead, screen icons and labels should follow a clear pattern that provides immediate understanding of what will be retrieved when they’re clicked. This will allow users to focus all their attention on the present decision rather than on being frustrated figuring out ambiguous or misleading icons. While this is the easiest obstacle to overcome in the quest to make software usable, many handheld devices and software user interfaces still befuddle employees. In the ideal cognitive-based system, the graphical user interface is a redundancy since the software knows what the decision maker is doing. Because the ideal may be further in the future for most companies, though, designing a cognitively-consistent graphical user interface should be the immediate goal. Second, use cognitive abstractions for enterprise activities. By this we mean the software has to break down each function into components that are valid (abstractions) regardless of what the function is. For example the functional navigation of approving a purchase order needs to be abstracted in the same way as the function of hiring an employee. At a much higher level there are even more abstractions. When a financial executive is wrestling with whether to slash the budget by 10 percent or downsize staff by 5 percent, the software should be designed in a way that it recognizes the common goal conflicts and known obstacles and provides this executive with experts, stories, information, and people connections around these issues. It’s the higher level abstractions such as short-term gain versus long-term pain that will provide this decision maker with the right type of knowledge at the right time. By indexing information at this higher cognitive level, the software can retrieve the knowledge the user requires to adjudicate this goal conflict and reach a good decision.





Third, create a “rich” design that keeps track of what users are doing through their work with the software. A great deal of enterprise software fails to emulate the richness of real world activities. Instead, it presents a complex but inadequate series of steps related to an object (i.e., the budget). This software doesn’t anticipate the thoughts concerns, requests and decisions of a user and how they fit into larger enterprise goals like budgeting. Without this activity-based cognitive design, the software is limited in what expectations it can manage from a decision maker. It won’t recall that this individual had a similar problem two years ago, tried x and it didn’t work. Therefore, it can’t remind him of this fact when he tries x again. Similarly, it can’t identify how his requests and actions seem to run counter to a larger group goal and point out this disconnect. A robust design, on the other hand, can provide users with an evolutionary rather than a static knowledge base and a user experience that matches the real world expectations of the emulated process. Fourth, translate an acute understanding of enterprise processes into the software design. This can be a challenge, in that most software engineers find it difficult to translate even simple requirements into software. Enormous complexity exists in making this translation, and so software engineers may find it daunting to design software around cognitive principles. When experts tell their stories, designers may not “get” how to translate them into relevant enterprise activities and then into software functionality; they may get lost trying to integrate these stories into the larger software design around common problems and opportunities. This is why mapping the enterprise processes and individual goals and roles are so important. This map provides software engineers with the right framework within which to work. It gives them a way of designing software so that people can navigate through a process decision in ways that make cognitive sense.



174

175

Fifth, design a system so that the computer processes information the way people do rather than how it’s processed by the functional design. Enterprise software will do all sorts of odd things when people use it to make decisions. Employees complain all the time about how their systems furnish them with the wrong information in response to a request or how it directs them to an unwanted site. More subtly, these systems may provide the surface requirements in response to key word entry or a functional choice, but they don’t have a deeper knowledge of the decision process to present users with a seamless and clear path to a decision—one that the user can follow without thinking about how to manipulate the software. This is why designers must incorporate cognitive processing into systems rather than relying on ways of processing information that has nothing to do with how people really think.

The Friend Paradigm Software usability is also related to how well a system knows its users. Beyond the recommendations just made we would encourage software designers to create systems that respond to users as a good friend would. Think about how well a close friend knows you and how this enables him or her to offer advice that is tailored to your personality. He knows when you’re making a mistake because of who you are (“you’re being too impulsive; don’t invest in penny stocks!”) or that it’s in your best interest to veer from your historical pattern (“try investing in some growth stocks rather than putting all your money in bonds and other conservative instruments”). Obviously, you friend needs to possess expertise in the topic on which he offers advice for his advice to be credible, but all things being equal, his knowledge of you makes his advice infinitely more valuable than that of an expert who knows nothing about you.





When a decision maker’s computer knows her in terms of her tasks, roles, goals, and plans, it can offer relevant information when she begins to solve a problem, capitalize on an opportunity, or make any other type of choice. It can “think” to itself: “Jenny is trying to figure out who to put on a new project team to upgrade customer services for high-end clients. In the past when she’s formed these teams, she’s often been dissatisfied with the results because she’s made the team too diverse and therefore too contentious. Plus, Jenny is likely to select the team without any input because the last time she asked for help with the selection process it created a lot of conflict among her people.” Knowing Jenny as well as it does, the software can recommend that she listen to the corporate guru on team selection tell a story about the biggest challenge he ever had when it came to picking a team. It might make Jenny aware that Tom in another group is also in the process of selecting a customer service team and that they should talk. And it might remind Jenny that this team is a high priority for the organization and that Jenny cannot take as long as she has in the past to assemble it. To create a truly user-friendly piece of software—one that knows a decision maker well—it should be aware of the following: ●

●

● ●

● ●

Short-term goals—what this person is trying to achieve in a given area. Long-term goals—what this person is trying to achieve in this area in the future. The existing and potential conflicts between these goals. Decisions (both successful and unsuccessful) that this person has made in the past in this area. The assignments being worked on now. Concerns about threats or obstacles to achieving goals.

This knowledge can be easily programmed into software and updated regularly. When this is done, the software ceases to be generic 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


176

177

and starts responding to an individual decision maker’s requirements and tendencies. As a result, decision makers have a partner of sorts who can coach them toward a good decision as if it had been working with them for many years and recognizes exactly what they know, don’t know, and need to know. Their software can engage them in a dialogue of sorts, much as a friend would. It can offer knowledge, and after the user has digested it he can respond with a question. Once more information is provided another question can be asked. This is the natural way people talk with knowledgeable friends and this is how they should communicate with their software.

The Right Stuff: Making Sure It’s There to Be Used If organizations don’t embed the right experts, stories, and other content into the system, then even the best design won’t be very usable. People may not say these systems lack usability, but their behavior will demonstrate that this is a problem. In other words, when they’re facing a tough decision, they won’t use their computers—or won’t use them to the extent that they should. They don’t trust the software to provide them with that key story or that fresh perspective because the software hasn’t been particularly useful when they called on it for help with decisions in the past. What they need from the system just doesn’t seem to be there. To make sure the right stuff is embedded in software and available for use, organizations should do the following: ●

Find and tape all the right experts.

When it comes to usability, overlooking key experts is a cardinal sin. When people turn on their computers and are working on a problem 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway




involving marketing, they want to hear from the acknowledged experts within the company or industry. If no expert is available through the software or it’s clearly a second-rate “expert” who lacks credibility or even worse, the right knowledge, users will be frustrated. We should explain why we’re emphasizing experts and their stories over documents, versions of documents, line item data, serial numbers, or any of the millions of examples of data we find in enterprise systems. While the right documents and the right data are essential for making low-level, transaction-type decisions (i.e., whether or not to include a line about diversity in the company’s employee manual), expert advice is essential for higher-level decision making. Most enterprise software currently in use focuses on transactions and ignores the experts. Other factors make it easy to overlook experts and fail to tape their stories. Organizations rationalize that if an expert is an employee, he’ll always be available in real time to help others with their decisions. In fact, most experts in big companies have neither the time nor the inclination to help everyone who needs assistance. Employees in other divisions or locations might not even know who the experts are. Even more frequently, organizations don’t do a good job of including all their experts on software. They don’t spend much time or energy identifying experts and making sure they are part of the software project. They overlook an expert in just-in-time delivery systems. They don’t want to enlist an outside expert for fear he’ll charge a large fee for his participation. They identify the wrong expert, assuming that someone qualifies as an expert because he’s the head of his function when in reality, someone two levels down is the one with the savvy about how things work. ●

Make sure the expert stories are usable.

One of the biggest mistakes here is allowing experts to go on too long. The medium demands brevity, as do most people without the time or



178

179

patience to stare at a talking head for more than thirty minutes when they’re under pressure to make a decision. Two minutes should be the maximum time allowed for an expert to tell a story that’s accessible via software. If they can’t condense their stories, then designers need to edit the length. Short, focused stories are also easier to index properly, making them more accessible to users. When stories meander, they often are difficult index abstractly—they may touch on two, three, or more decisionmaking topics. As a result, they may be retrieved incorrectly and stymie a decision maker who finds much of the story irrelevant to his purposes. ●

Anticipate and include the knowledge that is particularly relevant to decisions.

Software engineers and their teams must ask the questions and find the answers that are often ignored by most software. What software usually includes is basic information about various processes, products, services, and the like. It’s difficult to imagine software that fails to include a document with last year’s budget for financial managers, for instance. What’s often missing, though, is the knowledge that lurks around the edges of a decision-making subject and that’s often crucial for making the right decision. The questions that have to be asked relate to very industry-specific or company specific issues. For instance, —Who are the true innovators in our industry and what are examples of their recent innovations? —What current regulations hamstring organizations in our field? —What legislation is pending that could have a major impact on how our company does business? When answers to these questions pop up as decision makers are struggling with a choice, users recognize that the system is aware of all




180


the current events involved in their decision and see the value of this software. Recognize that less is more.

Knowledge management systems tend to stuff computers full of documents with very weak relevance criteria. From a usability standpoint, this is a huge problem. Reading a document to find out what it really tells you impedes productivity. For example, most companies will have past contracts for the purchase of assets they own. Reading the contract does not tell decision makers about lessons learned. They can spend hours plowing through online documents without learning what mistakes were made with purchased assets or what strategies were successful. It’s very difficult for the user to find what he needs with thousands or even millions of options and no way to locate the essence of given experience. Contrast this with a few stories from seasoned experts in asset acquisition involving similar situations. When a decision maker conducts a search of an enterprise system, he will find what he needs faster if the search is limited to a relatively narrow field of expert stories rather than every document or spreadsheet that has ever been processed in the enterprise. Nothing makes people hate their office computers more than struggling to find a nugget of knowledge in a vast, undifferentiated information landscape.

Shipping Lessons: Using Software with I-Phone Ease Perhaps more than any other industry, shipping firms have learned how important it is to have software that operates intuitively. In the shipping business, there’s a lot riding on decisions. A bad decision on ignoring a safety issue can result in the loss of a ship. A good decision about how to get around rough weather can result in timely delivery and solidify a



●

181

relationship with a major customer. Just as importantly, decisions in shipping often need to be made with maximum speed and coordination. Costly mistakes aboard ships aren’t unusual and usable systems can provide the critical coordination and knowledge transfer to avoid these events. Captains, chief engineers, and superintendent engineers, especially, must possess software that provides an effortless interaction with both the internal world of key ship personnel as well as the external world. At least some of these decisions demand extraordinary focus, and so they need to interact unconsciously with the software; they cannot afford to spend time concentrating on how to make the software work, since that will detract from where their focus should be. These captains, chief engineers, and superintendent engineers need to use their software like a driver on a busy street uses his iPhone to find a particular destination. It has to be a simple and intuitive process, allowing him to concentrate on navigating the streets while navigating screen icons. All this is a good indication for why the shipping industry committed to software usability prior to many other industries. It’s also why companies in the industry have learned valuable usability lessons that we’d like to share with you. Specifically, we’re going to tell you what the lesson is, how it applies to the shipping business, and how it translates into other business decision-making arenas: Lesson 1: Respond to a user’s role within the larger process. If a superintendent engineer walked up to a fleet manager and began discussing a technical defect in a malfunctioning hydrocarbon alarm, the engineer would expect the manager to respond with knowledge of the engineer’s role in the repair process, experience in working with these types of alarms, and so on. If the fleet manager began speaking to the engineer as if he had no idea of who he was or what he did in the company, it would create serious communication problems. Similarly,





the software must tailor its interaction with the ship engineer around his role in a particular process. In this way, the system doesn’t waste time asking irrelevant questions or providing tangential data. The software sees the big picture and the user’s role in it. That recognition makes it far easier to provide the knowledge he needs, reducing glitches in system functioning to a minimum. This lack of role recognition makes most enterprise software difficult to use. In large companies especially, software treats everyone as if they have the same role, which is absurd. Within processes like marketing and manufacturing, for instance, individuals have distinctly different roles, even though they may all be involved in contributing to the same decision. In the marketing process, the corporate communications director needs input about the potential consequences of a decision about the company’s image; the ad manager needs information on advertising concepts that will maximize the positive impact of that decision. To give each of them the same broad base of knowledge will not only overwhelm them with information but also discourage them from using any of it—there’s just too much to sift through. Lesson 2: Put the discussion in context. When bad weather is rushing toward a ship or pirates are in the area or an employee’s behavior is putting the crew in jeopardy, the captain or ship officer doesn’t want the software to present him with an object. He doesn’t want the focus to be on some generic emergency procedures program or one that offers forms that must be filled out before a crew member can be terminated at sea. As we’ve discussed, software places the emphasis on generic objects rather than on individual situations. For decision makers on ships, context is everything, and if the software recognizes it and provides assistance based on it, it can be used much more effectively. This is as opposed to software that asks you what feels like an endless series of questions before even beginning to provide 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway


182

183

decision-making assistance. Common contexts can be anticipated and programmed into the software, and a few key strokes will alert the software on the type of context the captain is dealing with. What irritates many business users is when they try to access software for help and receive a series of questions instead. It is akin to facing a medical emergency, calling the doctor’s office and having an automated system ask one question after the next—most of which are irrelevant to the emergency—that makes people hang up in frustration and call someone else. While it’s easier to program software to anticipate situations in highly structured processes such as those on ships, it still can be done for the majority of businesses. Companies generally know the five or ten most common decisions facing their manufacturing people; they can predict the majority of important choices their operations people must make. Lesson 3: Link-related processes. Decision making isn’t always a linear exercise. To arrive at a good decision, people may need to veer away from their immediate assumptions and explore outside their original focus. For instance, we may discover that the initial malfunctioning hydrocarbon alarm was not about a defect as much as an environmental issue—it needs to be replaced in order to meet emission standards. An emission and defect discussion involve the same object and two related processes, but most software doesn’t link these together. Instead, it forces the decision maker to go back to square one—using a different software program or returning to the beginning of the original program and entering data all over again. This wastes time and is highly inefficient. Cognitive software should recognize that a switch in focus has been made and segue the online discussion to the second related process without any need to return to square one. Businesses have a series of increasingly numerous interrelated processes. Competition and other factors have turned what was once a 10.1057/9780230110397 - The Future of Decision Making, Roger C. Schank, Dimitris Lyras and Elliot Soloway




clean, overarching process into many highly specialized ones. The sales process, for instance, has sub-processes that include conventional client relationship management, lead follow up, and client request qualification, as well as complex management of internal customer politics, analysis of client corporate cultural traits, and how this fits with a vendor’s products. Linking these processes in a software system allows decision makers to shift their inquiries and conversations from an initial process to a more relevant second or third. Lesson 4: Shift from one topic to the next. This one is simple. Software must have the capability of moving not just from one process to the next, but from one topic to the next. In volatile environments, the issue may no longer be about repairing a defective piece of equipment but about the environmental implications or the financial consequences. In shipping, when these shifts take place, the software can move people seamlessly to a fresh knowledge base—from stories about replacing defective parts to ones about meeting new emission control standards. While shipping has always had a certain amount of volatility because of the nature of the industry (international trade, changing weather, new regulations, etc.), many companies operate in similar fast-changing environments. A closed-door discussion with a governmental agency about possible safety violations can turn into a public relations crisis overnight. To help make the right decisions quickly, software has to be capable of taking people through these shifts as they occur. Lesson 5: Reflect the way an organization does business. Let’s assume that the superintendent engineer wants to replace the malfunctioning hydrocarbon alarm with a new instrument but has to



184

185

decide between two very different suppliers. He sits down with his purchasing manager to talk over the decision, when out of the blue the manager asks him for authorization to spend $10,000 to buy the new instrument from Supplier A. Understandably, the superintendent engineer is irritated by this request because it is out of sequence. The correct sequence is to discuss the two suppliers, obtain additional information about each, perhaps bring other people into the discussion and then choose which instrument to order. Unfortunately, generic software often conducts business in the way it wants rather than in a way that reflects how things are done in the organization. Here, usability has to do with the software reflecting the typical steps in decision-making process. When software leads people through the logical steps necessary to arrive at a good decision, it feels right. When software skips steps or doesn’t follow them in the proper order, people either ignore it or, if they’re not careful, end up making the wrong decision based on the software’s poor logic. Some business managers feel like a slave to their system, assuming that “the software knows best.” They move toward a decision the way their computers instruct, assuming that a great deal of thought has gone into the software design and that they have no right to question the direction the machines are leading them. Even though the software feels wrong, they go along with it, much to their company’s eventual regret. Lesson 6: Stick to the main topic. Think about what would happen if the superintendent engineer went into his purchasing manager’s office to discuss the two suppliers and the purchasing manager asked: —Would you like me to provide you with ten additional suppliers to choose from?





—Would you prefer only low-cost suppliers be on the list? — Can you provide me with a list of suppliers you’ve used in the past five years with which you’ve had good experiences? — Can you identify three traits that make a supplier superior in your mind? These questions may sound ridiculous, but they’re exactly the type of irrelevant and secondary questions that generic software asks. They reflect its cluelessness about a user, going all over the map with inquiries or requests for additional information. This superintendent engineer knows exactly what he wants to talk to the purchasing manager about to reach a decision, and he is fully aware when the process of arriving at that decision becomes unnecessarily slow or circuitous. Most business decision makers don’t want to get bogged down in details or overwhelmed by secondary issues. They are under pressure to make a choice, and they relish software that keeps their decisionmaking process at four steps rather than turning it into ten.

Use It or Lose It Organizations can create software for decision makers that incorporate many of the cognitive principles we’ve discussed, but if they fail to translate these into level 2 usability, then employees will only be able to do simple things efficiently and not challenging things effectively. Even if software designers include some of the ideas discussed here— great expert stories, addressing decision-making pain points through those stories—they will still be at level 1 if the software doesn’t respond intelligently to what people are doing on their computers. The challenge is to design software for this higher, decision-making purpose, and when it is done correctly, people will not just use it routinely but enthusiastically.



186

187

This is because computer users sense when software feels right. Something inside of them says that the software is asking them questions, reminding them of stories or providing other knowledge that is exactly what is required. At the same time, they also sense when the software seems awkward and uncomfortable. Again, this discomfort isn’t just about confusing icons or slow software; it is a more general sense that something is off or a belief that the software is only useful for mundane tasks. Most people probably can’t articulate what is wrong, but they don’t feel good about relying on this software to help them with their business choices. In many organizations, managers don’t realize that their people fail to capitalize on their expensive software for more than simple jobs; they don’t realize that people aren’t using the software for assignments that demand higher-level reasoning. When employees can’t articulate what’s wrong with it, they are unlikely to tell their boss that they don’t want to use it. Instead, they will use it for basic functions, but they will do end runs around the software in order to make their decisions. Usability has always been talked about in corporate circles in terms of ergonomics, so it has seemed to be a relatively minor issue. From our perspective, however, it is a major issue that has to do with what goes on in people’s heads when they’re working at their computers. True usability means nothing is going on, at least in terms of thoughts about the software itself. The more intuitive the process is, the more usable the software.







Obstacles and Opportunities: How Organizations Can put Cognitive Systems into Practice

The good news is that organizations are showing much greater interest in improving their decision-making methods than in the past. The bad news is that in doing so, they’re often taking the easy, wrong approach. As for the good news, we’re seeing raised corporate awareness of decision-making issues. This is due in part to improved information technology and all the attention surrounding it; organizations are aware of the buzz around Business Intelligence and want a way for their sophisticated computer systems to use that knowledge to make better choices. It is also due to the growing recognition that proprietary intelligence is becoming a thing of the past and that competitive edge is conferred by what you do with that intelligence (i.e., using it to make more effective decisions). In fact, it’s fair to state that this growing interest in decision making is becoming a business trend, and like all trends, it spawns showy approaches. Neuroscientists have weighed in with decision-making ideas for business. Mathematicians have furnished numerical-based



Chapter 9


models that have been adopted by some companies. Terms have been coined to describe a wide variety of decision-making theories and methods, from the well-known Balanced Scorecard approach to the lesser-known Swiss cheese risk diagram. In a bit, we’re going to contrast these approaches with the cognitive one we favor to help organizations avoid falling for methodologies that are more style than substance. We’re also going to focus on the opportunities for organizations that adopt a cognitive methodology and compatible software. As we’ll see, decision makers today are overwhelmed with information, and the fast rate of change makes much of it obsolete seemingly overnight. Companies are growing bigger (through organic growth or acquisition), making it harder than ever to connect people within companies so that decision makers are communicating with experts in other fields, divisions, and offices. Opportunities exist to bring these people together in highly effective decision-making networks, filtering and focusing knowledge so that it flows in the right form to a decision maker exactly when he needs it. Of course, when opportunities exist, so do obstacles, and we’ll examine what stands in the way of companies committed to taking a cognitive approach to decision making. Let’s begin by looking at one obstacle that often masquerades as an opportunity: the proliferation and popularity of decision-making methods.

Yellow Flags for the Red Flags In an article titled, “Why Good Leaders Make Bad Decisions” (Harvard Business Review, February, 2009), authors Andrew Campbell, Jo Whitehead, and Sydney Finkelstein use neuroscience to explain what distorts people’s judgment when faced with choices and how to avoid



190

191

these distortions. They present a number of valid points about decision making being an unconscious activity and how past experiences impact present choices, but they go off track when they get begin discussing “red flags”—the biases that negatively impact decision-making objectivity. They talk about how certain memories have “emotional tags” that distort the meaning of the experience and prejudice the decision maker. The authors tell the story of General Matthew Broderick, the chief of the Homeland Security Operation Center at the time of Hurricane Katrina. Broderick was supposed to tell President Bush if the water breached the levees; he decided to tell President Bush they had not been breached. The authors argue that General Broderick made this bad decision because earlier experiences in Vietnam had taught him that early reports of disasters were not always to be believed. The article suggests neurological research indicates people become “slow and incompetent decision makers” because of emotional tagging. The authors seem to conclude that emotion should be guarded against in the decision-making process. But emotion can serve decision makers well. Fear of a strong, upstart competitor can cause a leader to take fast and decisive defensive action to maintain market share. Anger at a customer’s repeated criticisms of the company’s cautiousness can motivate an employee to make more aggressive decisions to meet the customer’s ambitious goals. Perhaps more importantly, emotional experiences are ones that the unconscious recalls—these emotional memories are neatly indexed and easily retrievable, providing the unconscious with guidance for choices. Perhaps the most important lesson to take away from this article is that the authors fail to acknowledge the real reason people like General Broderick make bad decisions. It’s not the emotional component of the decision that’s the problem, but the lack of diverse and relevant experiences. We theorize that had he experienced failures based on an unwillingness to communicate catastrophic early reports to bosses—even if



OBSTACLES AND OPPORTUNITIES


they were smaller failures in less publicly visible situations—he might have made a different decision. It is the breadth of relevant experiences that is important for decision makers. And if General Broderick had access to the type of cognitive-designed software we’ve been discussing, it would have offered him a story from a crisis management expert that demonstrated the peril of responding tardily to early, negative reports. Our larger point is that organizations need to be careful about accepting everything they hear and read about decision making, even if the source seems reliable (i.e., The Harvard Business Review). Clearly, organizations are becoming more reliant on software to capture and access information for decisions. According to a Gartner Group 2009 publication: ●

●

By 2010, 20 percent of organizations will have an industry-specific analytic application delivered via software as a service as a standard component of their business intelligence portfolio. By 2009 collaborative decision making will emerge as a new product category that combines social software with business intelligence platform capabilities.

These are just two of many indicators that organizations are eager to embrace a new type of software to help them make more effective choices. But this environment has created a paradoxical reaction among organizations: They’re gravitating toward decision-making models that are both overly simplistic and overly complex. Volatile, ambiguous environments make people long for easy answers. They are drawn to models that seem to explain everything and can be implemented without much fuss. The book Smart Choices: A Practical Guide to Making Better Decisions by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, proposes assigning numerical values to the factors involved in a decision. For instance, before buying



192

193

a house, neighborhood schools may be one factor and receive an “8” because they have excellent reputations. Another factor may be proximity to highways and other forms of transportation; it receives a “4” because major roads are difficult to access and there’s no train station in town. By adding up these values and dividing by the number of factors, we can determine the relative value of moving into a specific house and thus make a decision based on this value. Unfortunately, these values are highly subjective—after all, some people might like the fact that there are no major highways nearby. Values also can’t possibly anticipate all factors—a neighbor with a large noisy dog, a plunge in real estate values the year after moving in because of flooding problems, and so on. No doubt, this approach may help some to arrive at simple decisions where all the factors are known and there’s little subjectivity. But this is the type most business managers face. Here is a story from Roger that documents why people are attracted to the easy solution: When I was doing work in Linguistics years ago, I made the radical suggestion that perhaps our efforts should focus more on meaning than syntax; that understanding meaning was a more important issue. I was attacked for this suggestion, in large part because understanding meaning is far more complicated and elusive than understanding syntax. Similarly, when I was working in the psychology department of a university, I proposed that we should focus our research on how memory works. Again, no one wanted anything to do with that idea; as one professor told me, “You can’t do controlled experiments on that subject.” In Artificial Intelligence, most of the work in the field involves statistical methods, with the premise that intelligence is based on the statistical processes of the mind. Researchers like statistic methods, since it allows them to quantify their efforts. Of course, it has nothing to do with how the mind really works.





At the same time, many of these simple solutions to decision making involve highly complex mathematical models. For instance, economic decision making sometimes relies on “utility theory,” a mathematical model that posits trading X for Y in order to get Z. The complexity of math reassures people; it provides an aura of scientific validity. In unpredictable times, sophisticated math formulas appeal to decision makers who feel that their choices are just stabs in the dark without them. Cognitive-based decision making is neither simple nor complicated. This book has demonstrated that there are no complex formulas to master and there are no easy ways to make such decision making work. But it is an approach whose time has come because cognitive science has revealed how we make choices and software technology has developed to the point where it can put cognitive science into practice. As we’ll discover, many opportunities exist to put cognitive science to work for organizations, but these can’t be seized until certain obstacles are overcome. Let’s look at five obstacles and how to overcome them.

Overcoming Barriers to Implementation When we talk to organizations about cognitive science and software, they naturally become excited about the possibilities this holds for their business decision making. But they also raise questions and concerns. Certain issues recur in our conversations and we’ve boiled them down to five obstacles—the barriers preventing organizations from making the leap to cognitive-based systems. But these hurdles are less substantive than they appear and we believe that most companies can clear them with ease. Obstacle 1: Our company has too many problems with too many different types of decisions to make this approach feasible.



194

195

In other words, companies don’t know where to start. They see poor decisions being made in finance, marketing, manufacturing, and in every function; they see them being made by both entry-level employees and senior executives; they see them being made because of carelessness and fear of risk. It seems overwhelming to do all the requisite activity mapping, expert identification, and story selection for the software design. But organizations can and should start small when it comes to implementing a new decision-making process. By targeting where the hurt is, they can focus all their efforts in a way that gives them the biggest bang for the buck. Concentrating solely on improving decision making within customer service, for instance, makes this project eminently doable. The key is simply identifying where the most severe point of decision-making pain is, and every organizational leader has a good sense of where major problems crop up. Everyone is usually complaining about it, the company has set up committees and task forces to deal with it, and these are costing the company money, either directly or indirectly. Here’s a story from Roger demonstrating in microcosm how to identify where the hurt is: I’ve always done a good job when it comes to hiring people for my own company, but when it comes to hiring professors—a responsibility that came to me later in my career—I made uniformly poor decisions. I didn’t realize this at first, since I hired many well-qualified, smart people, most of whom did very well initially, but later on a number of them became very political and undermined me or other faculty members. I didn’t realize that in academic situations, you need to hire professors who you can control or who are completely focused on the academics and are apolitical. I didn’t have sufficient experience in hiring academics, and so I made poor choices. What I needed was someone who did have this type of experience tell me a story about




196


Obstacle 2: Our decision-making issues are so complex and nuanced that there’s no way to index stories or other related knowledge so they are retrievable. Companies are so used to organizing their materials by subject that cognitive indexing seems like a foreign concept. Yet it’s this type of indexing that allows the mind to retrieve memories based on what is happening now. It may sound like a task that requires nothing less than a cognitive scientist, but it’s actually a skill that many software designers can master if they understand what they’re dealing with. Specifically, software people need to get past the notion of filing things in the literal sense—by subject, date, alphabet, and so on. A good exercise for learning this skill is to take a proverb and equate it to a current goal conflict within the organization that is hampering decision making. For instance, the proverb, “a pig with two masters will soon starve,” links to the organizational reference “an employee reporting to two bosses [or teams] will soon serve neither well.” Indexing is all about identifying our goals related to decision-making areas, the plans we have to achieve these goals, the goals others have that hinder our own, and so on. Here is an example of how stories are indexed from Dimitris’ shipping business. In October 2008, he was contemplating an investment in bulk transportation stocks. At that moment of contemplation, these stocks had plunged in value by 70 percent. Dimitris had to make a decision, and as is usually the case when organizations are facing complex choices, there were no previous experiences that exactly mirrored the current situation. Yet he was able to make a wise decision—investing in these stocks on the assumption they would eventually rise—because



the treacherous behavior of a professor who through his machinations managed to get his boss fired on in trouble.

197

the stories that were retrieved were indexed properly. For example, one index was “You are always surprised by the degree of expertise in a business you don’t know.” Dimitris was contemplating investing in freight futures. He was highly apprehensive about the expertise people in freight futures trading possessed in contrast to his own scant knowledge of the field. The stories that came to him, though, cautioned against buying into something about which he knows less than his competitors. The people who sold when he bought or bought when he sold, were far savvier than he was in trading these particular instruments. He could get “killed” in an otherwise very timely investment. His homespun proverb of being surprised by the expertise of those in a relatively unfamiliar business provided cautionary examples that helped him make his decision. The point is that there are many ways to index knowledge that are conceptual rather than literal and have to do with goals and plans rather than subjects and objects. Everyone is capable of creating their own proverbs about their business that will retrieve knowledge about plans and goals just when it’s needed. Obstacle 3: Our people are used to being told what to do; they don’t know how to make decisions based on indirect methods like stories. It’s true that employees are used to being given explicit directions to help them do their jobs, especially at the lower levels of an organization. Even managers are accustomed to having their bosses provide them with “Dos” and “Don’ts” for their assignments. Just about every company has policies and procedures employees are expected to follow. It may also be difficult to visualize how employees will respond to timely stories delivered by experts on their computer screens; experts who may offer these stories because of the particular tasks employees





are dealing with online rather than in response to a specific search request. However, we’ve found that despite the standard practices of organizations, people generally hate being told what to do. You may recall the earlier anecdote Roger shared about a friend trying to decide whom to marry. Roger told him a story about a guy he hired who treated his soon-to-be-ex-spouse poorly and eventually treated Roger and the company poorly as well. The moral of both stories was, “Listen carefully to what people tell you because they mean what they say.” Both women had told Roger’s friend the truth about themselves. The point of Roger’s story was that his friend should take the women seriously rather than thinking he could change them or rationalizing what they had said. Roger’s story was very different from his friend’s situation on the surface, but at a higher level of abstraction, the goals and plans were the same. The story hit home with this friend in a way that the same advice delivered directly would not have. We are born listeners as well as storytellers. For thousands of years, people in very diverse cultures have learned from the lessons in stories. On the other hand, most people resent being told what to do, even if it’s the right thing to do. They either tune out the boss instructing them or they carry out his orders without much enthusiasm or creativity. Be assured that stories work as decision-making tools, whether told in bars and around the water cooler or emanating from the computer screen. Obstacle 4: We train our people to be logical, rational decision makers and to reason out solutions to tough problems; your cognitive approach seems to be anti-logic. Cognitive decision making is not “anti-logic”; it’s anti-fake logic. Managers like to believe they’re running highly rational systems when employees are only trying to act logically. Decision making is an



198

199

unconscious process, and employees aren’t aware of all the factors— especially emotional ones—that influence them to make a particular decision. We noted earlier that emotion can be useful when making a decision, but it’s also important to be aware of how emotions might be impacting a decision. In 2008, on the eve of the worldwide economic downturn, Dimitris had decided to sell a vessel. However, he was having problems doing so because the buyer was defaulting on the purchase. Dimitris was strongly encouraged by others to sell the ship even if it wasn’t a perfect deal. This all made logical sense to Dimitris. Yet, there was an emotional component to this decision: selling and buying vessels was Dimitris’ core competence and he took pride in his abilities. He didn’t want to sell it in a way that was below his professional standard. As a result, he did not succeed in selling the vessel. It’s possible that he might not have been able to sell it under any circumstances, but he lacked the motivation to pursue other selling options vigorously. If he had a software system that had been designed for this type of decision (at the time, the system was geared for more common, midlevel shipping decisions), he would have heard stories from others who had faced similar predicaments. For example, stories from people who been conflicted about lowering their professional standards in making the right business choice or a more cognitively abstract story that demonstrated how a lack of awareness of personal emotions had a negative impact on a decision. Systems based on the principles of cognitive science aren’t illogical but actually point out the flaws in our reasoning—flaws that can be related to a lack of awareness about the emotional implications of a decision. Obstacle 5: It costs too much. Whether for performance support or training, building cognitive software systems requires an investment. When companies measure the





cost of a modest classroom training regimen versus developing smarter software, the former is found to be less expensive. Far more important, though, are the cost savings that are accrued to an organization that chooses to implement cognitively designed enterprise software systems. These performance support systems guarantee massive savings in time and productivity across the entire organization on a daily basis. The high degree of usability alone yields tremendous financial benefits. Decision makers no longer have to waste hours each week searching for the knowledge they need so they can focus all their attention on making the right choice (rather than figuring out how to make the system work). While traditional knowledge management systems and cognitive-based software both require similar investments, the latter requires a bit more time and creativity to set up because it’s easier to create a passive filing system of documents than a proactive network of cognitively indexed stories, information, and people. Still, that extra effort is well worth the cost considering the huge return on investment from a decision-making standpoint. These systems can simply target a specific decision-making area. Companies don’t have to do a comprehensive overhaul of their enterprise software immediately. By creating test cases for the cognitive approach by focusing on one area of the company, costs can be controlled. When the test is successful, it can then garner the support needed to roll it out to other areas. The costs of a new enterprise software approach can also be amortized indirectly. This is the most significant way to overcome this obstacle. The cost of bad decisions to organizations is difficult to calculate, but every company wants to reduce the number of employee errors— especially major errors that hurt the company in some significant way and that with hindsight were clearly preventable. If a company looks at the major, preventable mistakes made over a period of time—say, six months to a year—and calculates the cost of these bad decisions, it can



200


201

The Diversity Opportunity: Why We Need Stories from Different Domains Now and in the Future “Thinking outside the box,” “breaking frame,” and like terms have become popular in business circles, advocating moving outside a narrow frame of reference in order come up with more creative ideas. Similarly, leadership gurus have suggested that senior executives need to invite other voices into their discussions, soliciting a wider range of opinion and perspective to avoid getting stuck in decision-making ruts. All this is fine, but not particularly useful from a cognitive standpoint. Telling people to think outside the box may inspire an innovative thought or two, but as we’ve emphasized, decision making is an unconscious activity. Even though people may make a conscious effort to think in new ways about an old problem, when they actually make a choice they’re thinking inside the box, relying on their relatively narrow range of experiences. In the same way, including a diverse range of perspective in decision-making discussions has a fleeting effect on the actual decisions. In most instances, these meetings and situation at hand are separated by weeks or even months. Outside people voice their opinions, but these views are either forgotten or lose impact over time. Decision makers need this input on the eve of making the choice for such perspectives to be impactful. This is why performance support software that contains a diversity of stories, experts, and knowledge is so useful. It not only arrives when it’s needed, but the system ensures that the information conveyed is across domains. Our example earlier in the chapter about Dimitris’



justify investing in software that would prevent at least some of these bad choices. Even better, this software would likely result in a number of good choices that would make money for the company.


decision about a bulk transportation stock investment illustrates why this is so important. As he was contemplating this investment, his system provided a variety of stories from different areas related to his proverb, “You are always surprised by the degree of expertise in a business you don’t know.” Rather than limit the stories to the bulk transportation sector, it brought him ●

●

A story about stock options purchases a year earlier in the tanker sector, which was a good investment but the options instruments were highly unpredictable for a non-expert. A story about oil product futures trade from 1990.

By integrating these stories from different domains and overlaying them on the situation he was facing, Dimitris concluded that the best instrument for purchase was one he knew how to trade rather than the freight futures that had initially seemed like a good investment but were an unfamiliar area for Dimitris. However, even more significant was the 30 percent drop in bulk transportation demand and the question of whether it would sustain itself or whether there would be a recovery. We will discuss this later. We emphasize the cross-domain concept because in the coming years it will be even more valuable than it is today. Increasingly, businesses are going to be facing problems where the old solutions don’t work. They will need fresh ideas for dealing with everything from competitive thrusts from Third World companies to integrating nanotechnology into their operations. Relatively little in company and industry history will help them with the decisions in these and other unfamiliar areas. Cross-domain knowledge can spark such fresh thinking. A story from another industry, from the non-business world, or from an expert in an area outside the ones usually consulted can reveal truths that would otherwise be hidden. As long



202


203

Insurance Against Bad Advice Increasingly, organizations are dependent on outsiders for significant business decisions. Because of downsizing and the growing importance of areas where the company lacks sufficient expertise (the environment, technology, specialized legal disciplines, etc.) organizations lack in-house experts on all important decisions. They must therefore bring in outside consultants for the expertise they require. We’re not suggesting that cognitive-based software can or should eliminate the need for outside help. However, many times companies are at the mercy of their consultants. With a system that retrieves expert stories from many domains on a wide variety of goals and plans, these companies could compare the outside advice with what the experts embedded in their software have to say. In other words, it’s an opportunity to protect a company from appealing but poor recommendations. This is especially useful when companies embark on growth strategies. By definition, corporate growth often means expanding into new markets with new products and services, changing distribution methods, exploring new technologies, and the like. It means venturing into an area where the company lacks experience. That’s when outside experts are called in for assistance. We know of one mid-sized software company that had launched an ambitious growth plan and had to bring in a consulting group specialized in marketing software innovation to implement it. This consulting group had worked with some of the biggest companies in their field and had an excellent reputation. They recommended an innovation



as these stories are indexed properly—popping up on screen as a decision maker faces a similar goal conflict or is trying to formulate a plan to achieve the same type of goal—then they will facilitate good decisions.


strategy that had been successful with some of their clients. It required introducing innovative products to the market at very low customer cost and depended on the massive adoption of this new product standard. The group claimed this investment offered a huge return—or at least it had for their other clients. The consulting firm’s track record, ideas, and profit projections were difficult to resist. The company decided to go forward with their recommendations, but the introduction of their innovations failed to produce good results. The problem, it turned out, was that the consultants lacked experience in introducing innovative software to narrower markets; they didn’t understand that unless there was major frustration with the current standard that the innovation was seen to relieve, a low-cost product was doomed to fail. This software company could have avoided making this bad decision if they had a cognitive-based system. When they were contemplating the recommendations of the consulting firm, they would have heard stories from experts about innovation and growth strategies, about big-company versus mid-sized-company strategies, about how markets respond to innovation when perceived product pain is low. These stories would have sounded alarms about what the consultants were recommending. More importantly, they would have led the software company in a new direction, helping them craft a strategy that was best suited for their situation—with or without the consulting group.

Put the Process to the Test Before we complete this book, we want to address an issue that goes through many people’s minds when we describe taking a cognitive approach to decision making and software design: Can these principles be applied effectively in an organization without software?



204

205

They can. If companies are small enough and possess significant experience and expertise for major decisions, they can use cognitive principles without software. By putting decisions in the hands of people with a wide range of experience, by encouraging them to make decisions based on intuition rather than lockstep analysis, by tolerating failure and using it as a learning experience, by promoting storytelling as a way to share information, then organizations can benefit from cognitive science. However, even small companies will benefit more if they integrate this science with software. With tasks, roles, plans and goals mapped into its design, a system can anticipate the decision-making needs of employees with uncanny accuracy. With expert stories and other knowledge indexed properly, decision makers can receive the right story at just the right time. With these systems e-mails, searches, and other communication modalities can be driven by what a decision maker needs to know and the best people to impart it to him. Still, becoming well versed in the cognitive approach to decision making doesn’t require software. We would urge every manager to become conversant in the principles highlighted in this book—the value of diverse experience, the benefit of expectation failure, and so on. We would also suggest as an exercise that managers practice dealing with the problems they face as part of their job through a cognitive science approach. Specifically, when managers find themselves trying to make a decision about a work problem, they should use the following steps: 1. Create an activity map that identifies the process where this problem is to be found; include the roles, tasks, plans and goals of key people involved. 2. Identify the goals and goal conflicts involved in trying to solve the problem—what is making the decision difficult?





3. Write a series of relevant proverbs or themes that capture the goals and conflicts. 4. Decide upon a questions that when answered will solve the dilemma and clear the path to a decision. 5. Recall stories from the company’s experience and across context to other domains that may answer the question. To test how these five steps play out in practice, let’s view them through the lens of Dimitris’ bulk transportation investment decision. Dimitris, as a shipping industry practitioner, was able to plot an activity map of bulk carrier market prediction. The proverbs he recalled, in addition the one about experts in an area of trading he was unfamiliar with, were “The best investment is one where the domain experts are caught wrong footed” and “When experts are caught wrong-footed they get stupid and misunderstand the situation they are in.” The latter recalled many media stories that were circulating at the time that served to confuse the issue rather than clarify it. In Step 4, we noted how decision makers should pose questions that need to be answered to clear a path to a decision. In this instance, the key question was: “Is the current plunge in the bulk market justified?” This question retrieved stories in the current media but also from other past sources across multiple domains. ●

●

●

A story about current orders for cars which were 50 percent down or so, together with a drop in other discretionary purchases that were responsible for the very negative current trend. A story about machine tool orders which always drop in the early part of a recession. A story on the banking crisis in the early 1980s about bankers refusing to give up providing letters of credit, one of their most secure businesses and the obvious reason why bulk carrier demand fell by 30 percent.



206

●

●

207

A story that involved a study of earlier recessions and concluded that demand in bulk markets never falls more than 3 to 10 percent no matter how bad the recession gets. Stories about construction projects in China indicating that they had not suddenly stopped, a positive sign for the bulk transportation industry.

These are the types of stories that can lead to good decisions, and too often they aren’t remembered by the decision maker or retrieved by his knowledge management system. This five-step process is designed as an exercise. It is not our recommended way to make decisions. It is necessarily abbreviated, since a real business decision would require more steps and likely a collaborative framework to monitor the other factors that can influence a decision maker (the emotional memories of past experiences, personal agendas, etc.). But we offer it here to give organizations the opportunity to apply cognitive science in business situations, approaching decisions using activity maps, goal conflicts, and stories rather than documents and rules. Once companies become familiar with applying cognitive processes to decisions, it’s only one additional step to translate these processes to software.

The End of Propreitary Knowledgde, the Beginning of Better Decisions An underlying premise of this book is that one way or another, people need to be able to access relevant knowledge and stories to make good choices. They must have the right group of experiences to draw from when they’re making a business decision or “borrow” these experiences from others—software is the best way to collect and distribute relevant knowledge from other sources.





However, this assumes that such knowledge will be available, and that’s not always the case. The most obvious problem is that people lack the necessary experience for their unconscious, case-based reasoning process to be useful for making an important decision. It’s also possible that their co-workers—direct reports, team members, etc.—also lack the requisite experiences to successfully guide decisions. Other possibilities are that the company software system is missing pertinent information, it may not have collected enough relevant stories, its database could lack crucial data for certain decisions, or it cannot access those with the knowledge essential for making an effective choice in a given situation. We emphasize all this because even the best software systems— cognitively based and designed with a high degree of usability—will fall short if a company neglects the simple task of identifying and recording its experts. This is a relatively easy task, but the majority of large organizations don’t do it. When an expert leaves the company, the knowledge leaves with him. Many times, the problem isn’t even that the experts leave but that the organization doesn’t recognize the value of finding its real experts and storing their knowledge in the form of stories. Specialized knowledge about a company and an industry are essential for decisions. General knowledge can be useful for some decisions, but the best type of knowledge is contained in a story that an expert has drawn from his experiences and relates directly to a decision maker’s goals and plans. So our best advice is that organizations make a sincere and continuous effort to find their experts and preserve their stories. Finally, we believe that the day is coming when organizations will have much more access to all types of expertise than they have had in the past. Even today, companies are drawing on all sorts of information that had been difficult to obtain in previous decades. The Internet and software technologies have helped organizations gain understanding



208

209

about everything from best practices in their industry to state-ofthe-art research on new manufacturing materials. What used to take months or years to reach an organization’s consciousness now takes seconds. Companies in the United States will learn of a breakthrough product in some Third World country almost instantly. While much of this knowledge may be irrelevant or tangential to an organization’s decisions, some of it can be crucial, and a cognitive-software system capitalizes on the availability of this knowledge by steering the right pieces of it to the right people at the right time. Our larger point, though, is that this accessibility will become even greater in the coming years. We’re going to see an end to proprietary knowledge at some point in the future, and probably sooner rather than later. Not only will organizations have access to their own experts but to their competitors’ as well. If this prediction seems unrealistic, consider the many companies already engaged in “co-optition,” working together on research projects that will benefit every company in their industry or banding together to establish global protocols for all companies in their field. The taboo of sharing knowledge with competitors has been broken (and even when a conflict of interest exists, software designed to identify it through activity models to help companies can help determine the consequences of sharing certain knowledge across traditional boundaries). So much proprietary knowledge is contained on computers that sharing is inevitable. Ample historical precedent suggests that if something exists on a computer, it will somehow make its way to another computer. We’re not talking about corporate piracy, simply the inevitable migration of knowledge online. Some of it will move because an individual in Company A shares it with someone in Company B because they’re working on a mutually beneficial project. Or an employee leaving Company A to join Company B will take his knowledge and files with him. Perhaps an expert from Company A publishes a white paper for the company’s Web site and it’s shared with





an outsider who in turn shares it with someone else until it is all over the internet. As proprietary knowledge ceases to exist, companies will have access to an unprecedented amount of information. Having a software system that qualifies and routes that knowledge to decision makers in a relevant, timely fashion will make a huge difference, not only for the outcome of a single decision but for a company’s overall competitiveness. In a world where all knowledge is available to all companies, the competitive edge hinders on well they capitalize on this knowledge. That’s where the cognitive-designed software systems come in, and organizations that move to adopt these models and its software will gain significant advantage in future markets.



210

Abelson, Bob, 67–68 abstraction, 2, 93–94. See also generalization; proverbs higher level of, 77–78, 94, 96, 97, 100, 120–21, 173 lower level of, 74, 93–94 academics, 111–12 accounting decisions, 52, 122 activity maps or models, 65–66, 71, 83, 88–92, 140–41 creating, 195, 205–6 e-mail and, 128 goal conflicts and, 104–5, 142 search engines and, 135–36, 139 stories linked to, 121–22, 174 advertising, 79–80, 90, 182 airline pilot, 36 ambiguity, 1, 5, 23, 73, 124, 153–54, 159, 168 Andersen Consulting, 116–17 Apple, 28–29 apprenticeships, 54–56 Artificial Intelligence, 60, 193 assembly line decisions, 52, 102 Balanced Scorecard, 144, 190

Bank of America, 27 baseball decisions, 37, 99 best practices, 26, 32, 107, 209 brainstorming, 39 Breakout Performance Web site, 27 Broderick, Gen. Matthew, 191–92 budget decisions, 34–35, 42–43, 74, 89, 107–8, 110, 119, 128, 173 Bush, George W., 191 Business Intelligence, 189, 192 Business Week, 57 Campbell, Andrew, 190 case-based reasoning, 17, 21–60 apprenticeship and, 54–55 benefits of, 41–43 high-level decisions and, 50–51 hiring, promotion, and retention and, 47–50 jobs learned through, 54–55 less tangible benefits of, 57–58 objectivity and, 45–47 operational effectiveness and, 51–54 restructuring and, 43–45 rules-based logic vs., 21–26, 33–36, 42



Index

case-based reasoning—Continued semiconscious state and, 37–40 shipping and, 42–43 smart risk-taking and, 55–57 software and, see cognitive-based software stories and, 30–33, 100 training and, 35–36, 159 transitioning to, 59–60 Citigroup, 27 client retention example, 79–80 cognitive-based software. See also specific examples and principles abstractions and, 173–74 activity maps and, see activity maps and models “anti-logic” of, 198–99 bad advice avoided with, 203–4 benefits of, 108–9, 124 cognitive principles and, 3–5, 9, 15–18, 60, 105, 194 collaborative decision making vs., 12–13 cost of implementing, 199–201 creativity and diversity and, 201–3 desktop as wrong metaphor for, 169–72 disparate elements brought together by, 79–81 ease of creating, 81–83 e-mail and, 126–32, 140 goal conflicts solved by, 10–11, 141–44 implementing, 17, 189–210

INDEX

indexing as natural fit for, 70–74 (see also indexing) information finds user with, 125–26 mathematical models vs., 194 obstacles to, 190–201 octopus metaphor and coordination and, 136–41, 144–45 outside knowledge and, 209–10 pain points and goal conflicts and, 101–3, 105 relevance and, 74–78, 103–5 reminding and dynamic memory and, 92–97 right stories at right time and, 13–14, 119–22 search engines and, 132–36 unlikely comparisons by, 98–101 usability and, see usability word processing and, 170 cognitive-based training simulation software, 3, 150–64 ambiguity and, 153–54 benefit of simulations in, 151–55 cost of, 200 expectation failure and, 153 fun and, 155 goal-based scenarios and, 154–55 key decisions and, 155–58 limitations and applications of, 161–64 principles of, 147–50 roadblocks to good, 158–61 cognitive science, 54–56, 74, 110, 120, 133, 170, 183, 189, 196, 199, 201. See also cognitive-based



212

INDEX

cross-functional teams, 44, 137 customer service, 21–22, 24, 51–52, 82, 91, 96, 101–3, 136, 157–58, 176, 191, 195 decisions and decision making. See also cognitive-based software; cognitive-based training simulation software; and specific concepts, examples, and processes case-based vs. rules-based reasoning and, 21–26, 30–36, 57–58 (see also case-based reasoning; rules-based decision making) cognitive principles applied to, 3, 13–18, 205–6 (see also cognitivebased software) common steps of, 82–83, 185 cost and status quo as impediments to, 11–14 cost of bad, 200–201 cumulative effect of small, 51–54 e-mail and, 127 emotion and, 72–73 evaluating new models of, 189–94 experiences and stories as aid to, 5–8, 13–14, 30–33, 64–66, 178 (see also experience; stories) experienced professionals and poor, 27–30 generic software and, see generic software importance of, 1–3, 41 octopus coordination problem in, 137–41



software; cognitive-based training simulation software and specific concepts and principles applying, without software, 204–7 basics of, 1–9, 17 case-based reasoning and, see casebased reasoning day of caveman and, 82–83 decision making flaws and, 12–14 desktop metaphor and, 169 expectation failure and, 56–57, 158 indexing and, 9–10, 66–70 semiconscious state and, 37–38 collaborative decision making, 12–13, 47 “collateral damage” concept, 9–10 company culture, 52, 72, 109–11, 115, 123–24 competition, 72, 120–21, 191 computer industry, 28–29, 61–62. See also software; and specific types of software computer-intuitive searching, 134 consultants, 107–8, 112, 116–18, 203–4 context, 14, 75, 171, 181–83 co-optition, 209 coordination (connecting dots), 88, 94–95, 103, 127–28, 137–41, 144–45, 181 Countrywide, 27 crises, 16–17, 23–25, 40, 48–49, 82, 184, 192 cross-domain stories, 94, 122, 139, 151, 201–3, 206–7

213

INDEX

decisions and decision making— Continued shipping as paradigm of, see shipping decisions specific areas of, 158–59 too many types of, 194–96 unconscious and “gut,” 1, 4–7, 22, 28–29, 37–40, 45, 72, 94–95, 122, 139, 154, 158–59, 181, 191, 199, 201, 208 unlikely comparisons as aid to, 94–95, 98–101 usability of software and, 168–69, 176 desktop metaphor, 169–72 Dewey decimal system, 67 discrimination negotiations, 72, 93–94, 162 documents, 63–66, 68, 108, 178, 180. See also information “dos” and “don’ts,” 154, 197 downsizing, 4, 10, 47–51, 93, 111, 140–41, 173, 203 e-mail, 61, 138 cognitive-based, 131–32, 136, 140–41, 145, 205 structured text and, 128–29 traditional, 125–26, 129–31 emerging markets, 4, 11, 125 emotion, 36, 72–73, 114, 117–18, 158, 191–92, 199 “emotional tags,” 191 Environmental Protection Agency, 154 expectation failure, 8, 32, 152–53, 158–59, 164, 205

experience, 2, 5–7, 12–14. See also stories case-based reasoning and, 21–24, 26, 36 downsizing and, 48–50 diversity of, 28–30, 98, 191–92 emotional impact of, 26, 36 hiring and, 48 limited or narrow, 45–46, 108 memory and unusual, 95–96 right mix of, 37–38, 71 experts (old salts, savvy veterans), 12, 17, 29–30, 32–33, 51, 55, 130–31 accessed by software, 70–71, 73–74 activity maps and, 91 cognitive abstractions and, 173 defined, 111 eliciting stories of, 111–18 future access to, 208–9 identifying and taping, 33, 83, 109–12, 123–24, 177–78, 195, 208 indexing stories of, 10–11, 119–22, 205 outside, 203–4, 209 recruiting and retaining, 48–50 reminding by, 91–94 training and, 152, 156, 160–61, 164 failures and mistakes, 8, 49, 55–57, 99, 142, 144, 205. See also expectation failure cost of, 200–201 mapping, 90 stories about, 60, 90, 111, 114–18



214

training and, 150, 157–58, 163 usability and, 168, 175, 180 filing systems, 68, 122, 169 financial managers, 25–27, 30 Finkelstein, Sydney, 27, 190 Fisher, Roger, 116–17 Fleet Bank, 27 Ford Motor company, 66–67, 132, 171 friend paradigm, 175–77 fun, 155, 159 Gartner Group, 192 General Electric, 57 generalization, 25, 95, 97–99. See also abstraction; proverbs General Motors, 11–13, 26 generic software, 2–3, 9, 87, 97, 144, 169–72, 182–83, 185–86 global markets, 26, 111, 120–21 goal conflicts adjudication of, 6–12, 16, 18, 42–43, 102, 104, 117, 136, 141–45, 173 friend paradigm and, 176 human mind and, 69–70, 74–75, 82–83 identifying, 91, 205, 207 pain points and, 101–5 proverbs and, 206 search engines and, 136 software and, 65, 87, 94–95, 109, 122, 141–45, 173, 196–97, 203 stories and, 113–14, 116–17 goals, 2, 44, 69–70, 75, 82–83, 104, 205

215

e-mail and, 128, 138 indexing and, 96, 196–97 learning and, 154–55, 159 long- vs. short-term, 176 proverbs and, 100, 206 search engines and, 133–34, 138 stories and, 116, 198 Goldman Sachs, 26 Google, 62, 132 graphical user interfaces, 172–73 growth strategies, 10, 64, 69–70, 75, 101, 203–4 gut instinct (intuition, “sixth sense,” unconscious), 1, 5, 7, 9, 13–14, 28, 37–40, 43, 52, 56–59, 72, 139, 154, 191, 199, 205 case-based reasoning and, 22, 24–25, 30 rules-based logic vs., 33–36 Hammond, John S., 192 Harvard Business Review, 190, 192 Harvard Negotiation Project, 116–17 hiring and promotion, 17, 30, 47–50, 57–58, 71, 75, 82, 91, 195–96. See also human resources Homeland Security Operation Center, 191 human mind, 1, 7 central processor and, 144–45 complex methods of, 193–94 desktop wrong metaphor for, 169 experiences and, 23, 25, 36–40 ignored by software engineers, 61–63 indexing and, 9–10, 67–69, 139



INDEX

INDEX

human mind—Continued information management and, 95–96 reminding and, 23, 92–93 human resources, 65, 72, 92–93, 97, 99, 141, 156, 161, 162. See also hiring and promotion IBM, 29, 82, 138–39 icons, 167, 172–73, 187 indexing, 9–11, 65–78, 203 of actions, vs. 3Ps, 96 dynamic, 144–45 e-mail and, 128 emotion and, 191 expectation failure and, 158 expert stories and, 31, 65, 73–78, 83, 116–17, 120–22, 179, 205 human mind and, 38, 57, 67–70 proverbs and, 99–101, 196–97 search engines and, 133–34 software and high-level, 60, 66–75, 95–98, 140–41, 144–45, 173 industry-specific factors, 2, 95, 112, 179–80, 192 information (data). See also key words; search engines ability to separate wheat from chaff, 73–74, 126 decision makers overwhelmed with irrelevant, 103–4, 190, 210 documents vs. stories and, 60–66, 79–81, 178 dynamic memory and, 94–97

finding, vs. being found by, 125–45 finding relevant, 87–89, 182–83, 208 lack of contextual knowledge and, 171–72 innovation, 120–21, 203–4 Internet, 208 internships, 54–55 Intuit, 57 Journal of American Documentation, 66 Katrina, Hurricane, 191–92 Keeney, Ralph L., 192 key words, 64, 68, 94, 105, 132, 139, 169, 175 Kid from Left Field, The (movie), 6, 7 knowledge management systems, 32–33, 61, 63–66, 108, 137–39, 207 cost of, 200–201 e-mail and, 126–27, 130–31 evolutionary vs. static, 174 searches and, 68–69, 87, 122, 130, 133–34, 171–72, 180 static vs. dynamic memory and, 94 labels, 38, 66–70, 75, 144, 157 labor negotiations, 116–17 leadership training programs, 35 lean methods, 107–9 learning, 8, 13, 54–57, 96–97. See also cognitive-based training simulation software Lewis, Ken, 27 logic and rationality, 4–5, 7–8, 13–14, 21–25, 33–36. See also rules-based



216

decision making “fake,” 198–99 Lotus, 138 manufacturing, 98, 107, 116, 183 marketing, 79–80, 89–90, 182, 111, 178, 182, 191, 203–4 mathematics-based decision making, 189–90, 192–94 memory, 31, 38, 45, 46, 74–75, 193 dynamic, 94–96 emotion and, 158, 162, 191, 207 static, 94, 140 topographical, 172–73 mentors, 151–52, 159 mergers and acquisitions, 69–70, 82, 104, 113–14, 171 Merrill Lynch, 27 Microsoft, 26 Microsoft Dynamics, 2 Microsoft Word, 169–70 MNBA, 27 Moffett decision-making training, 148–49, 151–52 neuroscience, 189–91 object-based software, 89, 91 objectivity, 35, 38, 45–47, 191 outsourcing, 111, 120–21, 170 pain points, 101–5, 157, 195–96 Pepsi, 28–29 performance reviews, 49, 52, 53, 75 plans, 100, 104, 198, 205

217

e-mail and, 128, 138 friend paradigm and, 176 human mind and, 69–70, 75, 82–83 indexing and, 96, 196–97 search engines and, 133–34, 138 Platt, David, 8–9 prioritizing, 58, 76–77, 88, 126–28 Procter & Gamble, 9–10 product introductions, 45–46, 69, 110–11, 120, 161, 162, 203 proprietary knowledge, 207–10 proverbs, 98–101, 105, 202, 206 creating and indexing, 196–97 “experts caught wrong-footed,” 206 “good market, bad buy,” 100 “if it ain’t broke,” 121 “listen carefully to what people tell you,” 198 “make enemy friend,” 98–99 “money in bank and ships on water,” 100 “necessity is mother of invention,” 121 “pig with two masters,” 196 “stitch in time,” 100–101 “surprised by expertise in business you don’t know,” 197, 202 “think long, think wrong,” 99 “trend is friend,” 100 purchasing, 30, 52, 61, 63–65, 110, 119, 173 quality problems, 101–2, 116 questions, key, 206



INDEX

INDEX

Raiffa, Howard, 192 “red flags,” 77, 191 relationship-building training, 163–64 relevance, 45–46, 51, 62, 73–74, 103–5, 110, 116–17, 132–33, 135–36, 179–80, 186 dynamic indexing and, 145 e-mail and, 129 reminding, 105 e-mail and, 127–29 human mind and, 69–70, 92–94 software and, 60, 71–72, 92–97, 174 repairs, 42–43, 77–78, 98, 100, 102, 110, 129–31, 142, 163, 181, 184 research and development (R&D), 11, 13, 45, 110, 138 restructuring decisions, 43, 82, 120, 133 right-versus-right decisions, 3, 7, 18, 124 risk taking, smart, 55–57 roles and responsibilities, 88, 97, 104, 140, 143, 205 e-mail and, 127–28, 138 mapping, 90, 205 proverbs and, 100 search engines and, 133–34, 138 usability and, 176, 181–82 Romeo and Juliet (Shakespeare), 68–69 rules-based decision making, 39–40, 42, 53–54, 58, 72, 75, 122. See also logic and rationality case-based reasoning vs., 21–26, 33–36 transitioning from, 59–60 Russo, J. Edward, 13

safety, 16, 76, 80–81, 142–43, 180, 184 sales, 21, 38–39, 52–53, 65–66, 91, 97, 102, 184 Satyam, 138 Schoemaker, Paul J.H., 13 scripts, 52–54, 75–76, 95, 97 Sculley, John, 28–29 search engines, 62, 67, 126, 138–39, 169–72 cognitive, 132–36, 145, 205 Shakespeare, 68–69 shipping decisions, 3, 15, 16, 180–81 boiler fire, in Suez Canal, 6–7, 36 bulk transportation investment, 196–97, 202, 206 case-based reasoning and, 31–32 e-mail and propulsion problem, 129–32 game of buying ships, 118 goals of decision-makers in, 142–43 hydrocarbon alarm, 181, 183–85 identifying experts and, 110 indexing of stories and, 196–97 inspection and safety, 80–81 local pilot, 144 managing corruption, 31–32 noise in engine, 76–78, 88, 92, 102–3 piracy and plants, 99–100 port arrival, 134–35 proverbs and, 100 right story at right time and, 76–77 safety-vs.-speed, 142–43



218

ship repair-vs.-budget, 42–43 ship selling, 199 software created for, 15–16 stevedore problems, 121 turning ship, 119 usability of software and, 180–86 talented engineer with poor behavior and, 163–64 short- vs. long-term fi xes, 16, 173 single false case, 46, 51 Smart Choices (Hammond, Keeney, and Raiffa), 192 software. See also cognitive-based software; cognitive-based training simulation software; generic software and specific concepts; issues; and types case-based reasoning and, 59–60 different types, defined, 60–61 document vs. stories and, 63–66 human mind not understood by designers of, 61–63 indexing by, vs. human mind and, 66–74 standard, vs. potential of new, 14–18 truths about, 8–11 usability and, 167–87 Spandan software, 138–39 specificity, 2, 29, 104–5, 109, 115–18, 144, 162, 171–72, 179 spellchecking, 169–70 sports coaches, 40 Starbucks, 11 “steak and haircut” story, 67–68

219

stories. See also experience activity maps and, 66, 91 collecting compelling, 31–33, 113–18, 195 diversity of, 123–24 documents vs., 63–64, 180 e-mail and, 129, 131–32 indexing, for easy retrieval, 10–11, 60, 65–66, 71–72, 118–22, 140–41, 173–74, 196–98, 205–7 indirectness of, as obstacle, 197–98 organizing, with goal conflicts, 109 organizing, with proverbs, 100–101 outside experts, 203–4 training and, 152, 156, 160–61, 164 usability and, 178–79 right, at right time, 14, 17, 43–44, 47, 50–51, 66, 76, 108 software to retrieve, 30–33, 73–75, 103–5, 173, 205 usability and, 177–81 Task Assistant, 15 tasks, 62, 71, 89–90, 96–97, 104, 119–20, 140, 176 coordination and, 137–40 e-mail and, 127–28, 131, 138 mapping, 205 proverbs and, 100–101 search engines and, 133–34 teachable moment, 56, 72, 159 team selection, 151–52, 176 Think Again (Finkelstein), 27 “thinking outside the box,” 201–3



INDEX

Thompson, Frederick B., 66 topic shifting from one to next, 184 sticking to main, 185–86 training, 3, 8. See also cognitive-based training simulation software instruction vs. action and, 147 new hiring vs., 91 rules vs. cases and, 35–36, 54–55 scripts and, 52 seminars and, 71–72 Ulysses Systems, 15 U.S. Army, 115 usability, 17, 167–87 financial benefits of, 200 five requirements for, 172–75 friend paradigm for, 175–77 lessons from shipping on, 180–86 level 1, 167–70

INDEX

level 2, 167–68, 186–87 user, 62–63, 65, 71, 87, 167–68, 174–77, 187 utility theory, 194 “warning signs,” 103 West Side Story (musical), 68–69 “What-You-See-Is-What-You-Get” (WYSIWYG) design, 62 Whitehead, Jo, 190 “Why Good Leaders Make Bad Decisions” (Campbell, Whitehead, and Finkelstein), 190–91 Why Software Sucks (Platt), 8–9 Winning Decision (Russo and Schoemaker), 13 Wittgenstein, Ludwig, 37 word processing, 62, 169–71



220

The Future of Decision Making: How Revolutionary Software Can Improve the Ability to Decide

Digital Decision Making: Back to the Future

The Making of Revolutionary Paris

The Art of Decision Making

The Art of Decision Making

The Routines of Decision Making

The Consequences of Decision-Making

How We Decide

The Decision-Making Pocketbook

Making the Antidepressant Decision

How We Decide

The Future of Software Engineering

Punitive Damages: How Juries Decide

How We Decide

How We Decide

How To Improve Your School

Can We Shift To The Solar Future?

Handbook of Decision Making

Patrick Pearse: The Making of a Revolutionary

Patrick Pearse: The Making of a Revolutionary

Handbook of decision making

Decision Making

Decision-Making at the Chessboard

How to Improve the Results of Peripheral Nerve Surgery

The Three Secrets of Wise Decision Making

Straight Choices: The Psychology of Decision Making

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

The Future of Decision Making: How Revolutionary Software Can Improve the Ability to Decide

Digital Decision Making: Back to the Future

The Making of Revolutionary Paris

The Art of Decision Making

The Art of Decision Making

The Routines of Decision Making

The Consequences of Decision-Making

How We Decide

The Decision-Making Pocketbook

Making the Antidepressant Decision

How We Decide

The Future of Software Engineering

Punitive Damages: How Juries Decide

How We Decide

How We Decide

How To Improve Your School

Can We Shift To The Solar Future?

Handbook of Decision Making

Patrick Pearse: The Making of a Revolutionary

Patrick Pearse: The Making of a Revolutionary

Handbook of decision making

Decision Making

Decision-Making at the Chessboard

How to Improve the Results of Peripheral Nerve Surgery

The Three Secrets of Wise Decision Making

Straight Choices: The Psychology of Decision Making

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Clean: The Revolutionary Program to Restore the Body's Natural Ability to Heal Itself

Recommend Documents