Agile Leadership

Technical VS Adaptive Problems in Agile

Sawyer Conrady

“The most common leadership failure stems from trying to apply technical solutions to adaptive challenges.” Ron Heifetz

Heifetz warns us that misunderstanding an adaptive problem by applying a technical fix isn’t going to win any “CIO of the Year” awards anytime soon. I’m not trying to bag on technical solutions – sometimes that’s exactly what’s needed, and can quickly address something and move on – but more often than not, things aren’t as simple as they first appear. So, l would like to talk a bit about the characteristics of technical versus adaptive problems and how we go about understanding them.

Agile lessons from scuba diving

People that know me know that I’m passionate about scuba diving – I first became certified about 30 years ago and have had some amazing experiences as a diver. About 15 years ago, I got into what we call “technical” diving – typically that means going deeper and staying longer, frequently using various gas mixes and extra tanks to go see things outside of recreational dive limits. Things like deep wrecks, bigger critters and the like. My most technical dive to date was to a depth of approx. 340 feet, carrying 5 different scuba tanks all with various gas mixes ranging from light and heavy helium to pure oxygen. The dive itself took nearly 2 hours and we had to do a lot of carefully planned decompression stops on the way up. Complicated stuff!

A few years ago, I decided to start my cave training – if you’re not familiar with cave diving, instead of diving vertically in the water column, more often than not you dive horizontally and go deep underground into flooded cave systems. It’s not unusual on a typical dive for divers to be multiple-football fields (sometimes miles) deep into a cave system (meaning you have to swim all that way back before you can get to the surface). Another feature of cave diving is that you execute it in teams of 2 or 3 (or more) well-trained divers who are prepared for the situations you could run into. Communication and coordination between the divers on the team is critical as you can imagine. Dangers in a cave can include getting lost (bad), having the batteries on your lights die (very bad) or the worst scenario, not having enough breathable gas to get back to the surface (very very bad).

Understanding the Problem at hand

My first day of cave training I showed up with all the cockiness and self-assuredness of “I’d been doing this for decades” and thought my extensive skills in technical dive planning and execution would allow me to easily master what I was being taught.

I couldn’t have been more wrong. What I thought was going to be a simple technical workshop on learning a few skills quickly turned into a complete redesign on the way I think and go about dive planning and execution. I absolutely sucked the first few days of training – all my previous experience, although helpful, was only tangentially applicable to what I was being asked to do now. I fumbled multiple simple tasks, had a hard time communicating and solving example problems with the other divers and several times I surfaced in a huff and questioned if I was even capable of doing this type of diving safely. I had to completely re-learn how to dive. It was a hard ego check.

My instructor (a very no-nonsense and highly efficient German) noticed me beating myself up and getting increasingly frustrated with my performance and on the way back from another disastrous lesson gave me some advice. He said,

“You might be very good at doing other types of diving, but you’ve never done THIS type of diving before. It’s day 1 of school, so you have to let go of everything you thought you knew coming into this and trust me to help build upon the skills a little bit at a time as we move forward.”

That was a revelation. My agile brain kicked in and I realized that this wasn’t a simple technical challenge, this was a technical AND adaptive challenge. Incremental improvement, fast feedback, pivot or persevere, building on MVPs – I started using all of those agile tools to get closer to my end goal. I experimented, I learned, and I dropped other skills and techniques that weren’t as effective in this new environment. I realized that my initial thinking of what the problem was to be solved (take class, pick up a couple of skills, proceed) was much too simplistic to what was needed to change in my own thinking and my behaviors. I collaborated with my instructor and team-mates on best approaches and what worked for everyone and things quickly improved. Within a few days, things slowly got “dialed in” and towards the end of the class I received the highest praise ever from my German instructor, “You dove efficiently today.”

What are the takeaways?

Technical problems, while often challenging, can be solved applying existing know-how and the current problem-solving processes. The challenge is known and although the work may not be simple, the path is relatively straightforward and can be accomplished by an expert. In this case, I hired an instructor to provide me with the proper training, I built upon my previous experience, and found success. Simple.

Adaptive problems resist these kinds of straight technical solutions because they require individuals to alter their previously established ways of working, break down silos, and work collaboratively towards co-creating the solution. I didn’t think I’d have to change much, that this would be a “net new” skills opportunity. One big “problem” with adaptive problems is that you don’t know what you don’t know. Again, in the scuba diving situation, I *thought* I knew what I was getting into and what was required, but quickly discovered that I had only scratched the surface of understanding the problem. The problem mainly being…me.

Adaptive solutions also almost always require loss, or the giving up of control in order to move a solution forward. In order to embrace a new way of working, you need to give up some of the OLD ways of working. We, as agilists, need to be aware and anticipate the pushback and resistance to change this typically creates. To succeed at the cave diving training, I had to shift my thinking and abandon my pre-conceived biases – from gear to skills to even the way I breathed underwater. Adaptive problems require exactly that – to adapt.

Ultimately, with adaptive problems you have to determine which pieces of your history you must carry forward, and which ones need to go the way of the Dodo.

What questions should we be asking?

So now that we have some characteristics of what denotes something on the technical versus adaptive side of the fence, what questions should we be asking and how does this apply to organizations in general? You should begin by asking yourself (or your team), “What is the nature of the work in front of us?” Is it a clearly defined issue that can be rapidly addressed by a single fix? Or is it something more complex? Are we improving the efficiency of an existing process, or are we completely changing the way we work and measure a new capability?

A useful approach I’ve used to help frame a business challenge is to start with some simple discovery questions to understand what you’re getting yourself into. This process can also include interviews, GEMBA, surveys, direct observations, reviewing artifacts, etc – but I always like to start with this simple set of questions up front.

What’s the problem we’re trying to solve?
What evidence (data) do we have that supports it’s a real problem? Do we have valid meaningful metrics in place to support that this is a real issue or is this based on a suspicion / HIPPO’s opinion?
What does “good” look like after we’ve resolved it? What are our clearly defined outcomes? How will we measure them?
Once the problem is resolved, what other thinking and behaviors will need to change to keep this sustainable? What other inputs into this solution can affect the outcome?

Conclusion

If you can clearly articulate answers to each of these questions, you’re well on your way to framing the problem correctly. If the answer requires some learning or experimentation, that’s okay too, but the important part is not to skip the question in favor of a more expedient process.

What you want to avoid is to begin solutioning BEFORE you’ve taken the time understand the context and complexity of the challenge to be resolved.

As John Dewey elegantly put it, “A problem well-defined is a problem half solved.”