The More Process You Have, The Less Process You Need

I’ve written a lot about process. In fact, it can be argued that I’ve written a disturbingly great deal about process.

Much of my writing—particularly of late—has been centred around the principle that the right process is a product of the situation we are in, the problem we are trying to solve and the environment we are trying to solve it in. In other words, process design is situational. The right answer depends.

And I’ve also been quick to write about the fact that if the right answer is “it depends,” then the real question is, “Just what does it depend on?”

There is a slightly different perspective about process that we also need to think about. It’s a little more abstract, and as a result it’s easy to overlook. But calling it out can arrive at some important and critical realizations. It also offers some essential insights into the role that process should have in our lives.

Process feels formal. Partly, that’s the way it is defined. More significantly, it’s in the way that process is explained and taught. We make it specific, concrete and precise. We draw boxes. We apply labels. We give those labels specific meaning and nuance.

From there, we connect the boxes. We draw lines. We make arrows. We prescribe sequence. In essence, we identify a pattern that says, “Start here. Do these things in order. Finish here.” The presumption is that if we do all of those things, we’ll be successful. We will have produced our desired result. And when we want that result again, we’ll reapply this sequence.

The challenge is that process doesn’t really work this way. At least, not most process. Not the processes that we care about. In very simple circumstances, we can manage in this manner. The kind of process that involves, for example, assembling an Ikea bookshelf. And even then, I know more than my fair share of people that shudder in horror at the concept of every building another Billy. Once we get a bit more complex than that, however, process loses its rigidity.

Let’s take cooking as an example. A recipe is, in theory, a process. It identifies the ingredients. It provides a sequence of steps. We can theoretically follow it to produce a meal. At the same time, that recipe presumes the understanding of some fundamental cooking principles. “Sauté for 10 minutes in a medium-sized skillet over medium heat until well caramelized” is, in the context of cooking, a relatively innocuous instruction. It’s a statement that hides a host of hidden complexities.

Let’s unpack those, shall we? For starters, it assumes we know the meaning of the words “sauté,” “skillet,” and “caramelized.” It presumes that we know how to translate “medium” to both skillet size and relative heat. It equally infers a way to resolve the tension between 10 minutes of time and testing the caramelization of whatever it is that we are actually sautéeing. And it makes the brazen assumption that we can differentiate with sufficient meaning “well caramelized” from the not-too-much-later state of “burnt.” And this in no way gets into the far-too-complex differentiation of interpreting medium heat as indicated on the knob from the heat actually transmitted to the skillet.

If we don’t know all of these things, our recipe is doomed. As is our dinner. And as a fall back, we better know how to call out for pizza. True story: when I was a small child on his first camping trip, I was assigned the theoretically simple task of “peeling the onions.” Removing a layer revealed that there was another layer underneath. And another. And another. What was not clear to me was how many layers were present, or when the onions could appropriately be considered “peeled.” That left me to present several very tiny onion hearts as a result, leaving a much larger pile of onion layers on the ground at my feet.

If that’s the trouble that we can get to on a simple task, just imagine the challenges that emerge when tackling something as complex as, for example, managing a project. And that’s why we reduce things to boxes, lines, labels and arrows. We are trying to simplify something that is inherently complex, in order to make it comprehensible. The implicit assumption is that, once understood, we’ll ramp the complexity back up and accept some blurring and fuzziness on the process, its steps, its presumed linearity and the presumption that we can start in one place and reliably and predictably navigate to a pre-defined finish.

The challenge is that we don’t actually do that. At least, a great many of us don’t. We learn a process as process, and presume that’s all there is to know. We don’t want nuance, and we don’t want complexity. We want a recipe that we can follow that will dependably and consistently produce a flavourful meal. And, to the concern and disappointment of many, life simply doesn’t work that way.

Push through to the other side, though, and an interesting thing happens. That other side isn’t mastery of one process, however, it’s familiarity with many. It’s the result of following not one path, but several. It’s the result of not repeatedly doing the same thing over and over again, hoping for a solid result, but experimenting and adapting. It’s the result of having many options available, and being able to make a selection in the moment of the appropriate one to follow.

In other words, the more process we have, the less process we need. Or, to phrase it somewhat differently, the more process options we have, the less dependent and reliant we are on one specific process to get to the finish line. We stop using process as a crutch. We don’t even necessarily rely on it as a guide. It’s more there as a fallback reminder of choices made and options taken.

As an example, a couple of weeks ago I found myself in Salem, Oregon, delivering a keynote presentation. I’m thankful and delighted that the presentation was well received. The highlight of the day for me, though, was something that happened over lunch.

In addition to being the morning keynote, I was invited to facilitate a formal networking session over the lunch hour. An important fact associated with this story: I loathe the concept of “networking,” and the presence of any formal “networking” event on a conference calendar is most likely guaranteed to find me in another location.

Given that I was asked to facilitate such a session, however, I was determined to build a networking event that I would actually want to participate in. So again, we need to do some unpacking. What I don’t like about networking is the forced meeting and exchanging contact information with random strangers whose interests I don’t know and whose relevance to my world is unclear. What I do love, by contrast, is meeting new people who are interested in things that are similar to what I’m interested in, and who can offer new and stimulating insights, observations and perspectives. Yes, I appreciate there is some dichotomy there. They’re my biases, so you’re going to simply have to cope.

The inherent challenge implicit resolving this problem is the answer to the question, “How do you find people that are interested in having a conversation about something you’re wanting to have a discussion about?” My answer to this was that if you want to find people of a like-minded interest, you need to promote the interest that you want to explore.

And so, pretty much on the fly in a conference call with the conference organizers, I proposed a process that looked a little like this: We’ll build a map of the room where we’re having lunch. That map will be posted in a conspicuous place through the morning. In my keynote, and through the session organizers, we’ll invite people to take the lead in identifying a topic related to the conference them that they want to discuss. They’ll pick an empty table, declare their topic, and be responsible for kicking off the discussion about that topic. Whatever happens after that will be up to each table.

A few days before the event, I was having lunch with a friend and colleague that I’ve known for years. I described what I was doing. What I started with was, “Like many others, some of the most interesting parts of conferences for me are the coffee breaks.” He gave me a knowing grin, and responded, “You’re doing Open Space.”

And I was. But I also wasn’t. For those not familiar with the term, Open Space Technology is a facilitation technique developed by Harrison Owen. The entire premise of Open Space was the idea that coffee breaks are the most stimulating and productive parts of formal meetings, in large part because people talk about the things that matter to them. What emerged was a participant-driven technique built around the expression of interests, self-facilitation of small group discussions and techniques to share what happens in smaller groups with the everyone else.

There is a process of Open Space. There are principles that define its use, and processes and activities that govern its adoption. There are, inevitably, those who will be horrified by my simplistic adaptation, because what I was doing wasn’t “real Open Space.” What I was doing instead was devising an approach that would work under the circumstances with the people in the room that would create a meaningful experience for the conference I was participating with.

In other words, I borrowed from process. I didn’t follow process. If challenged, I could cite and reference the processes that I’m drawing from. I could explain the choices I made and the adaptations that I adopted. I could rationalize why I approached the session in the manner that I did. I have no interest in doing so. More importantly, doing so would be an after-the-fact rationalization of choices that I’m not particularly conscious of making.

I know Open Space Technology in much the same way that I know a number of other facilitation techniques, approaches and philosophies. At this point in my career, I doubt that I’ve followed any of them formally in many, many years. Decades, in point of fact. There might have been a time when I did adhere more closely to the process as described or prescribed, but I would be hard pressed to cite circumstances, places or dates. That’s not how I work.

That’s been an important realization for me. While the right process depends, at this point I rarely go back to process as it is formally defined when designing an approach. That’s true of much of the work that I do, whether I’m helping to solve a strategic problem, develop a strategic plan, manage an organizational change or figure out how to manage a complex and messy project. There’s process behind pretty much everything I do, but I don’t lead with process. Moreover, I don’t follow process. I leverage the process that works that gets me to the solutions that I need.

To me, that’s where we need to take our understanding of process, and in particular where we need to encourage our adoption of process. It’s not about establishing rules or prescribing steps, and it’s certainly not about enforcing rules or punishing those who don’t adhere. It’s about figuring out what works in a particular circumstance, given the situation we are in and the outcome we are trying to attain. The more options we have, and the more fluidly we can draw on different options, the more effective we will ultimately be.