Is Your Problem Technical or Adaptive?

Back in the early 1990s I was an avid skier, putting in 40+ days on the slopes every season. I was part of a group that did days in local (to Seattle) ski areas; annual trips to Whistler, BC (my favorite place); Mount Hood and Mount Bachelor in Oregon; and a semi-fateful trip to Red Mountain in Trail, British Columbia in March of 1993. Red Mountain is known for its challenging terrain.

March 13, 1993: Mark and the Red Mountain ski patrol

I was a pretty good skier, though not an expert. There were places where I would be in over my head. And I followed some expert skier friends into one of those places. To cut to the chase, I ended up learning how to spell “anterior cruciate ligament” and later on how to spell “arthroscope.”

My torn ACL was a technical problem, but not one I was (or am) qualified to fix. I outsourced the solution to a technical expert – an orthopedic surgeon and his team. They did a great job. Today that knee is better than the original equipment.

But the surgical, technical repair did not address the root cause of the problem. I could not outsource that. The work was mine, and mine alone, to do. Dealing with the root cause required me to change my own behavior. I had a few choices:

  • I could give up skiing entirely. Nope, too much fun.
  • I could take fewer risks, though that would mean plateauing my own learning.
  • I could work deliberately* to become a better skier so I can take on more challenging terrain with reduced risk of serious injury.**

No matter which of those courses of action I chose, they are not things I can assign to someone else to do for me. I have to do the work myself. Solving the problem requires a change in my own behavior.

I believe it was Ron Heifetz at Harvard who coined the term “adaptive leadership” to describe leading for behavior changes vs. simply guiding technical solutions. If you are a change agent, you are (or need to be) engaging in adaptive leadership.

In the context of continuous improvement, we are talking about the culture change that has to accompany any technical implementations if they are to stick for more than a few months.

Trying Technical Solutions on Adaptive Problems

An organization had a culture of working around their ERP / MRP system. If production fell behind, they extended lead times in the system (which is the worst thing you can do in this case). They would schedule “hot” orders in the past to force them to the top of the queue, driving material shortages for later orders – repeating the cycle.

They all believed that the computer system itself wasn’t up to the task of managing their “complex requirements.” (Which actually weren’t that complex at all – everyone seems to think their production portfolio is more complicated than everyone else’s.)

The new system, though, would fix all of this.

When the new system went into place, though, things got worse. Much worse. They doubled down on the same things they had done in the past, which made things worse again.

This wasn’t a problem with the computer systems. It was a problem with the way the team members worked together, a problem with their understanding of how their computer systems responded to their manipulations. It was a problem that no changes to the I.T. systems could solve.

Not surprisingly the same organization had tried kanban in the past. And not surprisingly they had worked around the system to “solve” perceived problems, and not surprisingly they had blamed the system for the failures.

It would not matter what technical system they had, their results would ultimately be shortages, expediting, scrambling to rush late shipments out the door. It was not the technical systems that produced those results, it was their behavior.

What Kind of Change Do You Have to Make?

This is adapted from material published by the Kansas Leadership Center, see more below under Further Information and Reading. The expansion, examples and explanations are my interpretation.

What kind of problem are you facing?

Is the problem clearly defined (like my torn ACL)? Or do you have to begin work to learn what actual problem(s) you are facing? If the later, you are dealing with adaptive, culture change work.

What kind of solution can be applied?

If there is a clear solution, or one can be researched, then you are dealing with a technical problem. But if the solution must be learned, then more likely it is adaptive. One key indicator – if you have put in a technical solution (like “standard work” or “5S” for example), but then seen it erode, then you are probably in adaptive territory. You have to learn what unseen factors are driving how people respond.

What kind of work is involved to apply the solution?

If you can just implement, like buying or upgrading a machine, then you are in technical territory. But if you have to diagnose, experiment, learn about things like the organizational dynamics then you are dealing with people’s behavior – an adaptive problem. Like above, I have seen many cases where a technical solution was implemented only to have that surface all kinds of adaptive and leadership issues. A new ERP system is a prime example. The software is the easy part. Beware of someone selling a “solution” by the way.

Whose Work Is It?

Even though this is a header, I bolded it, because this is The Critical Question. If technical experts or authority can just tell you what to do, then it is a technical problem.

But most meaningful change requires the stakeholders – the people responsible for the system and the results – to actually do the work themselves. This is the difference between fixing my torn ACL and the work I had to do.

In other words, if you put in “lean tools” (or complete a “black belt project”) only to see the results quickly eroding, then the technical tools, no matter how well you see them work elsewhere, are not going to help you. The organizations where you see them working have fundamentally different systems of leadership, and that is where the change must occur of the tools are going to work as promised.

What Timeline Should You Expect?

Technical solutions can be put in quickly. Anyone who has been though a classic “kaizen event” knows this. But changing people’s default thinking and behavior takes time because it takes practice and correction. And the default thinking and behavior is what created the technical systems you are trying to adjust. Eventually your kaizen blitz rocket runs out of fuel, and things fall back to Earth because gravity pulls them there.

What Are Your Expectations?

This is a tricky one. The whole reason to do any of this is to change results, change outcomes in some way. Technical solutions can do that pretty directly.

But when you are in adaptive territory, learning you way in, then you need to celebrate making progress and learn to trust the process – the results will come. Impatience does not serve us here.

Required Mindset

For technical solutions, skill and confidence are enough. You can hire someone with that. But if you are seeking to make real, meaningful change then you are better served with curiosity.

Further Information and Reading

If you want to learn more about Adaptive Leadership, here are some sources you can start with. Of course you can also leave a comment or click on “Contact Mark” in the right sidebar and ask me if any of this is interesting to you.

(Books are Amazon affiliate links, I get a small kickback at no cost to you if you buy through them.)

Best starter book: Your Leadership Edge by Ed O’Malley. This is also the text for a course by the same name taught by the Kansas Leadership Center.

Teaching Leadership by Chris Green and Julia Fabris McBride, who are also affiliated with the KLC, is more technical and more advanced. It is targeted more at people who understand the basics, and have practiced a bit, who now want to begin to coach others.

The Practice of Adaptive Leadership by Ron Heifetz, Marty Linsky and Alexander Grashow is what I would call the baseline reference. The books above are geared toward developing your practice. This book is more about the underlying principles. It is also a heavier read, just so you know.


*Note the word deliberately. This meant taking lessons specifically targeting my skill gap. Simply putting in more hours skiing would not be deliberate practice, I would simply be reinforcing the habits I already had. In other words – get a coach.

**Some of my more astute – probably younger – readers may question my judgement about not wearing a helmet. At that time, helmets were pretty uncommon for recreational skiing. Thankfully that has changed in more recent times. And yes, today I wear one.

4 Replies to “Is Your Problem Technical or Adaptive?”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.