Adaptive leadership: how to lead when there is no known answer

Adaptive leadership is the practice of mobilizing people to tackle problems that have no known solution and that require them to change their own habits, roles or assumptions. The idea comes from Ronald Heifetz at Harvard, who argued with Donald Laurie that in such situations, rather than providing answers, leaders have to ask tough questions. Seeing early where a change will require new roles and skills is part of the job, and workforce planning software helps by modeling the capabilities a team will need before the gap becomes urgent.

The model rests on one distinction. A technical problem can be solved with existing expertise: a broken process, a missing tool, a skills gap with a known course. An adaptive problem cannot, because the solution lies in changing how people work together, what they prioritize or what they believe. Most leadership failures in change come from treating an adaptive problem as a technical one.

Adaptive work asks people to give something up. Heifetz and Laurie noted that adaptive change is distressing for the people going through it, who must take on new roles, relationships, values and approaches to work. In a later article, Heifetz and Marty Linsky observed that when the status quo is upset, people feel a sense of profound loss and dashed expectations. Resistance is often grief for a competence or identity that the change makes less valuable.

Leaders struggle too. Many are promoted for solving problems themselves, and adaptive work requires them to hold back answers and let others struggle productively. The pull to "just fix it" is strongest exactly when it does the most harm.

And the volume of change keeps rising. Gartner finds that only 32% of leaders globally get employees to adopt changes in a healthy way. Teams that cannot adapt pay for it: Gartner also reports that companies with above-average change adoption see year-over-year revenue growth rates two times higher than those below average.

Before you act, sort the problem. Most real situations have both parts; name each.

Examples on a team:

• Technical: the reporting dashboard shows wrong numbers. A data analyst finds and fixes the query.
• Adaptive: sales and support blame each other for customer churn. No expert can fix it; the two teams must change how they hand customers over and what each counts as success.
• Mixed: a new AI tool arrives. Installing it and training people on features is technical. Deciding which work changes, which skills still matter and how people feel about it is adaptive.

When you hear "if only they would…" about a group of people, you are probably looking at an adaptive challenge.

Heifetz and Laurie described six principles: getting on the balcony, identifying the adaptive challenge, regulating distress, maintaining disciplined attention, giving the work back to people, and protecting voices of leadership from below. For a team manager they reduce to the five moves in the figure below.

1. Get on the balcony

Step back from the action and look for the pattern. In meetings, notice who speaks, who avoids the topic and where discussions always stall. Ask: "What keeps happening here, regardless of who is involved?" A weekly 15-minute review of notes from the week is enough to start seeing patterns instead of incidents.

2. Name the challenge

Say out loud which part of the problem is technical and which is adaptive. Then name what people may have to give up, and what will stay. Heifetz and Laurie wrote that leaders must help others distinguish immutable values from historical practices that have become obsolete. "We will keep our standard of owning every customer problem. What we may have to give up is each team owning its own queue."

3. Regulate the pressure

Keep the pressure high enough that people engage with the problem, and low enough that they can think (see the next section).

4. Give the work back

Resist the urge to solve it. Ask the people who own the problem to design the answer, and hold them to it. Bring together those who must change, including the dissenters and the people closest to customers. Protect the quiet or unpopular voices that see the problem differently; they often carry the information the group is avoiding.

5. Experiment and learn

Treat each answer as a hypothesis. Run small, timed tests and decide on the evidence, rather than committing to a large plan up front (see "Run small experiments").

Change creates stress, and some of it is useful: it is the signal that something needs attention. The problem is stress that comes from not knowing. In an experiment published in Nature Communications, people's estimates of uncertainty predicted their stress responses, and subjective stress, pupil size and skin conductance all tracked irreducible uncertainty. How closely each person's stress tracked uncertainty also predicted how well they performed the task, which the authors read as stress playing a useful role in learning under uncertain threat. Uncertainty you remove is stress you remove, without lowering the challenge itself.

Signs the pressure is too low:

• The topic keeps being postponed or delegated to a working group that never reports.
• Meetings end with agreement but nothing changes.
• People talk about the problem as someone else's.

Signs the pressure is too high:

• People stop raising ideas and wait for instructions.
• Conflict becomes personal rather than about the work.
• Sick days, mistakes and departures rise in the affected team.

To raise pressure: put the problem on every meeting agenda, share the data people are avoiding, set dates for decisions. To lower it: say clearly what is known, what is not and when you will know more; fix the technical parts quickly; slow the pace on one front so people can absorb another; make sure people know the values and jobs that are not at risk.

Teams are asked to absorb more change than before, and inspiration alone does not carry them through it. Gartner reports that establishing change as a routine is three times more effective than an inspirational approach to change adoption. For a team manager, routine means:

• Small changes, often. Adjust one working practice each month, deliberately, so adapting is a habit rather than a crisis.
• Progress, not only the end state. Report what changed this week and what was learned, not only how far the destination is.
• A standing slot. Ten minutes in the weekly meeting for "what is changing around us, and what do we need to adjust?"
• Fewer simultaneous changes. Sequence changes where you can, and say no to the ones that do not matter.

Adaptability can also be developed as a skill. Pulakos and colleagues analyzed over 1,000 critical incidents from 21 jobs and identified eight distinct dimensions of adaptive performance at work. Adaptability is several skills, not one trait, so practice them one at a time: dealing with unclear situations, learning a new task, solving an unfamiliar problem. A team that already reviews its work and learns from it adapts more easily; how to create a learning culture shows how to build those habits.

Adaptive problems are solved by learning, and learning needs tests. A one-page experiment format:

1. Hypothesis. "If support takes ownership of renewals for customers with open tickets, churn in that group will fall."
2. Test. What exactly will change, for whom, for how long. Keep it small: one team, one segment, four to six weeks.
3. Measure. One or two indicators decided in advance, and what result would count as success or failure.
4. Owner and date. Who runs it and when you will decide.
5. Decision rule. Scale, adjust or stop, based on the measure, not on enthusiasm.

Run two or three experiments in parallel when the answer is very unclear. Share failures as openly as successes: a stopped experiment that taught the team something is a good result. If the experiments point to a bigger decision, sort it by stakes and reversibility first, as described in decision making in leadership.

Many adaptive challenges arrive as decisions made elsewhere: a reorganization, a new strategy, a new system. You can still lead the adaptive part. Translate the decision into what changes for your team, name what is technical (training, tools, timelines) and what is adaptive (roles, priorities, relationships), and give your team the work of designing how to make it work here. Our guide on how to lead change covers explaining a decision you did not make and reading resistance.

Adaptive leadership is a set of practices more than a tested theory, and it has limits:

• The evidence is mostly from cases. It is widely taught, but controlled studies of the model as a whole are scarce. Treat it as a useful lens, not a proven method.
• It is slow in a real crisis. When safety or survival is at stake, people need direction first; adaptive work comes once the situation is stable.
• It needs tolerance for failure. In organizations that punish failed experiments, giving the work back produces cautious proposals, not learning.
• It can be misused. "Giving the work back" is not leaving people alone with an impossible problem. You still provide resources, protection and a clear question.

Use it alongside good technical management, and be explicit about which mode you are in.

• Naming the challenge: "Part of this is technical, and we'll fix it this week. The harder part is that we'll need to change how sales and support hand over customers, and I don't have that answer. We'll need to find it together."
• Giving the work back: "You know this work better than I do. What would you try first, and how would we know in a month if it's working?"
• Lowering uncertainty: "Here's what we know, here's what we don't, and here's when we'll know more. Nothing about your role changes before then."
• Raising pressure: "We've talked about this for three months. By the 15th, I'd like two experiments running."
• Protecting a dissenting voice: "Before we decide, I want to hear the strongest argument against this. Who sees it differently?"
• Closing an experiment: "The test didn't move the number, and we learned why. We're stopping it and trying the second option."

• Treating adaptive problems as technical. Buying a tool or reorganizing the chart when the real issue is how people work together.
• Rescuing the team. Supplying the answer to relieve discomfort, which stops the learning.
• Letting the pressure drop. Moving on as soon as the first crisis passes, before the new way of working has stuck.
• Overloading people. Running many changes at once, so none gets the attention it needs.
• Silencing dissent. Treating objections as resistance, when they often contain the information you need.
• Big plans instead of tests. Committing to a full rollout before a small experiment has shown it works.

Workforce planning tools model the roles and skills a change will require, so learning can start before the gap is urgent. People analytics shows where a change is causing strain, in turnover, internal moves or engagement by team. OKR tools suit short, experimental cycles: each test gets an owner, a measure and a decision date.

Software cannot tell you whether a problem is technical or adaptive, hold a team in productive discomfort or protect an unpopular voice. A clear sense of direction helps people tolerate the uncertainty of adaptive work; leadership vision shows how to describe where the team is going in a way people can picture.