Richard Hawkes - Navigate the Swirl

The challenge of visualizing business processes has preoccupied some of the brightest minds over the past century, and you're probably familiar with concepts like value chains, value streams, Lean, Six Sigma, and so on. All these systems—which represented breakthroughs in management and organizational development—are approaches to mapping and optimizing business processes and workflows. However, many of them come out of a mechanistic, manufacturing mindset. They're top-down methods that a leader or consultant can apply to a system to reduce inefficiencies and increase throughput, but they're not really designed for a knowledge work environment in which team members need to be actively, ongoingly engaged in negotiating and optimizing their shared work. They describe a business workflow, but not the set of relationships and the nature of the relationships that have to be enacted for that workflow to happen smoothly. That's the question that preoccupied me, from my early days as a consultant. Even with my limited experience at that time, I could begin to see how the lack of shared clarity on what people were “in together” caused numerous problems. I was wrestling with this conundrum when I showed up for a consulting engagement one day—and stumbled upon an insight that would lead me to an answer so elegant that it became a staple of my own work and a foundational element of Growth River for well over a decade now. The story of how I came to it is worth sharing, since it highlights important distinctions. It all started out with the sides of a conference table.

I was working with a small business that day, trying to help them understand their workflow so they could get more clarity about who was doing what and how they needed to work together. After discussing their issues for much of the day, it occurred to me that it might help to give them a visual experience of their workflow. The first image that came to mind was the one right in front of me: the conference table. I went around the table and explained each person's respective place in the workflow, from developing their product to delivering it to the customer. The scientist was critical to developing the product but had little interaction with the customer; the salesperson was down the line a bit, ensuring that relationships with customers were value-based and effective; the operations person was further downstream; and on and on. I showed how their business flowed around the table, from role to role, through these various activities. Each was essential and each played a different part.

That session was helpful, and it inspired me to think more deeply about what it means to be in a business together. My conference table brainstorm helped to clarify some of the confusion about roles in the company and it set me on the path to capturing the ways of working that made up that dynamic business system. I asked myself: Is the flow I'm seeing specific to this company? Or is it something more universal? After all, every business had a product or service—be it software, hardware, clothing, food, energy, entertainment, education, and so on. They all have to develop , sell , and deliver that product or service. They each have to manage processes through those sets of activities to deliver value to the customer. And every business has support functions that make it all possible, such as accounting, IT, HR, and so on.

These activities each rely on human beings, of course, but they also include resources, processes, technologies, and so on, so I use the term capabilities to describe them, and I group capabilities into four types of business capabilities: Develop, Sell, Deliver, Support. A capability is a strategic factor critical to creating value in a business or for a customer. It can be almost any kind of key factor or point of leverage including an activity, a skill, an expertise, a resource, a process, a product, a way of working, or a type of culture. This distinguishes capabilities from roles , which are the groupings of responsibilities we assign to particular people in order to enact those capabilities.

Based on my initial insights, I started to create a simple model. On one side was Develop and Sell. On the other was Support and Deliver. The people on one side developed the products or services and sold them. The people on the other side delivered the products and provided customer support. It was basic, but it broke out the essential elements of the business in such a way that anyone could understand the workflow. I worked with this model for a time, and it was very helpful for a number of small businesses. It provided clarity about roles and gave leaders a workflow map that made it easier to diagnose bottlenecks, identify gaps, and untangle overlapping responsibilities. I also noticed something else: When I would speak about this model with leaders and team members, it got them focused on the business as a whole, visualizing it as a complex social system. It seemed to give them permission to work on the business together, not just in the business —to rise above the operational trees and see the forest, so to speak. So, I was pleased with the basic tool. Soon, however, I hit a wall—in the form of a large enterprise.

I was scheduled to give a presentation to the executive team of this company, a national clothing retailer, during which I planned to use my model. While preparing, however, I began to realize that the version I had been working with up until now was inadequate to represent their workflow. A large enterprise like this was a different beast compared to the small companies that I'd been applying this model with so far. In order to help them design a better system of roles that would eliminate many of the problems they were having in their operations, we needed to be able to effectively visualize their business as a system. And my model simply wasn't good enough. I was worried it would create more confusion than clarity. Sitting in my hotel room, the night before the session, I found myself undergoing a mild panic at the recognition that in a matter of hours, I'd be standing in a room full of executives with a blank slide unless I could figure out how to fix it.

I didn't give up. I considered the issues, examined their existing organizational structure, and compared it to the model I had developed. Eventually, late that night, I had a breakthrough. I needed to separate Develop and Sell as well as Support and Deliver. In fact, Develop, Sell, and Deliver each formed a discrete part of a workflow process. Further, there were feedback loops between Develop and Sell, Sell and Deliver, and Deliver and Develop. So was it a circle? No, because circles don't clearly distinguish one part from the other. It was more like a triangle, with three clearly differentiated but connected sides. I sketched out my makeshift triangle on a piece of paper and went to sleep.

In the morning, bleary-eyed and more than a little insecure about my nocturnal breakthrough, I presented the model to the CEO ( Figure 2.1). He glanced at it briefly, and then exclaimed, “That's exactly right! It describes us perfectly.” Later that day, I led a four-hour discussion using this newly created business triangle with the company's executive team. Since that day, my colleagues and I have used the Business Triangle hundreds if not thousands of times with countless companies. It's become one of the foundational pieces of the Growth River approach to unleashing transformation to grow and scale teams and companies.

FIGURE 2.1 The Four Business Capabilities Around the Business Triangle