How technical problems mask adaptive challenges

Try this: Never proceed with a solution to a technical problem without first naming the adaptive challenge behind the problem.

Try this: Never proceed with a solution to a technical problem without first naming the adaptive challenge behind the problem.

Ronald Heifetz, founder of the Center for Public Leadership at Harvard’s Kennedy School, describes technical problems as those that a group can address without pulling any muscles.

A photographed book page with one passage marked in pink highlighter: “What makes a problem technical is not that it is trivial; but simply that its solution already lies within the organization’s repertoire. In contrast, adaptive pressures force the organization to change, lest it decline.”

In museums, technical problems show up as research projects, a survey, a new database, or a wayfinding refresh.

Heifetz says adaptive challenges are harder because they’re unfamiliar. They require us to act in new ways or give something up. Choosing who the museum is for is an adaptive challenge. You can’t say which outcomes you want to prioritize without saying which ones you’re not going to prioritize and, even though making the decision does not, in fact, mean you’ll no longer provide those outcomes, it feels like a loss or some kind of negligence. (“But aren’t we for everyone?!”)

By my interpretation, you sometimes have to take on a technical problem to address an adaptive challenge. It’s more than reasonable to do some research (technical problem) before making a difficult strategic choice like positioning the museum around a particular set of outcomes (adaptive challenge). The problem comes when we use technical problems to avoid adaptive challenges.

One thing I’ve been collecting evidence on these past months is a tendency (and, frankly, me) to seek technical solutions without clarity on what someone will have to give up on the other side of that solution or project. Example: Earlier this summer, we introduced dashboards for those who have taken our Outcomes Assessment. The dashboards let MaP members from the same institution access live data about their assessment results and how they compare to other institutions. The intention is to help people access data without having to knock on a colleague’s door for another copy of their report. A technical problem because I know how to create web pages and I enjoy devising ways for people to interact with things online. This week, a community member showed me how they’re now creating quick visitor surveys to understand how they think about the outcomes their museum provides. They want to get that data into their dashboard to compare staff beliefs against visitor realities. Another fun technical problem that’s completely addressable. At the same time, in that same call, we both concluded that the hardest thing is that outcomes are the last thing people want to tackle on a Tuesday afternoon. Or, in other words, making choices about what matters to users tends to be the first thing that gets cast aside when things get busy (and when are they not busy?). That’s an adaptive challenge. It’s unfamiliar, demands different behavior and new ways of working, and likely leads to decisions that feel like we’re losing something in the process.

Don’t ignore the emotional tax. Heifetz and Donald Laurie visualize the productive range of stress like so:

A diagram titled “Technical Problem or Adaptive Challenge?” plotting disequilibrium against time. A band between the Threshold of Learning and the Limit of Tolerance is labelled the Productive Range of Stress; an oscillating line labelled Adaptive Challenge stays inside it, while two lines labelled Work Avoidance and Technical Problem drop below it and flatten out. Source: Ronald A. Heifetz and Donald C. Laurie, “Mobilizing Adaptive Work: Beyond Visionary Leadership,” in The Leader’s Change Handbook (John Wiley & Sons, 1998).

I find it helpful to understand there’s actually a narrow tolerance for addressing adaptive challenges. And once you’ve absorbed these two definitions, you can begin integrating them into your work in interesting ways. For example, what happens if we say that we need to calibrate against a tendency to reach for technical problems in the face of adaptive challenges? We could introduce a rule: We won’t pursue a technical problem without first identifying the adaptive challenge behind it. Now, not every technical problem hides an adaptive challenge, but by building a habit of assuming one likely lurks somewhere, we may be doing ourselves a favor. Naming the underlying challenge also forces us to identify what’s at stake. Commissioning this research serves a difficult choice that will make some of us unhappy. Are we prepared to accept those various potential outcomes, or are we commissioning this research as a way of deferring that unhappiness?

Technical problems are defensible. You’re not going to get in trouble for trying to make a better exhibition or a better survey. You will ruffle some feathers if you try to get people to say plainly what outcomes your institution supports, for whom, and when.

— Kyle