The Design of Insight
How to Solve Any Business Problem
Mihnea Moldoveanu and Olivier Leclerc




Innovative solutions to complex business problems are like works of art: they elicit emotions similar to the ones we feel in front of great paintings or photographs. They transform our views of the world by showing it to us from different perspectives. When Yann Arthus-Bertrand shows us a photograph of the earth from the sky, it not only expands our horizons in the literal sense but reveals unsuspected patterns in the landscapes we thought we knew well.

A new theory, like the special theory of relativity, does even more for us. Einstein’s insight that light moves at the same speed in any inertial frame implies that space, time, and the mass of a moving object contract or expand as a function of the speed with which the object moves relative to a nonaccelerating frame. It is a lens that lets us make a new and valid prediction: the rate at which particles’ energy states will decay as a function of the speed with which they move, something the previous picture of space-time did not predict. The new theory does not give us new information. It adds new insight to existing information—to the facts we knew when looking through the old lens—and sets our gaze on critical new information we can seek out.

A new way of looking at a business can also make unseen patterns visible and reveal innovative levers we can use to drive changes that have impact. When Coca Cola describes itself as a conditioned reflex business rather than a “soft drinks business,” its marketing department begins to think about how to engineer stimuli that will trigger customers’ buy-and-consume routine so reliably that it becomes a reflex. Then the company sets to work on optimizing the color of the drink, the shape of the container, and the sound patterns of the commercials to trigger consumers’ desire to “have a Coke and a smile” as a matter of reflex rather than a considered choice.

Google understands itself as a company constantly searching for the best search process. Its approach to research, development, and deployment has taken on a vinelike characteristic—one that is adaptive and expanding. “Search,” writ large, is its raison d’être, which encourages it to stay at the forefront of a human activity—search and re-search—that has been addictive since before we knew what the Internet was. Google Earth, Google Books, Google Scholar, Google Patents, and Google Code are all exploration vehicles that expand users’ search repertoire while furthering the company’s own search for better ways to search.

The business world offers up challenges involving large sets of variables on consumer behavior, trends, regulatory uncertainties, shifting competition, new technologies, and more. Finding a way to see these variables in ways that illuminate an insightful course of action is not so different from seeing the world through Bertrand’s photo lens or seeing time and space through Einstein’s model. The trick is to discover a lens that focuses us on the variables that matter—those we can observe and control to bring about useful change. To do so, we need to look and see differently. We get to insight by building and using a new lens, not just by collecting more data and analyzing it. That is how we design insight.

Shedding new light on a predicament is hard because we tend to gravitate toward familiar ways of seeing. Our existing models, metaphors, and frames shape our ways of looking, and precedents constrain what we end up looking for. They can provide useful shortcuts for transferring insight from one field of practice to another, but they are our enemies in producing new insight: they are the pictures we took using yesterday’s lenses.

This book is an exercise regime for the business mind that seeks insight—a personal problem-framing and problem-solving assistant for business problem solvers. It can be used as a think-out-loud document for strategists, advisors, and executives, alone or in teams, and it answers the questions that should guide all insight seekers—for example:

• How can we harness thinking deeply and precisely to seeing more clearly?

• How can we broaden our line of sight into possible solutions—or narrow our focus to avoid getting sidetracked without losing perspective?

• How should we design the process by which we design business solutions?


In business, we never begin our work with a well-defined problem. We start from a difficulty, an issue, a challenge, or a predicament:

• Quarterly sales have suddenly plummeted. What now?

• Manufacturing costs have skyrocketed over the past two quarters. What do we do about it?

• Our arch-competitor has announced a new product we’d not even conceived possible a quarter ago, and it looks like a market beater. How do we respond?

• The client’s top management team has gone into a motivational slump according to the chairman of the board: How do we change their behavior?

These are not problems. They are vaguely articulated predicaments, or challenges. As business problem solvers, we never “solve problems” already posed. The work we do creates most of its value through defining problems: turning predicaments into precisely articulated problems we can solve.

What does that mean? What is a well-defined problem? It is a difference between the way things are and the way we want them to be. “Precisely articulated” means just that: we want to be able to measure the most relevant variables pertaining to where we are (the current conditions) and where want to be (the desired conditions); define the time frame in which we will get there from here; and map out the space of possible solutions, that is, the permutations and combinations of all possible changes in the variables we can influence to take us from where we are to where we want to be.

The prototypical well-defined problem is a jigsaw puzzle: you have a stack of nine square tiles, each with some pattern on it. These are the current conditions. You know that the solution to the puzzle is an arrangement of the nine tiles in a square three-by-three tile array such that the patterns fit together, that is, they produce a coherent image (the desired conditions). The space of possible solutions—the solution search space—is all of the possible three-by-three arrays of tiles you can create using the nine tiles at your disposal.

This problem is not simple, but, it is well defined. You know what the solution should look like: you have some hint in or on the box of the tile package. You can verify whether any configuration of tiles fits the bill. You have the means to alter the position or rotation of any tile to get closer to the solution to the puzzle. You may also know that the solution is unique. That will help because you will be aiming to solve for one thing, not for any one of 10, or 100, or 1,000.

Once you have a well-defined problem, you can write down the full solution search space and the rules for searching for a solution. If you are rushed or derive no enjoyment from solving jigsaw puzzles other than the satisfaction of having solved one, you can hire a good Python or C++ programmer who will, for a hundred dollars or less, write code that finds the solution to the puzzle (and all similar puzzles, to boot) in no more than an hour. Clearly the problem definition step is where the gold lies. It is where we add most value when we are engaged to solve problems. The rest is code.

How do you best turn a loosely, fuzzily, tentatively articulated predicament into a well-defined problem? How do you turn hunches and intimations about difficulties like, “We have an accountability problem around here?” into a problem that is defined in terms of actionable levers and observable inputs and outputs, like, “How do we allocate decision rights over order fulfillment decisions to top management team members to achieve a 20 percent improvement in an accountability metric defined in terms of promises made, kept, and broken, and by the end of six months or sooner?”


Language is the key to defining problems. Language matters to problem solving because it supplies the basis for posing problems, that is, for defining them.

At the core, as businesspeople, we end up truly solving only two kinds of problems: prediction and optimization problems. Prediction problems like these: How will competitors respond to our new product? How will this budget cut affect our ability to ship product next quarter? How will the new management team respond to this new ownership structure? And optimization problems like these: How do we most efficiently increase top-line revenue by 20 percent without making additional investments in sales and marketing? How do we achieve the minimal-cost R&D organization for achieving the desired target for earnings before income, taxes, depreciation, and amortization? How do we most effectively aggregate new client information for maximum informativeness to the top management team so as to cut decision time by 20 percent?

Prediction feels intuitive to us, whereas the concept of optimization is worth unpacking because its name and the formalisms that economists and engineers use to represent it often make it sound mysterious and opaque. In fact, it is a natural process that all living creatures engage in at various levels of sophistication, using four elementary steps:

1. Enumerate, or, list, the alternative options for solving a problem. For instance, list all the possible ways to allocate 3 different kinds of incentives to each of 4 different people–already a hefty list of 34, or 81, different reward structures.

2. Evaluate the net benefits of each of the alternatives. For instance, evaluate the benefits of the higher motivation induced by the incentives, net of the costs of the side effects of people pursuing their own incentives at the cost of the firm’s benefit for each allocation;

3. Compare the net benefits of the different options among them so as to be able to rank them from highest to lowest in terms of the net benefits they will bring.

4. Select the option with the highest net benefit. This is the optimal solution.

Optimization is rarely easy to do. But it is easy to understand and can stay that way if we remember its foundations.

All well-defined business problem are combinations of prediction and optimization problems. The catch-all problem, “What should we do about X?” can always be decomposed into this prediction problem, “What happens if we do a, b, c, and d?” and an optimization problem, “What is the best way to get from X to Y?”

To get to a well-defined prediction-optimization problem requires looking at a challenge through the prism of a problem-solving language. It specifies the variables to try to predict and optimize over, the variables to control and observe, and the measures of performance or success. For example, consider this challenge. The CEO of a large manufacturing business is facing an accountability challenge at the level of her top management team: important client information falls through the cracks, critical orders are shipped late or with defects, and promises that team members make to address the shortfalls are not kept. Order fulfillment is currently slow, sloppy, and unreliable. We can measure speed, precision, and reliability and define an objective—a goal we are driving to. We know the CEO believes the root cause of the difficulty is at the level of the top management team—four executive vice presidents and chief X officer-level people whose collective and individual behavior have led us to where we are now. Let’s trust her on that (for the time being).

What we do next in this situation depends on the lens we choose, that is, our way of seeing the challenge. It allows us to focus on specific parts of the challenge, which will become the variables of our problem statement. If you look carefully at figure 1.1, you will see that it can turn into a duck head or a rabbit head, depending on where you start off scanning it. Scan it from the left, and it looks like the profile of a duck’s head; you will make out the beak, the plumage, and the eye. But scan it from the right, and it looks like the profile of a rabbit’s head; you will make out the ears, the fur, and the eye.

Problem-solving languages have the same lensing feature: you can see the challenge as one problem or as another, depending on which language you use. The language is what guides your gaze. For instance, you can think of the team as a network of information flows and trust ties, as figure 1.2 shows. Then you specify the problem in terms of the bottlenecks in the timely and reliable flow of accurate and relevant information about the order fulfillment process. You next consider ways in which to optimize the network to minimize bottlenecks, misunderstandings, and the flow of distorted information. You could do this by increasing the flow of information among team members who trust one another or making public the private exchanges of information between team members who do not trust each other (e.g., using boards that track service levels over time between two production units within a plant), so distortions of information can be monitored more easily.

FIGURE 1.1. A bistable image that turns into a duck’s head or a rabbit’s head, depending on where your gaze starts scanning. source: "Kaninchen und Ente" (Rabbit and duck), Fliegende Blätter (October 23, 1892).

Now change your lens and think of the team as shown in figure 1.3: as a group of self-interested agents who make decisions on the basis of different levels of authority (their decision rights), different levels of expertise and decision-relevant information, and their own private incentives that may differ from those of the business. You can use this to consider ways in which to reallocate decision rights and incentives to improve the efficiency of the order fulfillment process—for instance, by giving more decision rights to team members who have mission-critical information and aligning the incentives of executives with those of the business.

FIGURE 1.2. Picturing the executive team as an information network.

FIGURE 1.3. Picturing the executive team as a set of agents making mission-critical decisions based on the structure of authority in the team, captured by the distribution of decision rights to team members.


To practice business problem solving effectively, you need a method—a series of reliable steps that prescribe a set of actions and are guided by a goal.

Our method begins by specifying the variables to focus on. If we look at the executive team as a group of agents with different levels of authority, we focus on the relationship between the decentralization of authority (how many decision rights the CEO has relative to others on the team) and the efficiency of the process (orders logged and shipped, delays, defects, rework requests), shown in figure 1.4A. We then estimate from prior experience and industry data the key relationships. Let’s say our case studies show that efficiency increases with decentralization of authority for problems such as ours, shown in figure 1.4B. We are on our way to a solution (decentralize authority) except that we do not know where on the curve the current team lies, so we measure the concentration of decision rights in the order fulfillment process in this case, as in figure 1.4C, which gives us the initial conditions for our problem. To figure out what we could do, we use our initial conditions and the relationship between the variables to predict the range of possible improvements we can make, as in figure 1.4D, and then optimize our solution by choosing the allocation of decision rights between top management team members that will produce the greatest improvement in the process measures (fulfillment delays, reliability) in the executive team, as in figure 1.4E).

This five-step process of specify-estimate-measure-predict-optimize (SEMPO) takes us from an ill-defined accountability challenge to a well defined problem (reallocate decision rights over D-type decisions to increase efficiency of process P to which D-type decisions are relevant), which naturally breaks down into two subproblems, predict and optimize, that are the workhorses of business problem solving.

FIGURE 1.4. The five elementary components of business problem solving.

What we get by being methodical is depth and precision. We end up with a well-defined, well-posed set of problems we can proceed to solve by making the changes to variables we can measure (decision rights) and that we predict will bring about the desired changes in the values of another set of variables we can measure (efficiency of the order fulfillment process).


Depth of understanding is only one of the upshots of our problem-solving languages. The other is breadth: the diversity that arises from putting several different languages to work on the same challenge.

The “Dream Team”

Imagine you have the chance to build a dream team for competing in a sports meet. You can pick from the 2012 medal winners in all of the sports represented in the Summer Olympic Games to build it: Roger Federer or Andy Murray (tennis, singles), Michael Phelps (swimming), Usain Bolt (short sprint), Sandra Izbasa (gymnastics, vault), Gabby Douglas (gymnastics, parallel bars), and so on. Of course, you will need to compensate each of these athletes according to both the value that he or she brings and each person’s market price, so you should choose judiciously.

Your first question may be: What sport am I competing in? It might be inefficient to have both Izbasa and Federer around. Suppose, though, that you do not know in advance what you will have to excel at: you will find out only at the last minute but must commit to a roster now. This may seem unfair, but it is what we have to do when we tackle business problems in real time: we do not know what the world will turn up, but will have to deal with whatever it throws at us. It makes sense, then, to assemble a team that will let you draw on Federer, Bolt, Izbasa, Douglas, and however many more megatalents you can afford, depending on the game you will face. Uncertainty about the game increases the value of your options and flexibility to use them—the value of your team’s diversity.

Since you do not know beforehand what talent is needed, you’ll want to have as many different talents as possible. That may lead you to build a very expensive team—so expensive, in fact, that the value you might create by winning may be dissipated by the value claimed by the stars you need to keep on retainer. Is there a better way?

There is. You can figure out the skill that each one of the star athletes brings and hire those who bring the highest-value, non-overlapping set of skills to the team. Federer will bring superlative eye-hand coordination: the ability to quickly and forcefully pronate, extend, and supinate the right forearm—essential to the production of his monster forehand—as well as the ability to sprint from a standing start. Bolt will bring height, reach, and an uncanny ability to adduct the hip—the speed-limiting step for a sprinter. Izbasa will bring her spinal flexibility, strength of wrists and ankles, and total body coordination required to land a vault jump without faltering. This basic skill decomposition of each athlete will allow you to make efficient choices in assembling your all-star squad and evaluate the relative and marginal value of any athlete. It seems obvious that you may not need both Federer and Murray but you may also realize that given Federer’s skill set, Usain Bolt will be worth less to your endeavor if you’ve just signed up Federer: you have sprints covered with the Swiss star. That frees up resources to go after other skill sets that do not overlap: maybe you can now afford Kobe Bryant’s reach.

The Business Dream Team

If you had to build a dream team of business advisors or executives, your first instinct might be to go for the top experts in the classical functions of business: finance, accounting, marketing, operations, strategy, and human resources management. You do not know beforehand which of these functions will figure prominently in your next assignment, and business problems are not neatly cut up at the joints into parcels that can be dealt with by different experts: you are the one who must do the handiwork of parcellation.

It would be much more efficient if you could identify the elementary skills you would need to solve any business problem and then recruit the team that has the very skills you will require. Strategists and finance theorists may be good at figuring marginal and total incentives and designing value-sharing mechanisms that allow you to extract the maximum benefit from a business situation. Operations specialists may be good at mapping processes in terms of ebbs and flows of raw materials, products on an assembly line, and even money and information.

Each distinctive expertise is in fact based on a problem-solving language spoken by practitioners of a discipline. Like any other languages, these have a vocabulary and a syntax—a bunch of rules for putting words together in phrases. They are also like computer languages in they are used to precisely pose and subsequently solve problems. That is why we call them problem-solving languages.

It turns out that most of the languages of business come from just three disciplines—economics, sociology, and psychology—with a few other disciplines, such as operations research, contributing additional models and methods at the margin. Equipped with their basic tool kit of problem-solving languages, you may be able to eschew the experts altogether (along with their inflated fees and self-important talk) and go straight for the core of their expertise. Instead of hiring Federer for his eye-hand coordination, you could hire a nimble juggler with a high willingness to learn new applications of her juggling skill. Or you could design a set of eye-hand coordination exercises that can help one of many more connected, willing-to-help humans produce the performance that you need.

Problem-solving insight itself comes from the diversity of the languages you use to define business problems, which requires mastery of several problem-solving languages. This is a strong claim, and it requires substantiation. A great deal of recent work suggests that teams of smart people from different backgrounds come up with innovative solutions more quickly than individuals or like-minded groups do. The reason is that the individual members of such teams look at predicaments through different lenses, and thus each sees a different problem. Each team member adopts a representation of the problem that is conditioned by her worldview, built out of words and sentences shaped by metaphors or models. A game theorist may articulate the problem of pricing a new product as one of equilibrium calculation and selection. A network theorist may see optimizing strategic partnerships as a problem of choosing the most connected or well-known members of the industry network. A problem of accountability in an organization may look like a pay-for-performance challenge to an economist, whereas the same accountability problem may look to a psychologist like a problem of choosing the management team with the highest individual self-efficacy or the most rooted collective identity.

Team interactions among experts who see problems through different lenses are confrontations among different ways of thinking that force each member to see the problem differently from how he or she would alone. The space of possible solutions grows and more likely will generate the hidden gem of insight because the search is broader and more likely to catch it.

Businesspeople often think of languages as tools for saying stuff, and they are. But they are also tools for seeing and for acting differently: We use language to think, not just to speak. How we think shapes both what we see and what we do. So the language we use shapes how we think and thus what we see and do. Insight is both about seeing more clearly and about seeing more—or seeing what others cannot see. We can get to seeing more by seeing in more ways, which means in different ways:

How Diversity Works

Kevin Dunbar, a cognitive psychologist, studied a number of laboratories to understand how scientists solve problems thrown up by their experimental work. First, he realized that most problems are solved during weekly lab meetings in which scientists describe their experiments and the difficulties they encountered. He then compared the meetings of two teams from different labs who faced the same problem: Escherichia coli proteins were sticking to filters, which made them impossible to analyze. He discovered that labs with scientists from different backgrounds (e.g., biochemists, molecular biologists, geneticists, and medical students) generated solutions more quickly than labs with exclusively E. coli specialists. “The E. coli group took a brute-force approach, spending several weeks methodically testing various fixes. They eventually solved it, but they wasted a lot of valuable time.” The more diverse team mulled the problem much longer at each meeting. None of the scientists was a protein expert, so they began a wide-ranging discussion of possible solutions. At first the conversation seemed directionless. But as the chemists traded ideas with the biologists and the biologists bounced ideas off the medical students, potential answers began to emerge. “After another 10 minutes of talking, the protein problem was solved,” Dunbar says. “They made it look easy.”1

Why Diversity Works

Research in a very different field supports Dunbar’s conclusions. Mathematical economists Lu Hong and Scott Page have shown analytically that for a complicated problem whose set of possible solutions is so large no expert can find the optimal solution in a finite amount of time, a group of nonexperts will usually outperform a group of experts in solving it.2 Two conditions apply: everyone understands the problem and can articulate it in his or her own language, and the problem is hard enough that no single expert can solve it using a brute-force approach.

Consider Dunbar’s example again. Unlike the E. coli experts, the second lab lacked a shared language. In arriving at an understanding of the problem, the team members had to reach for analogies and metaphors to explain things to one another. They introduced one another to different ways of seeing the problem. In contrast, the shared jargon, assumptions, and conventional wisdom led the expert group to shepherd the problem efficiently into a box they all knew how to work in. Unfortunately, the box contained only procedures that were not well tailored to the problem.

To get out of a box, you need different ways of looking at the problem. That’s what problem-solving languages give us. But is there a problem-solving language that can be a jack of all trades—one that beats out all others on any problem? It would be nice, but . . .

No Silver Bullet!

Search theory—the theory of optimal search—gives us an answer worth pondering. It was not the case that we would have to think of simultaneously searching for the solution to a problem and for the optimal way to search for a solution to that problem. We would just search for the solution, and solutions that worked in the past would enter folklore, databases, and learned journals. Now, with the proliferation of both memory storage and computational power, we can search for both the best solution and the best way to search for the best solution. That is what search theory is all about. David Wolpert, a NASA scientist, recently proved a result that should give pause to any fan of general-purpose silver bullets in problem solving. Using statistical signal processing techniques, he demonstrated there is no problem-solving procedure that beats any other problem-solving procedure on any problem, even if “better” is defined in the average sense. There is no silver bullet.3 And that means there is no free lunch either: a problem-solving procedure good enough to solve one tough problem optimally cannot generally be redeployed as is for any other problem.

Once we understand how the language we use shapes how we think, we see why groups of nonexperts or of heterogeneous experts who must develop a broader language just to be able to communicate see a larger solution search space. But these groups also succeed better because of the way they search that space. Intractable problems—the ones that exhaust the calculative abilities of a group searching in a linear, sequential fashion—are always better tackled by randomizing and parallelizing the search for solutions. By putting together a group of heterogeneous problem solvers, we take the first step to being able to randomize our search because each team member will likely proceed differently from the others. In addition, having many team members work on different parts of a problem at the same time can parallelize the search process.

If you are searching for a smart phone lost in a large conference facility, chances are that a combination of different search strategies by starting at different points (entrances, restrooms, presentation venues; searching sequentially by location type or searching in concentric circles around each location) will produce the solution (you are reunited with your smart phone) more quickly than would simply taking a single approach. And taking all of these approaches at the same time—sharing out among many searchers—cuts the time required to find the device.


We speak of problem-solving languages as insight generation engines through both precision and diversity. But what exactly is a problem-solving language, and how is it different from a framework?

We’ll start from a place we all understand: that of a framework. We all know of some: Five Forces, 7-S, VRIO. Frameworks are templates: they offer fill-in-the-blanks approaches to mapping what we see onto models that others have already built for us. Plug in the numbers, and the framework usually spits out some answer—for example: “Here is your most profitable product market [Five Forces].” “Here is your least imitable source of competitive advantage [VRIO].” Here is your salary competitiveness index in comparison to the rest of your industry [compensation design].”

It’s quick and easy but very limiting. The machinery of a framework is fixed, like hardware. There may be sound microeconomic thinking behind the Five Forces framework, for example, but it cannot be adapted to the situation at hand—for instance, examining interactions between the different value chains in an industry, predicting sources of disruptive scalable innovation, or optimizing the strategic planning process within the business at hand. Like the hardware of Apple laptops and iPads, you either use the hardware as is or you buy a new one: you cannot tinker with it. But tinker is what problem solvers to the world need to do to stay adaptive (and alive).

If a framework is a template, a problem-solving language is a lens. Languages can be adapted to a much broader array of problems. They adapt to the situation or challenge we face. The cost of this adaptability is that these languages require fast customization to the situation at hand. We need to translate our predicament into one of these languages: to map firms into agents, decisions, decision rights, incentives, payoffs, and strategies (rational choice theory and game theory), or to map groups of firms into ecologies evolving on the basis of mutation, selection and retention of ideas, technologies, design modules, and best practices (evolutionary theory); or to map teams of top managers into the nodes and edges of an evolving network whose structure is correlated with performance (network theory).

Like frameworks, problem-solving languages have limits: they cannot represent everything. In fact, no single language can even represent everything that can be represented. What can we do about that?

We do what Dunbar’s group of nonexperts did: replace one problem-solving language with two or more. Two is more than twice as valuable as one, and three are more than three times as valuable. Then we take a page from the logic of evolutionary mechanisms and engage in recombinant problem shaping. Thinking of an organization as a set of games played among self-interested strategic agents and as a network of relationships that embeds and constrains their actions helps us to focus on both the bargaining power of team members and on their affective, informational, and power relationships. Thinking of a consumer as an organism who has stimulus-triggered, experience-conditioned responses that are prone to marketing influences and as a decision agent capable of rational choices based on internal deliberation regarding costs and benefits focuses us on both the immediate and possibly subconscious causes of her behavior and on her conscious reasons for choosing our client’s product over that of the competition. Thinking of an assembly line as a computer carrying out a calculation that converges to an answer when the finished product leaves the assembly line with zero defects and as a networked group of workers whose productivity changes as a function of the pattern of information flow within their network along high-trust links and bridges focuses us on both the structure of the tasks that the line performs and on the relations among the humans performing those tasks. Thinking of an industry as a set of profit-maximizing agents (firms) that compete with one another on price and quality by making proactive and deliberate changes to their products, cost structures, pricing policy, quantity commitments, distribution networks, and marketing and R&D investments and as an ecology of organisms that compete for survival by making a myriad random, often unplanned point changes to their structure and function allows us to focus on both the strategic and operational choice and option set of a firm in that industry and on its unplanned and uncharted behavioral and structural blueprint, as sources of advantage.

A combination of problem-solving languages mimics the diversity of Dunbar’s nonexpert group. It replicates at the level of business problem-solving prowess the skill set of the Olympic dream team we had fantasized about assembling. Now all we have to do is to choose which problem-solving languages to master.

Crafting Internal Diversity

We are often not in a position to build a diverse team of problem solvers by accessing disparate pools of experts who must often be trained to collaborate with one another and overcome significant ego-related counterproductive ways of being before cooperatively producing insight. The alternative to sourcing native speakers of different problem-solving languages is to build our own internal collection of problem-solving languages, for any group of mentally agile people trained to use them can serve as a substitute for the wisdom and experience of a diverse experts in this case.

However, the world is full of languages. Which to choose, and why?

David Deutsch, a quantum theorist moonlighting as an epistemologist, gives us a useful hint. In The Fabric of Reality, he starts by bemoaning the loss of the Renaissance man—an Empedocles, a Leonardo, a Galileo, a Vico, a Goethe, a Hegel, a Leibniz, that is, a person who “understands everything”—in the age of hyperinformation, hypercomputation, and hyperspecialization.4 Folk wisdom has it that no one in this day and age can even hope for, let alone attain, an understanding of everything in the natural and social sciences. There are too many specialized terms of art, too much technical detail, too much know-how that a single mind would have to master to solve problems that may arise from any and all domains of human activity.

But Deutsch realizes that a global and transcendental understanding is possible: one can understand everything, if by “everything” we mean “everything that can be understood.” The key is to possess a special, core set of languages that are the modern equivalent of the philosopher’s stone, that is, the object that allows its beholder access to the darkest mysteries of the world. Deutsch’s candidates for this small set of languages are quantum mechanics, information theory, evolutionary theory, and the theory of computation. What they have in common is a curious property called logical depth: deep languages explain a lot with a little. They start from a small, sparse, widely applicable assumption base and produce explanations and predictions of massively complex phenomena—of giga-, tera-, or peta-bytes of data.

What more can you ask for? Master these languages, and you will have access to the treasure troves of knowledge and expertise that range from chemistry to botany, from aeronautical engineering to soil science, and from the design of new ontologies for database management to the implementation of expert systems for playing chess, Nintendo, or your favorite mind game. Master their vocabulary and syntax—the way you put their specialized terms together in meaningful sentences—and you will be able to “understand everything that can be understood”: there is no publication or research report or review article, no matter how complicated or esoteric, that you will not be able to decode and make sense of.

Why the Philosopher’s Stone Is Not Enough

“Not bad!” you might say. “Why not, then, just use these languages and be done with it? Why do we not just learn quantum mechanics, evolutionary theory, and information and computation theory, and dispense with the minutiae of our accumulated knowledge and expertise base in various industries and disciplines?”

There are two reasons. First, problem solving is not a spectator sport. Deutsch is on a quest to understand, not to predict, control, and interact with the object of his understanding. His languages, though useful, are passive. They are far more useful to the scientist-philosopher who, like the Renaissance scientist, is interested in observation and analysis than to the person of action. Second, language is a tool for doing, not just for seeing and saying. Deutsch’s languages live far away from practical reality, which is different from empirical reality because it confronts you with a problem to solve and a time frame to solve it within. You have to do a lot of work to generate useful predictions and explanations of any system you care about using information theory alone: conceptual work, computational work, experimental work, and so on. Deutsch’s languages are highly useful as decoders of the increasingly abstruse knowledge base of science because they are computationally very complex.

So Deutsch’s philosopher’s stone is not enough because we are not just philosophers! We cannot stop where Deutsch does because his languages are merely descriptive.

What We Need of Our Languages

We are after problem-solving languages that offer guidance for immediate action and let us build solution search spaces for business challenges as they happen. Here, then, is what the languages we’ll build require for them to be useful.


Languages can be used to quickly map the business predicaments we face into inputs (or independent variables), outputs (or dependent variables), and levers (or structural variables we can change in order to modify the outputs given a series of inputs). Take our decision agent language. It posits that incentives, decision rights, and levels of expertise and information are inputs that we can observe and measure, and levels of performance is an output that we can observe and measure. It also lets us play with the allocation of decision rights and incentives—the levers—in ways that are likely to produce changes in the desired levels of accountability (the outputs).

Our networks language does the same. It lets us map the patterns of relations among the members of a top management team (whether they be trust, information exchange, interactional ties, or something else) and attempt to change some of these relations (our levers for changing the topology of the network) in order to produce greater levels of team and individual accountability. These examples demonstrate the first requirement of a problem-solving language: it gives us observable, measurable, and controllable variables, along with a set of hypotheses that link the input to the output variables via levers we can access.


Our problem-solving languages must be applicable at many levels of analysis in a business. Each can be applied at the level of individuals, teams, firms, markets, institutions, and even societies and world systems taken as a whole. Once we understand the way the decision agent language works, we can speak of individuals, teams, and institutions as a whole as agents and examine their utilities and preferences, decision rights, beliefs, strategies, levels of specific knowledge, and incentives. This is an enormously important feature because it allows us to tailor and adapt our problem-solving language to a large number of different situations and predicaments without making radical changes to the syntax or semantics of the language in question. Due to the flexibility of our problem-solving languages, we call them flexons: flexible objects for generating of novel solutions.


A problem-solving language should capture a lot with a little. The explanatory engine of classical mechanics is sparse. Newton’s three laws of motion, the law of universal gravitation, and two conservation principles—for momentum and energy—form perhaps the densest explanatory core of all the sciences. As another example, the basic building blocks of evolutionary theory—selection, variation, retention—are all we need to describe industries as population ecologies of firms, which in turn are population ecologies of people, technologies, strategies, or any other entity striving to survive.


With these requirements in mind, we realized we needed to reach beyond the traditional disciplines of business. We scoured the modeling tool kits of both the social and natural sciences to distill out five problem-solving languages that fit them. They are:

1. The networks flexon, which uses nodes, ties that connect them, and the distribution and topology of these ties as a basic set of causally relevant variables

2. The decision agent flexon, which uses decision agents and their decision rights, incentives, beliefs, and knowledge states as a basic set of causally relevant variables

3. The system dynamics flexon, which uses causally linked variables, like matter or money that flow and can accumulate, and passive components, like resistors and capacitors, as a basic set of relevant variables

4. The evolutionary flexon, which uses parent offspring populations of entities that compete for survival, along with mechanisms of variation, selection, and retention as a basic set of relevant variables

5. The information processing flexon, which uses problem-solving agents (entities capable of storing and processing information) and the processes they use to solve problems as a basic set of causally relevant variables

The balance of this book is dedicated to showing how each these five flexons can be used to define and structure the challenges and predicaments the business world throws our way into well-defined problems we can solve in practice. What follows is a crash course in the use of these flexons to turn loosely structured business predicaments and situations into precisely articulated business problems. Its intended outcome is a brand-new skill that enables readers to picture the world in several different ways corresponding to different flexons and to switch between different pictures in order to engineer new insights that could not have been generated through the use of one problem-solving language alone.


For a panoptic view of explanatory and predictive models across scientific disciplines and branches of philosophy, see:

Deutsch, D. (1997). The Fabric of Reality. New York: Penguin.

For a model-centric exploration of the patterns and processes of what we call thought, see:

Hofstadter, D. O. (1978). Godel, Escher, Bach: An Eternal Golden Braid. New York: Basic Books.

Hofstadter, D. O. (1993). Fluid Concepts and Creative Analogies: Computer Models of the Fundamental Mechanisms of Thought. New York: Basic Books.

For an exposition of representational structures (models) used to structure perception and reasoning, see:

Johnson-Laird, P. M. (1991). Mental Models. Cambridge, MA: Harvard University Press.

For a view of problem-solving processes as algorithms and heuristics applied to well defined-problems across fields, see:

Michalewicz, Z., and D. B. Fogel. (1999). How to Solve It: Modern Heuristics. New York: Springer.

For an inquiry into successful patterns of thinking and behaving informed by algorithm and heuristic design and performance analysis, see:

Moldoveanu, M. C., and R. L. Martin. (2009). Diaminds: Decoding the Mental Habits of Successful Thinkers. Toronto: University of Toronto Press.


1. Kevin Dunbar, “How Scientists Build Models: In Vivo Science as a Window on the Scientific Mind,” in L. Magnani, N. Nersessian, and P. Thagard, eds., Model Based Reasoning in Scientific Discovery (New York: Plenum Press, 1999).

2. L. Hong and S. E. Page, “Problem Solving by Heterogeneous Agents¸” Journal of Economic Theory 97 (1): 123–63.

3. D. Wolpert, “No Free Lunch Theorems for Search,” NASA Ames Working Paper (1995).

4. D. Deutsch, The Fabric of Reality (New York: Penguin, 1997).