Consultant, heal thyself

Earlier this month I facilitated a meeting for a group of physicians who are members of a state medical society. The Governor of the state established a consortium for the prevention of prescription drug abuse in response to the national opioid crisis. The consortium in turn, reached out to the medical society to convene members for the purpose of establishing protocols, exchanging best practices, and aligning on a point-of-view to share with legislators that would ensure meaningful regulation.

My blood pressure goes up when I’m in a room with one doctor, so you can imagine how I felt about facilitating a meeting with 20 doctors. Nevertheless, I had agreed to help them tackle an important topic. We needed to make the most of a day-long meeting of professionals volunteering their valuable time. The expertise in the room wasn’t going to do anyone any good without a process that ensured shared understanding and produced actionable alignment.

Working with problem-solving groups is itself an exercise in problem solving.

Smart, highly skilled people who generally solve problems by themselves don’t automatically adapt to the challenges of collaboration. One of the challenges of collaborating during a problem solving exercise is slowing the group down enough to confirm that they agree on the problem before they start generating solutions. Doctors in particular, think fast and have been trained in a diagnostic methodology; they move from symptoms to causes and then prescribe or operate.

A challenge like the opioid crisis doesn’t present itself in the way a patient might show up with symptoms. A public health emergency is not just a more complicated set of symptoms requiring a differential diagnosis. Complex social problems can’t be outsmarted. Chasing down causes might help us feel more in control, but the causes are not static conditions waiting to be discovered. Asking what’s causing the opioid crisis is like asking what causes religion (no Marxist pun intended).

Upon reflection, I’ve come to realize that a tension between competing research methodologies hid below the surface of our work together that day. The doctors had been trained as scientists. Science presumes that objective observation and analysis can lead to universal causal laws. I had suggested a collaborative process based on a social theory approach called, participatory action research. Participatory action research presumes a dynamic relationship between understanding something and changing it. By contrast, science presumes we need to understand something before we try to change it.

While we made respectable progress and agreed to a few clear action steps, I am only now coming to realize the mistake I made in designing a process for the meeting. Because of my anxiety about showing up as an authority, I inadvertently acted like a doctor. I treated the group as a patient. I diagnosed their group dynamics and prescribed process fixes. Alternatively, I could have recognized that together we represented our own complex social network. I might have been more open to the way our challenges and shared understanding emerged through our dialogue. Had I been more attentive to and less judgmental about the group’s natural tendencies, we may have made even more progress.

Recalculating: When is responding to change better than following a plan?

At some level I understand that the artificial intelligence behind the voice of my navigation app is not judging me when I make a wrong turn. Still, I can’t help sensing a tinge of disappointment behind the announcement that my route is being “recalculated.” Why not just provide the re-routed directions? Better yet, let’s program the navigation system to compliment me for making a bold move: “Interesting choice. Now, continue straight for 1000 feet and make a U-turn.”

Speaking of programming, some of you may recognize the reference in the subtitle of this blog to the Agile Software Development Manifesto. The manifesto was written and signed in 2001 when a group of software developers met in Snowbird, Utah. The document codified values and principles representing a methodological shift in how software developers meet client requirements. Caroline Mimbs Nyce provides an engaging history of the agile software development movement in her 2017 article for The Atlantic, “The Winter Getaway that Turned the Software World Upside Down.”

The manifesto includes four value preferences. The fourth value preference reads, “…We have come to value responding to change over following a plan.” The manifesto does not oppose “following a plan.” The idea is that adopting a preference for “responding to change” will provide a more efficient, more targeted solution to the customer or end-user.

Recently, organizational leaders have taken note of the “Agile” philosophy. The idea of self-managed teams working cross-functionally and collaborating with customers seems like an approach the entire organization should embrace. Agile software development emerged as a response to “Waterfall” software development. The waterfall model is linear and sequential. The waterfall model favors analysis, documentation and design over end-user testing and iterating. The organizational equivalent of waterfall software development is “command and control” management.

Given the current volatility and uncertainty of our business environment, should organizations transition away from a “waterfall” leadership style to an “agile” leadership style?

I recently had the pleasure of partnering on a leadership development program with Bjorn Bihhardt, Owner and CEO of Abilitie. Bjorn introduced me to the Cynefin framework* for making sense of the contexts within which leaders solve problems and make decisions. David J. Snowden, the founder and chief scientific officer of Cognitive Edge developed the framework with input from a number of his colleagues. In November of 2007, Snowden and Mary E. Boone, President of Boone Associates co-wrote a Harvard Business Review (HBR) article about the framework.

The Cynefin Framework

CynefinThe right-hand side of the framework describes contexts that are either “simple” or “complicated.” In both cases, cause-and-effect relationships exist. In simple contexts, cause and effect are apparent to everyone. In complicated contexts, there may be more than one right answer and it requires expertise to analyze the situation and determine an appropriate response. A simple business problem is collecting a late payment from a customer. A complicated business problem is improving the company’s cash flow.

The left-hand side of the framework describes contexts that are either “complex” or “chaotic.” In a complex context, no amount of expert analysis will result in a single solution or right answer. In their HBR article, Snowden and Boone write that a complicated context differs from a complex context in the same way a Ferrari differs from the Brazilian rainforest. The car is complicated, but static. An expert can take it apart and put it back together. The rainforest, on the other hand is in a constant state of unpredictable flux. Instead of conducting expert analysis, decision makers in a complex context must investigate, sense and then respond.

In a chaotic context, there is only turbulence and ambiguity (e.g. conditions in the midst of the events of September 11, 2001). Attempting to make sense of conditions before responding does not help. In a chaotic context, one must simply act and learn from how the environment reacts to what you do. The fifth element of the framework is represented by the open space at the intersection of the other four contexts. Snowden calls the fifth context, “disorder.” Disorder applies when one cannot discern which of the other four contexts pertain.

I mention the Cynefin framework because it seems to me that following a plan works when contexts are either simple or complicated. In both cases, expertise can determine a workable solution, routines and authority can ensure people implement the solution. When things become complex, responding to change with agility will be more useful. When things become chaotic, just do something.

The question then is not whether today’s leaders should adopt a waterfall style or an agile style. The question becomes, how do we know which context we should apply when framing our situation? In other words, when should we follow the plan our navigation software put us on and when should we turn off the app and respond to the changes we are sensing?

* Cynefin (ku-nev-in) is Welsh for habitat. It carries the connotation of factors that influence us in ways we can’t understand.