5 min read

AI Is Adaptive Work Disguised as a Technical Project

AI Is Adaptive Work Disguised as a Technical Project
AI Is Adaptive Work Disguised as a Technical Project
8:42

 AI Is Adaptive Work Disguised as a Technical Project And This Is Why Your Rollout Is Stalling 

I want to tell you about the single most important diagnostic mistake I see in AI transformation work.

Leaders treat AI deployment as a technical challenge. It isn't. It is an adaptive challenge, and as long as you keep treating it like a technical one, you will keep getting the same disappointing result no matter how much money you spend.

This isn't a soft observation. It's a framework with thirty years of scholarship behind it, from Ron Heifetz and Marty Linsky at Harvard's Kennedy School. And once you internalize it, almost every frustrating AI rollout in your organization starts making sense. 


 
The distinction that changes everything

Heifetz and Linsky, in their book Leadership on the Line and the follow-on The Practice of Adaptive Leadership, draw a hard line between two kinds of work:

Technical challenges. The problem is clear. The solution is known. Experts can implement it. Existing roles and structures don't need to shift. The work might be difficult, but it's not confusing.

Example: deploying a new project management platform. You pick the vendor, configure it, train the users, migrate the data. Done.

Adaptive challenges. The problem itself requires learning to define. The solution requires learning to discover. Stakeholders — not experts — have to do the actual work. Values, attitudes, habits, and roles all have to shift.

Example: rebuilding how knowledge work gets done in a company because AI now exists.

Heifetz has said it many times in his teaching: "The most common failure I've seen in leadership over many years is this diagnostic failure of people in high positions of authority who have failed to lead because they've ended up treating adaptive challenges as if they were technical."

Read that quote twice. It is the entire AI conversation in one sentence. 


 
Why your AI rollout looks technical (but isn't)

The seduction is understandable. When you frame AI as a technical project, you can plan it. You can put it on a timeline. You can hire a vendor. You can assign it to IT. You can report quarterly on milestones.

Adaptive work doesn't behave that way. It is messy. It involves loss. It requires people — not the leader — to change behavior. It threatens existing identity and expertise. It has no defined endpoint. It cannot be solved. It can only be learned through.

Here are the tell-tale signs your AI work is adaptive, not technical:

  • The tool is purchased and deployed, but adoption stalls.
  • Senior people resist using it, even when they say they support it.
  • Every team interprets "use AI" differently, and no two implementations look alike.
  • Productivity gains are theoretical — visible in slide decks, invisible in the P&L.
  • Whenever leaders push harder, resistance gets quieter but not smaller.
  • People agree in the room and disagree everywhere else.

If three or more of those are present in your organization, you are doing adaptive work, and the technical playbook will not get you to the outcome.


 
What people are actually resisting (and it isn't AI)

One of the most important insights in the Heifetz/Linsky framework is also one of the most counterintuitive:

People do not resist change. They resist loss.

When a knowledge worker pushes back on an AI rollout — quietly, by not using the tool, or vocally, by listing reasons it won't work — they are almost never resisting the technology itself. They are resisting one or more of the following:

  • Loss of competence. The way they used to be excellent is no longer the way the work gets done.
  • Loss of status. The expertise that took them ten years to build is now table stakes.
  • Loss of certainty. They knew how their job worked yesterday. They don't know how it will work tomorrow.
  • Loss of identity. The professional self-image they've carried for two decades — "I'm a great analyst," "I'm a great writer," "I'm a great strategist" — is suddenly contested.
  • Loss of relationships. The team dynamics, the rituals, the way information flowed — all of that may be quietly reorganized.

Daniel Kahneman's research, summarized in Thinking, Fast and Slow, gives us the technical name: loss aversion. People weight potential losses roughly twice as heavily as equivalent potential gains. If there's any chance the change will result in loss, the brain tends to resist — regardless of the upside.

That means when a leader stands up at the all-hands and lists the upside of AI — the productivity, the efficiency, the time savings — and a third of the room nods politely and then doesn't adopt anything, those people are not being irrational. They are doing exactly what brains are designed to do: protecting what currently works from an uncertain future.

You don't lead through that by repeating the upside louder. You lead through it by naming the loss, acknowledging it, and helping people find their footing in the new world 


 
What adaptive leadership actually looks like in an AI rollout

Heifetz, Grashow, and Linsky describe a set of moves the adaptive leader makes. I'll give you the short version, applied directly to AI:

Get on the balcony. Step out of the day-to-day and look at the whole system. Where is AI being used well? Where is it being avoided? Who is succeeding with it, and what are they doing differently? What are the conversations not happening in the meetings? You cannot diagnose adaptive work from the dance floor.

Name the adaptive work explicitly. Stop solving it like a technical problem. Tell your organization, in plain language, that this is going to require people to learn, to let go of old practices, and to redefine parts of their roles. Treating it as a software rollout sets up the wrong expectations and makes the inevitable friction feel like failure.

Regulate the heat. Adaptive work requires productive discomfort — enough pressure that people engage, not so much that the system breaks. Too cool and nothing changes. Too hot and people check out. Read the temperature in your organization weekly and adjust.

Give the work back. The leader's job is not to provide the AI playbook. The leader's job is to push ownership down so the people who actually do the work can shape how AI fits into it. If you hand them a fully designed solution, they'll resent it. If you give them a clear problem and trust them to learn, they'll own it.

Protect dissent. The person on your team who is saying "this isn't working" or "I don't get what we're trying to accomplish" is often holding the most valuable insight in the room. Silence them and you lose the diagnostic data you need most.

Pace the change. Adaptation is a marathon. Manage the losses along the way. Acknowledge what you're asking people to let go of. Celebrate genuine learning, not just adoption metrics. And don't confuse compliance with capability.


 
The diagnostic question you should be asking

Every Monday, I'd encourage you to ask yourself one question about your AI initiative:

"Am I treating this as something to be solved, or something to be learned through?"

If your answer is "solved" — if you're tracking it like a project plan, escalating issues to IT, and waiting for adoption to "stabilize" — you are misdiagnosing the work, and the rollout will continue to underperform.

If your answer is "learned through" — if you're protecting time for experimentation, listening for resistance as data, redesigning roles as you go, and accepting that capability will be uneven for a while — you are doing the actual job.

The companies that are going to win the next ten years are not the ones with the most sophisticated AI stack. They are the ones whose leaders correctly diagnosed the work as adaptive and built the organizational muscle to do it.

A technical challenge gets solved with expertise. An adaptive challenge gets learned through, together. Leadership is knowing which one you have in front of you.

For AI, the answer is almost always the second one. 


 

Sources & further reading:

  • Heifetz, R. A., & Linsky, M. (2002). Leadership on the Line: Staying Alive Through the Dangers of Leading. Harvard Business Review Press.

  • Heifetz, R. A., Grashow, A., & Linsky, M. (2009). The Practice of Adaptive Leadership. Harvard Business Press.

  • Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.

  • Harvard Medical School Professional & Continuing Education, "Adaptive Leadership: Making Progress on Intractable Challenges" (faculty insights from Dr. Greenberg).