Aug 2, 2025 12 min read

Technical Problems vs Adaptive Challenges

Technical problems vs adaptive challenges

If you're a leader, you've likely faced a problem that refused to be solved by your usual methods. A problem that made you question everything you knew about leadership. 

Consider this scenario: You're a senior manager, respected for solving complex business challenges. But now, you're confronting an issue that's defying every attempt at resolution. On paper, things look fine. Metrics are steady, initiatives are moving forward, and the team appears competent. 

Yet something isn't adding up. Decisions are delayed, and important conversations are avoided. Team members nod in agreement during meetings, only to act differently afterward. New initiatives launch enthusiastically, but fizzle out weeks later.

Your instinct is to fix things: redesign the RACI matrix, roll out a new engagement survey, or clarify decision rights. These standard moves worked in the past. But this time, nothing works.

What you don't realize is that you're not solving the wrong part of the problem; you're solving the wrong kind of problem entirely. The mistake is to confuse an adaptive challenge for a technical one.

Ron Heifetz's distinction between technical problems and adaptive challenges is a powerful — and overlooked — ideas in leadership.

The most common cause of failure in leadership is produced by treating adaptive challenges as if they were technical problems.

—Heifetz, Linsky, Grashow [3]

Adaptive challenges are a different beast

Technical problems are solvable with expertise, process, and control. They can be complex, but are fundamentally linear: define → analyze → fix. The system stays intact; you just upgrade the components.

Adaptive challenges are different. They’re entangled with beliefs, loyalties, habits, and identities. They resist definition, let alone resolution. Solving them requires people to change how they see, not just what they do.

To make things worse, adaptive challenges often show up disguised as technical ones. They feel like a workflow glitch or a communication breakdown. But underneath, they demand a deeper kind of work. A shift in understanding, values, or relationships that the system isn’t ready for.

If you miss that, solutions will not just fail, they’ll worsen things. Each failed fix deepens cynicism and reinforces the status quo.

Before discussing the differences, let’s look at a simple analogy that captures the essence of this distinction: diets.

An example of technical problem vs adaptive challenge

Consider the goal of losing weight.

For a small number of people, this is a straightforward task. They cut sugar, increase their steps, maybe download a tracking app, and the weight comes off. In this case, the challenge is mostly technical. The problem is well defined (excess calories), the solution is known (caloric deficit), and the path to implementation is clear. It’s a matter of discipline and follow-through.

But for the vast majority, the story is very different.

They sure know what to do. They might lose weight initially, but eventually, the old patterns return. The solution doesn’t stick. It’s not due to a lack of willpower. It’s because the presenting issue — weight — is only a surface symptom. Beneath it lie emotional triggers, stress loops, familiar patterns, identity structures, and unresolved grief or shame. The problem wasn’t technical to begin with. It was adaptive.

The person needs new meaning, not just habits. Food isn’t just fuel; it’s comfort, control, celebration, permission, or rebellion. Solving that kind of problem requires more than a new regimen. It requires new sensemaking: a deeper understanding of what’s driving behavior.

An underperforming team might not need a new KPI system or restructuring. Those are technical moves. If the real issue is unspoken conflict, risk-aversion, or a legacy of dysfunction, then no amount of tracking will help. The problem is adaptive. Any solution that fails to identify it as such will fail.

The diet example is useful because it exposes the core question every leader must learn to ask: Does this require new skills or new thinking?

If it’s the latter, technical tools are both insufficient and misleading. They give the illusion of progress while avoiding the real work. And that, more than anything, stalls growth. It’s not a lack of knowledge, but a lack of clarity about the kind of work that’s required.

Let’s unpack the differences, starting with what makes a problem “technical.”

What Is a Technical Problem?

What makes a problem technical isn’t its scale or complexity. It’s that the solution already exists, even if it’s not yet in hand.

Not all technical problems are simple. Many are complex, high-stakes, and demand deep expertise. Performing surgery. Upgrading an enterprise system. Navigating a supply chain breakdown during a geopolitical crisis. These are difficult problems, but not adaptive ones.

The defining features of a technical problem are:

  • The problem is clearly defined and agreed upon.
  • The solution is known or discoverable with current expertise.
  • Implementation can be delegated to those with authority or skill.
  • The system doesn’t need to change; it needs adjustment or optimization.

In short: technical problems exist within the existing paradigm. The tools match the task, and expertise already exists. The organization doesn’t need to change; it just needs to execute better.

If your CRM isn’t syncing across platforms, that’s a technical problem. So is an ambiguous workflow, poorly scoped role, or underperforming product feature. These are fixable with the right resources, coordination, or upgrades.

Technical solutions can be elegant. In fact, good leadership often requires decisive technical action: fixing what’s broken, resourcing what’s underfunded, or simplifying what’s bloated.

But this is precisely why technical solutions are traps. They are seductive, offering the allure of speed, clarity, and closure. Such approaches allow leaders to signal competence and decisiveness. Their appeal is enhanced by clean timelines, visible wins, and PowerPoint slides that signal progress.

Under high pressure, it’s easy to default to what’s actionable: launch new initiatives, restructure teams, or bring in external experts. All valid moves, only if the problem is technical.

Trouble begins when it isn’t. Because technical solutions applied to adaptive challenges don’t just fail, they mask the real work needed. They provide temporary relief while the deeper issue remains hidden.

Leadership derailment happens not from dramatic failures, but well-intentioned efforts that skim the surface.

How do you know when the problem isn’t technical?

What Is an Adaptive Challenge?

An adaptive challenge is a problem with no clear agreement on the definition, known solution, or path that can be executed by authority or expertise alone.

It doesn’t live in the realm of facts and fixes. Instead, it’s about competing values, shifting identities, and conflicting interpretations. 

Adaptive challenges require that those with the problem become part of the solution through learning, not compliance, and sensemaking, not mere performance.

If technical problems are about skill, adaptive challenges are about meaning, which is always contested in organizational life.

Here are the core features of an adaptive challenge:

  • The problem is unclear or experienced differently by stakeholders.
  • There is no off-the-shelf solution because the system has never faced this version of the problem before.
  • Authority can’t solve it alone. It requires engagement of those with lived experience.
  • Progress requires loss: of identity, control, power, or outdated patterns.
  • The solution will likely be emergent, not designed. It will unfold through experimentation, conflict, and learning.

In other words, adaptive work is developmental. It asks the organization and people to grow in ways they may not have chosen.

That’s why these challenges are often avoided, disguised, or reinterpreted as technical ones. Because the real work requires confronting discomfort and asking hard questions:

  • What aren’t we talking about?
  • Whose values are in conflict?
  • What assumptions are we protecting?
  • Who needs to change for this to be resolved?

They often show up as recurring breakdowns: talent strategies that never take root, stalled “transformation efforts,” and persistent collaboration challenges despite workshops and such. Each time, the fix is technical. And each time, it fails.

What’s required is a shift in framing. A willingness to stop asking “What should we do?” and instead ask: “What are we not seeing?”

Adaptive leadership is difficult. You can’t command it. You have to name what’s being avoided, regulate the anxiety it provokes, and create enough tension for learning, without tipping the system into collapse.

The required leadership isn’t diagnostic in the traditional sense. It’s sensemaking under pressure. Adaptive work doesn’t feel like progress. It feels like risk and discomfort from not having all the answers. That’s why leaders use the wrong tools.

Let’s examine why technical solutions are often misapplied to adaptive challenges, and the costs.

Why We Default to Technical Solutions

The illusion of progress

Technical solutions are appealing because they let you act quickly, appear competent, and restore control. They present problems as definable, containable, and fixable. In uncertainty, they offer relief to the leader and the system.

But this is often short-lived. Adaptive challenges don’t yield to technical force. They require engagement, learning, and loss. When leaders mistake one for the other, the consequences compound, not out of neglect, but because of misdirected action.

Action bias under pressure

In most organizations, decisiveness is celebrated. Leaders are rewarded for moving quickly, signaling confidence, and driving outcomes. Few are applauded for saying, “I don’t know yet,” or “We may be solving the wrong problem.”

This cultural bias toward speed and clarity makes adaptive leadership harder. Because it starts by slowing down, grappling with ambiguity, and holding off on premature solutions. It doesn’t look like progress. Often, it looks like pause, discomfort, and conflict. That’s precisely when the pressure to “do something” becomes strongest. And the quickest way to look effective is to reach for a technical fix.

Safety in certainty

Ambiguity is emotionally destabilizing. Leaders under pressure want to resolve the discomfort of not knowing. A technical solution — however partial or misaligned — offers clarity. Even when they suspect the real problem goes deeper, the pull toward certainty can override that instinct. Especially if there’s an audience.

The politics of evasion

Adaptive challenges surface things organizations would rather not examine: outdated beliefs, political bottlenecks, and hidden fault lines. Naming these openly can be risky because it creates tension, threatens power, and destabilizes norms.

That’s why technical solutions are used to avoid the adaptive work those problems point to. They help manage anxiety: organizational, political, and personal. Everyone gets to look busy while preserving the status quo. 

Hidden costs

When technical solutions are applied to adaptive challenges, they don’t just fail quietly. They erode trust. People stop believing the organization can face what matters. Cynicism grows and engagement fades. Meanwhile, the real challenge, still unaddressed, takes root in the culture.

Over time, the organization builds fluency in avoidance. People learn to feign alignment without real commitment. Strategic plans are revised annually while nothing fundamental changes. Hard conversations are postponed indefinitely.

Eventually, leaders end up creating a system that no longer believes change is possible.

A familiar pattern

Stepping back reveals a pattern:

  • An adaptive challenge surfaces.
  • It creates discomfort, ambiguity, and political tension.
  • A technical solution is introduced to ease the pressure.
  • The deeper work remains untouched.
  • The system learns to tolerate symptoms while avoiding causes.

This is how organizations protect themselves from change, loss, and truth. Unless the cycle is interrupted, it becomes self-reinforcing.

The real leadership challenge isn’t just solving problems. It’s clearly identifying the problem and refusing the false comfort of a fix that conceals the work.

How to Differentiate: Technical vs Adaptive

The hardest part of adaptive leadership isn’t solving the problem. It’s seeing it for what it really is. Here’s how to tell the difference.

Look for disagreement

Technical problems usually come with broad agreement. People may argue about how to fix it, but not about what it is.

Adaptive challenges are different. There’s disagreement about both the solution and the situation. The marketing lead thinks it’s a messaging issue. The product team thinks the value proposition is off. Everyone is solving a different problem because they’re experiencing a different system.

When there’s no shared definition of the problem, you’re likely in adaptive territory.

Watch for repeated attempts

One of the hallmarks of adaptive challenges is that they resist resolution. You try to fix the workflow, restructure the team, bring in coaching, launch a new strategy. But six months later, the pattern reemerges. Not because the fix was bad, but because it was aimed at the wrong layer.

When you find yourself returning to the same issue over and over, with diminishing returns, you’re likely facing something adaptive.

Notice when the problem lies in habits and assumptions

Technical problems reside in tasks, tools, and execution. Adaptive challenges lie in how people make sense of their world.

You’ll know you’re dealing with the latter when:

  • The issue touches on values or identities.
  • People feel threatened or defensive, even with a gentle approach.
  • Progress would require someone to unlearn a success formula they’ve relied on for years.

These are not technical barriers but adaptive fault lines. Adaptive leadership begins where competence ends and identity begins.

Can it be delegated?

A useful litmus test: can someone else solve this?

Technical problems can be delegated to someone with expertise, authority, or the right tools. Adaptive challenges cannot. They require the people experiencing the problem to be involved in solving it because the solution doesn’t exist yet. It has to be created through participation, conflict, and iteration.

If the problem demands others change — but you’re solving it for them — you’re likely defaulting to a technical fix.

Pay attention to resistance

Adaptive work surfaces loss. Not always a dramatic loss, but of comfort, identity, and coherence. This triggers resistance. People get quiet and momentum stalls. 

What looks like disengagement may actually be self-protection. That’s not failure. It’s a sign you’ve touched the real issue.

Technical and adaptive problems don’t exist in separate silos. Most real-world challenges are mixed. But the danger is in solving only the technical part — because it’s visible, measurable, and comfortable — while leaving the adaptive core untouched.

The work of leadership begins when you stop asking, “What do we do?” and start asking, “What’s really going on?”

A Diagnostic: Technical Problems vs Adaptive Challenges

Dimension

Technical Problem

Adaptive Challenge

Problem Definition

Clear and agreed upon. Everyone sees the same issue.

Disputed or ambiguous. Different people define the problem differently or see different root causes.

Solution Availability

Known. A solution exists and can be implemented using current expertise or standard methods.

Unknown. No clear solution exists yet; the answer must be discovered or co-created.

Location of the Work

Outside the people—can be delegated to experts, consultants, or systems.

Inside the people—those with the problem are also part of the solution. Cannot be outsourced.

Type of Work Required

Application of knowledge, execution, coordination, process optimization.

Learning, experimentation, value negotiation, identity work, and sensemaking.

Time Horizon

Short to medium term. Results can be planned and forecasted.

Medium to long term. Progress is emergent and unfolds in non-linear ways.

Primary Leadership Role

Direct, instruct, deploy resources, resolve.

Diagnose, frame the issue, hold space, regulate distress, mobilize learning.

Kind of Change Needed

Transactional. Tweak routines, improve execution, or apply new tools.

Transformational. Shift mental models, roles, relationships, or underlying assumptions.

Role of Authority

Authority figures can define the problem and deliver the solution.

Authority alone is insufficient. Leadership must engage others in working through the problem.

Nature of Resistance

Minimal or technical—disagreement over method or timeline.

Emotional and political—linked to fear of loss, disruption of identity, or conflicting values.

Markers of Misdiagnosis

Solution implemented but problem persists or recurs.

Repeated cycles of initiative without sustainable change; surface compliance but underlying stagnation.

Risk of Avoidance

Low. Fixing the problem is seen as desirable and straightforward.

High. Naming the problem may provoke conflict, discomfort, or threaten norms and loyalties.

Signs You’re in Adaptive Work

People are uncomfortable or disengaged. The “fix” doesn’t stick. The system pushes back without clarity.

Progress requires naming loss, unlearning what once worked, and tolerating ambiguity.


Most organizations aren’t short on tools, plans, or urgency. What they lack is the habit of asking the right question early enough.

By the time the issue is on the table, the reflex is already underway: frame it as an execution problem, assign it to the right person, create a timeline, and track progress. It looks like action. But in many cases, the work has gone off course because the problem hasn’t been clearly understood.

For leaders, the task is not to work harder, implement faster, or persuade better. It’s to see sooner and to match action with the problem.

Everything else flows from that.

Sources and Further Reading

  1. Heifetz, R. A. (1994). Leadership Without Easy Answers.
  2. Heifetz, R. A., & Linsky, M. (2002). Leadership on the Line.
  3. Heifetz, R. A., Grashow, A., & Linsky, M. (2009). The Practice of Adaptive Leadership.
  4. Adaptive Leadership: Making Progress on Intractable Challenges
  5. The Theory Behind Adaptive Leadership – Cambridge Leadership Associates
  6. The Work of Leadership – Harvard Business Review
Sheril Mathews
I am an executive/leadership coach. Before LS, I worked for 20 years in corporate America in various technical & leadership roles. Have feedback? You can reach me at sheril@leadingsapiens.com.
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Leading Sapiens.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.