ADDO 2019 Keynote Session: Crossing the River by Feeling the Stones

The path of knowing very little to eventually gaining understanding is a tough one, but luckily, we have a map for it. Here’s what one CEO’s path to understanding looked like:

An outline of Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

But of course, we need more detail! So first, let’s look at strategy.

Reading all the books on strategy doesn’t necessarily lead to understanding strategy. But the strategy cycle from Sun Tzu’s five factors, taken from his book The Art of War, identifies the following components.

• Purpose
• Landscape
• Climate
• Doctrine
• Leadership

But ultimately, we still need to understand the why. Without understanding why we move through these stages, we can’t create a valid strategy.

After understanding the cycle of strategy, we need to look at the map that gets us there. But what makes a map? With maps, space has meaning. And it can change the context of a graph by giving it a compass, or a direction that provides additional focus.

SWOT from Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

Here are some of the maps we have in business:

• Mind maps
• Business process maps
• System maps
• Etc.

And what do all these maps have in common? They’re imperfect. They’re representations of the real world but cannot provide strategy. They’re all just graphs. They lack direction or a compass. So what can we do instead?

Mapping a Business: Tea

Take, for example, selling a cup of tea. The cup of tea has needs—the tea leaves, a cup, and hot water. The kettle also has needs, like power and a tap. Once we have these anchors mapped out, we begin to develop a chain of needs.

Tea’s chain of needs from Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

So now that we have an example of what anchors and needs might look like, where do we go next? We’re missing additional information. Our maps should show movement, which we can describe as change itself

But how do we do that? Theoretically, it should be easy. Looking at the concepts described in the book Diffusion of Innovations by Everett Rogers makes it seem simple. Taking in innovation, product, and other components should result in showing the movement. But it’s not actually that simple. Things diffuse, but they also evolve

To illustrate this, let’s take a look at smartphone adoption over time. It would have been difficult to know when in the cycle the phone would become ubiquitous in the market.

Waves of smartphone adoption shown by a diffusion graph from Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

The point of stability marks where the product becomes ubiquitous in the market. This helps us understand movement.

Once we’ve defined movement, we can add that to the axis at the bottom.

Map of a business from Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

On a single map, we have a multitude of factors that affect your product. Here’s how that might look for our tea example.

Map with factors from Simon Wardley’s “Crossing the River by Feeling the Stones” presentation.

Mapping a Business: Insurance

Now, imagine that an insurance company had a problem. They had a bottleneck in providing their service to the customer. The solution they invested in and drove towards involved advanced robotics. That seems like a heavy-weight solution for an insurance company. Why was that the solution they drove towards?

The answer came out when they mapped their business. With the map, an interesting discovery surfaced. The need for robotics stemmed from not a need that the customer had. Instead, it came from the company’s decision to use custom-built racks. And because of these custom-built racks, their thought process led them down the path of working within that constraint. And robotics was the only visible solution. However, a solution of going to standard racks could improve their process flow and eliminate the need for continued customization.

Going to a standard offering instead of a custom-built one allowed them to find the right optimization. They were trying to optimize a flow that required highly technical solutions due to assumptions made long ago. And this was made clear by mapping it out on the bottleneck.

“Past Success Breeds Inertia”

Once we understand the landscape, we need to look for patterns. In other words, we need to identify the rules for the game.

Past success breeds inertia. Take Blockbuster vs. Netflix. Who had a website first? Blockbuster. First with video on the web? Blockbuster. First with streaming? Blockbuster. First to bankrupt? Blockbuster.

It wasn’t a lack of innovation that brought Blockbuster down. It was a business model focused on late fees. Netflix came in and changed the business model. They succeeded where Blockbuster couldn’t.

Let’s look at a different example. By taking a systems diagram and creating a map, the company Fotango developed the first serverless environment. Unfortunately, executives disagreed with the strategy and pushed the company in the direction of 3D TV. We can all now see that was a bad bet. Past success was their downfall.

Efficiency Lead to Innovation

Certain people will say that you need agile everywhere. Others say that it has its place. Where does agile map?

Going back to our example with the insurance company, building custom racks resulted in inefficient processes and bottlenecks.

Instead of customizing everything and building it ourselves, we should focus on what matters. So outsource utility to suppliers, use off-the-shelf products, and then build the components that have meaning in-house using agile methodologies.

Closing

As a final thought, let’s look at the current push to automate all the things. We use DevOps, agile, cloud technologies, Kubernetes, and everything else to improve the efficiency of our process. However, adding automation and DevOps to your processes can speed up segments of your process. But without mapping the entire problem, we’re solving the wrong problem

Don’t focus on optimizing the process flow. Instead, focus on evolving the process flow.

This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

Photo by Jeremy Cai