If you were to write down the three most innovative creations from your career or from your organization, what would they be, and when were they invented?

In the life cycle of an organization, once an innovative breakthrough is made and a system is developed, leaders of each individual part of the system are incented to optimize their individual parts. This is aligned with organizational structures as well as the educational system, and is an inheritance of the Industrial Revolution and mechanistic thinking. If an organization is a large machine, then the individual parts should be designed to run smoothly, improve incrementally, and reduce risk.

In 1951, a leader at Bell Labs called a meeting of departmental leaders and entered the room in a charged emotional state. He grimly announced that the telephone system of the United States had been destroyed the preceding night. The leaders were confused, as many had used the telephone that morning. He proceeded to restate that the telephone system had been destroyed and that anyone who did not believe so by noon that day would be terminated. He had their attention.

After a sufficient amount of pause and allowing the leaders to process his assertion and threat, he began to laugh and released the tension. By manner of explanation, he asked the room about the most meaningful contributions to the development of telephonic communications ever made by Bell Labs, which had recently been recognized in an article in Scientific American as the best group of industrially based laboratories in the world.

The answers were unanimous:

• The dial, which was introduced in the 1930s, but invented in the late 1800s.
• The ability to transmit multiple conversations simultaneously over one wire, which was introduced between the world wars, but invented in the late 1800s.
• The coaxial cable that connected the United States and Great Britain, which was built in 1882.

“Doesn't it strike you as odd,” he said, “that the three most important contributions this laboratory has ever made to telephonic communications were made before any of you were born? What in the world have you been doing?” he asked. “I'll tell you,” he said. “You have been improving the parts of the system taken separately, but you have not significantly improved the system as a whole.”

“The deficiency,” he said, “is not yours, but mine. We've had the wrong research and development strategy. We've been focusing on improving parts of the system rather than focusing on the system as a whole. […] We have to restart by focusing on designing the whole and then designing parts that fit it rather than vice versa. Therefore, we are going to begin by designing the system with which we would replace the existing system right now if we were free to replace it with whatever system we wanted.”

What ensued was an influx of inventions, including some well‐known inventions ubiquitous in the late twentieth century, such as the touch‐tone phone and caller identification.¹

Nearly every organizational leader with whom I have discussed innovation wants to be an innovative leader. When that leader stands before a whiteboard, however, it is extremely rare for a leader, steeped in their organizational, industrial, market, and societal context, to propose an idea that does not focus on an individual part of the system.

Ironically, the inability to think systemically is a systemic problem. In the majority of cases, incentives, training, and experiences have groomed leaders and managers to drive and report short, incremental improvements on the existing system.

I was once brought in to advise one of the top telecommunications companies on a challenge they were facing related to their technology strategy. Their business‐critical, monolithic applications were running on servers for which support was ending in approximately 10 months. Their strategy was focused on updating the applications as needed to migrate to the next set of on‐premise servers, and I was asked to weigh in on nuances regarding the technology and the viability of their strategy. From a systems perspective, they were hoping to replace a part and slightly improve the performance of the part without disrupting the system.

I asked if they had considered migrating to the cloud, and was informed that, although migrating to the cloud was their long‐term plan, it was not possible to rearchitect the monolithic applications into microservices, develop those microservices, and deploy to the cloud before support would end for the existing servers.

After some digging, it turned out that an offhand comment from one of the leaders of the initiative about how it would take too long to rearchitect the applications was the foundation for eliminating the consideration of migrating to the cloud, and no one had spoken with the development team.

I spoke with the development team, who had been hoping for the opportunity to eliminate technical debt by rearchitecting and rebuilding the applications, and they were confident it could be done. The team rallied, built momentum, generated their case, and presented to the executives, who accepted their proposal. Within the next 10 months, they achieved their goal and significantly improved the performance and capability of the system.

This is an example of the value that can be created when the orientation of investment and effort moves away from solving problems and toward designing and building an envisioned future.

Problem Solving versus Future Solving

The rhetoric of problem solving is pervasive in contemporary discourse. Leaders across sectors, ironically, in trying to solve the problem of leading with technology instead of outcomes, are quoted in books and articles, refocusing the conversation on “what problems need to be solved.”

In an interview for this book, an esteemed academic leader told me that “the largest gap is connecting a problem a company wants to solve with the technology that's available.”

But the problem with solving problems is that solving a problem is inherently directed at that which you do not want, not at what you do want.

As demonstrated in Figure 6.1, the problem‐solving process begins at the starting point with the question: “What problems do we need to solve?”

The answer to that question is infinity. Organizations face an infinite number of problems at any given moment. The first step of narrowing the infinite number of problems is often to list the most top‐of‐mind problems, then socialize the list with others in the organization. Once the list has made a couple of revisionary rounds, an algebraic formula for determining which problem(s) to start with is developed. An example of this would be the projected benefit of solving the problem, paired with the cost of implementation and length of time. A subset of problems are chosen, and the solving process begins.

During this process, the organization is backing into the future, as it is not aimed at a specific future. The organization is instead aimed at each problem that is closest to it and the most painful at any given time.

If I asked you to get into a time machine and go into a future scenario with me, would it matter which coordinates were programmed into the machine?

Future solving presents a new encapsulation of preexisting but underutilized methods, distinct from problem solving, by which organizational leaders and managers can advance into the future with clarity of direction.

The first question posed in future solving is “What ought to be?”

The second question, looking backwards from the envisioned future point to the starting point, is “What would have to be true to reach this future?”

This is a much simpler process, as it reduces the number of possibilities from infinite to one. The question of what would have to be true to reach this future can be recursively asked, building a path backwards until there is a clear path from the starting point to the envisioned future point, which could consist of a string of digital and autonomous reformation and transformation initiatives together with acts of creation.

When I first met with a contracts team at one of the top technology companies in the world, they had undergone a series of problem‐solving steps, and had arrived at an undesirable future.

Their process began with the need to determine how to handle digital contracts signed through an electronic signing services platform since their process was based on written contracts. They resolved this problem by creating a shared email inbox to which all the emails from the electronic signing services platform would be directed. The next problem was to create and maintain a list of all of the existing contracts, which used to be manually entered into a spreadsheet when signed contracts arrived in the mail. They had resolved this through developing a process by which various team members would monitor, flag, and check off emails as they typed the contract information into a shared spreadsheet and saved the attached document into a shared folder.

The next problem presented to the team was the need to analyze the information in the spreadsheet and create graphs without risking any data integrity issues or loss. They resolved this by copy‐pasting the data for the relevant time period (based on regular reports and point‐in‐time stakeholder requests) into a different spreadsheet that was preloaded with a variety of formulas to accelerate the analytical process.

The next problem was presentation, as their leadership was not interested in screenshots from the spreadsheet or in opening an attached spreadsheet, so they created a Word document template into which they would copy‐paste the graphs and export to a PDF file. They then attached this file to an email template, updated the template, and hit send.

The final problems they faced, which led to calling my team in to help, was how slowly the spreadsheet software ran due to the number of rows and columns, as well as the risk of anything happening to the data.

For context, the market capitalization of this technology organization was over $400 billion at this time. They had the technological prowess and the resources to create a better solution, but the process by which they solved individual problems in succession led to a highly inefficient, risky position.

The question posed to me and my team was if we could improve the performance of the spreadsheet despite the large amounts of data; that is, “This problem needs to be solved.”

Bear in mind that these were remarkably intelligent business leaders and managers at one of the most successful organizations in the world, following the prevailing management philosophy of doing the work that needs to be done with a bias for action and for solving problems as they present themselves to achieve efficiencies.

The process we followed as we scoped a potential partnership and engagement began with the question of what would have to be true for this process to be equally or more dependable without any step of the process requiring manual intervention.

For that to be true, there would need to be a way to either scrape the attachments of the emails as they came in to extract the necessary data, or the electronic signing services platform would need to have a means of sending us data each time a contract was fully executed alongside the email. Fortunately, they had the capability to do precisely that (through their Application Programming Interface or API)—send the data and the PDF that could be handled programmatically (i.e., by our software application)—and we were able to automate the first step of the team's process by building that integration, creating a database in which to store the data, and a folder in which to store the files.

For each subsequent step, we asked what would have to be true in order for no manual intervention to be required, and the final product was a software application that interacted directly with the electronic signing services platform and other internal systems, automatically generated the graphs the team used to create in a spreadsheet, with the addition of new graphs and a series of filters, which meant that the team no longer needed to create the regularly scheduled reports, most of the point‐in‐time reports could be self‐serve directly in the tool, and the data could be exported for further analysis when needed.

This paved the way for improving this team's performance in its core function as well as transforming its interaction with other teams that relied on their information and their ability to advise on, build, and execute contracts.

Had we begun with the problem statement presented to us, we might have built a new spreadsheet software capable of processing more rows or proposed that they migrate to a different platform that would serve the same function within their process without reimagining their process.

The Use Case Problem

The field of agriculture is an exciting frontier for the application of technology. The developments in intelligence that can be distributed to edge systems enable solutions that can span the acreage of a farm or a collection of farms at a cost‐effective price point.

Agricultural science (or agriscience) organizations have invested heavily in technologies such as remote sensing, the analysis of satellite imagery, developing drones, machine learning, and robotics. A notable example of the subsequent advancement of scientific research through technology is the ability to correctly identify leaf damage from a fungal pathogen from drone imagery.

The typical path to determine investment across industries, not just agriscience, is to build a business case around a collection of use cases, or problems, that the proposed development would solve. The field of agriscience is no exception, and there is a long list of use cases where technology could be applied to assist farmers.

A use case, however, is inherently focused on the proposed development, as opposed to the betterment of the system into which it is implemented. The words themselves reveal this orientation: use case, or, flipped around, a case in which something could be used. The investment is thus focused on how something could be used, and a problem it could solve, as opposed to the betterment of the system in which it is implemented.

In the case of agricultural science, examining the application of machine learning to drone imagery through the lens of use cases, the value is inarguable. Through the lens of farmers in the United States, however, the average age of whom is over 60 and whose family has been farming their land for generations, a machine could never know the land better than they do. The investment and effort of researchers has solved a problem that no one was asking to be solved.

Whether or not machine learning can be applied to do something interesting has little to do with the future of an industry. Synthesis (which we will dive into more deeply later in this book) pivots the focus to the role or function that agriculture serves within its containing system (society): feeding the world.

To have a conversation with a farmer about feeding the world within the context of two of their larger systems, society and the earth itself and the changing climate conditions due to climate change, labor shortages now that the Internet has provided paths to digital jobs and there is a declining interest in farming, or the ever‐growing global population, placing pressure for more food despite fewer farmers, one can lay the foundation for a discussion about the future of agriculture in which farmers would participate. Once the vision for the future of agriculture has been created, that vision can be disaggregated to understand the participation of individual farmers, agriscience companies, equipment manufacturers—the whole ecosystem that supports farming. In this context, investment in technologies would be focused on creating or improving parts of the broader system (agricultural) that the whole system has identified will be needed to improve the performance of the whole system at its function as a part of a broader system (feeding the world).

In this pivot, sales conversations no longer begin with the question of why a given development would be valuable, because its role in the future of that industry has already been defined, and it instead becomes a question of how well the development performs its function, at what price point, its ethical implications, and its ease of adoption.

The Second Use Case Problem: Use Case Battleship

Technologists reading this might have the question or thought about clients who ask for use cases, which is common in many industries as a lens through which new technologies can be easily examined.

When technologists approach business and industry leaders and managers, the application of technology is often framed within problems and use cases. There is considerable investment taking place at forward‐thinking technology companies to pivot from product‐based sales to outcome‐based sales. This is an important evolution of the sales methodology to pivot salespersons from focusing on the applicability of their products to the necessary client impact, from which a line can (or cannot) be traced back to the products the salesperson is able to offer.

But this is still not enough if the organizational leader is focused on solving the next problem without designing to improve the whole system to which their organization contributes. If an organizational leader wants to improve efficiencies by a given percentage to counteract the ongoing decline of product sales, the resolution may actually be found in altering the product to increase sales or in improving customer experience to increase retention. It is the responsibility of organizational leaders to realize when they are caught in the problem‐solving loop and pause to reassess strategy. In the absence of an organizational leadership capability to pause and reassess, the responsibility falls to their team and advisors to have the insight to identify this phenomenon and the bravery or vulnerability to raise it to their leaders.

When clients request use cases examples, sometimes the intent is to illuminate the capability of a technology, which can lead to a discussion about its ability to solve a different use case. Other times, they are playing “Use Case Battleship.” Battleship is a two‐player board game in which the players can only see their own set of ships and submarines on an algebraic grid. They take turns calling “shots” into the other player's side of the board by naming algebraic squares. The other player then notifies them whether the shot is a hit or a miss.

Some clients wait for technology providers to name the right square on their invisible grid and, in its worst form, accumulate collections of point solutions solving individual use cases from different vendors, creating a bloated and disconnected overarching system that performs the same or worse than it would without those solutions.

This has become one of the largest challenges facing the modern organization.

If the concept of a human did not exist, and those tasked with creating a human first solved the problem of movement, then the problem of reproduction, and then of generating energy, the resulting system would be unrecognizable. Taken a step further, if the human body were a technological entity, and the development of each function of the human body were assigned to different technology providers on different technology stacks, there would be a high likelihood that many of the parts of the human body would not interact with one another.

Doing the Wrong Thing Right

Packing into a car with family or friends for a leisurely road trip across a country or continent is an exciting prospect. Innately, road trips include a balance of planning and spontaneity. Even the most thought‐through plan can be thwarted by weather conditions, road closures, or spotting an unanticipated landmark and stopping along the way.

Some road trips swing in the opposite direction and intentionally begin without a plan, embracing spontaneity and approaching each leg of the trip as an adventure.

An organizational initiative shares many similarities with a road trip. Someone has to drive, the vehicle can only go so far without further investment, everyone must agree to go to the same place, and the best‐laid plan will inevitably meet surprises, often requiring a reevaluation of the plan.

One of the challenges faced by organizations today occurs when organizational leaders state where they want to go at the onset of a new trip, but before programming the GPS with the destination to generate a route, they create a list of problems that need to be solved: fill up the car with gas (or charge it), use the restroom, get snacks, get coffee, stop to stretch legs, stop for lunch—many hours can pass by, routing at each point toward the next problem to be solved, but without connection to the long‐term destination or strategy, valuable time and energy has been wasted. If challenged on this approach, the leader might reply that each of those stops is a necessary part of a road trip, and they would be right. Every road trip includes stopping for food, gas, and snacks, but if those take place outside the context of the broader route, a trip that should take two days could take weeks, or worse—and, more often than not when it comes to technology initiatives, never arrive at the destination.

There are many reasons this could be the case, such as the innate desire to check items off a checklist or the organizational need to demonstrate progress each quarter.

But demonstrating progress toward the wrong goal or outside the context of a long‐term strategy is counterproductive, or, as the late Dr. Russell Ackoff, a former Wharton professor and organizational theorist, said, “The righter we do the wrong thing, the wronger we become. When we make a mistake doing the wrong thing and correct it, we become wronger. When we make a mistake doing the right thing and correct it, we become righter. Therefore, it is better to do the right thing wrong than the wrong thing right.”²

Organizations have a natural aptitude for correcting mistakes without examining whether that process is doing the right or wrong thing for the organization in the long term.

If a process is found to have an inefficiency, and an analysis demonstrates that the process can be streamlined to improve efficiency by 2% by the end of the quarter with a reasonable investment of capital and resources, it becomes an obvious choice for a leader. Teams or consultants will be assigned to search for similar problems to be solved. If the work is performed well, the leader can submit a report that includes the percentage of increased efficiency produced by their team's work, the cost reduction, or the increased profit. This becomes a positive performance review, justifying bonuses and increased budgetary allocation to that leader's organization.

Many leaders have risen through organizations by creating a demonstrable record of solving problems.

This becomes a vicious cycle and can lead to narrowing the aperture for organizational investment of time and resources to solving problems with a preference for the problems that will demonstrate the best numbers within a quarter or fiscal year as opposed to whether or not they are contributing to the performance of the overarching organization or should be scrapped or redesigned altogether, which would likely not yield demonstrable efficiency gains within a given quarter or fiscal year.

The pursuit of short‐term, demonstrable results is taught in school and reinforced by current economic incentives within organizations because most leaders and managers must answer for the demonstrable, measurable results achieved by their team or organization in quarterly reviews and at the end of each fiscal year.

This systemic context is one of the primary reasons technology initiatives fail and organizations and society face unrealized economic potential.