Consider two senior engineers on the same team, promoted to the same level around the same time. Both good at their jobs. Both used to being the person whose judgment carries weight. Somewhere in the months after, without either of them naming it, a quiet competition starts. It shows up as technical disagreement. They clash on decisions that used to get settled easily, and the clashes take longer to resolve than the substance of the issue seems to warrant. One starts pushing back harder on the other's calls than the situation requires. The other starts avoiding direct conversation, routing decisions through someone else instead. Nobody makes a complaint. There's no incident. Just a low, steady friction the whole team can feel and nobody calls out.

The team's lead reads it as an ambiguity problem; too much room for individual judgment, not enough process. So they introduce a formal sign-off step, requiring both engineers' approval before certain decisions move forward. Clear process, clear accountability, and on paper a good fix. It seems to work for a few weeks. Then the same dynamic resurfaces in a different form, somewhere else in how the two of them work together, still never named directly. The lead hadn't solved the problem. They'd relocated it, and it came back wearing the language of process instead of conflict.

Two kinds of problems, not one

Ronald Heifetz, who spent decades studying leadership at Harvard's Kennedy School, drew a distinction that most new leaders never encounter until they've already been burned by ignoring it [1]. A technical problem has a known solution. Someone with the right expertise applies it, and the problem is resolved. A production outage caused by misconfigured software is technical. A senior engineer knows the fix. They apply it. Done.

An adaptive problem is different in kind, not just in difficulty. It requires the people inside the problem to change how they think, what they value, or how they relate to each other, and no outside expert can do that work on their behalf, because the expert isn't the one who has to change. Heifetz built this distinction around large-scale, high-stakes situations; organisations forced to reconcile genuinely competing values, where someone has to give something up and there's no clean resolution. The friction between two engineers is a smaller thing than that, but the same underlying logic scales down. Most leaders never meet an adaptive challenge at Heifetz's scale in a given week. They meet a dozen smaller versions of the same pattern, and the diagnostic question is identical at any size: can an expert fix this, or does it require the people involved to change something in themselves.

That question is where most treatments of this idea stop, and it's also where the real difficulty starts. The conflict between the two engineers above was never really about the technical question on the table. But naming what it actually was about requires more than swapping one label for another.

What the sign-off process was actually doing

Heifetz has a name for what the team's lead did, and it isn't incompetence. He calls it a work avoidance mechanism. That is, a legitimate-looking action that lets people feel something is being addressed while the actual adaptive work stays untouched [2]. A technical fix is one of the most common versions of it, precisely because it's the move a competent person reaches for by instinct, and because it produces something visible. A document. A policy. A line in a meeting note that says the issue has been addressed.

The tell isn't that the fix fails outright. It's that it works just well enough to reduce the visible symptom without changing anything underneath it, which is exactly what happened here. The sign-off process didn't fail because it was badly designed. It succeeded at exactly what a technical fix does. It managed the presenting behaviour and left the actual conflict, whatever it was about status, competence, or being the one whose judgment counted, completely intact. The engineers adapted to the new process instead of to each other. That's not a coincidence. It's what a well-executed technical fix does to an adaptive problem. It absorbs the pressure without releasing it.

This is worth sitting with, because it inverts the usual advice. The common version of this idea says don't apply a technical fix to an adaptive problem, apply the right kind of intervention instead. But a leader rarely reaches for a technical fix by mistake. They reach for it because the alternative requires something harder than picking the right tool. It requires naming a conflict nobody has agreed to have yet, tolerating the discomfort of not resolving it immediately, and risking being wrong about what's actually going on. A technical fix is often not a failure of diagnosis. It's a choice, usually not fully conscious, to avoid the cost of getting the diagnosis right.

Why the avoidance is rational, not just common

People don't resist adaptive work because they're stubborn or because they haven't been given a clear enough process. They resist it because adaptive work asks them to lose something, and loss aversion isn't a character flaw, it's a stable feature of how people evaluate change [3]. In the scenario above, resolving the conflict directly would have meant one or both engineers admitting, to the other, that some of what looked like technical disagreement was actually about status; about no longer being the only one whose calls didn't get questioned. That's a real loss of identity, not a preference that can be traded away with a better process.

This is why leaders underestimate how long adaptive work takes, and why they misread stalling as resistance to the process rather than resistance to the loss the process is asking for. It also explains why a sign-off step felt like relief to everyone involved, including the lead. It let both engineers keep functioning without either one having to name or absorb that loss. Everybody in the situation had a reason to prefer the technical fix. That's what makes adaptive problems hard to diagnose in the moment. The incentives of everyone involved, including the leader, point toward the version of the fix that doesn't require anyone to lose anything visible.

Diagnosing before acting

Telling technical and adaptive problems apart isn't a single yes-or-no question, and treating it as one is itself a mild form of the same avoidance. Two questions do more real work than one.

The first is Heifetz's: does a known solution exist, one an expert could apply without asking anyone to change? If a leader can answer that clearly and the answer is yes, the problem is technical, and the job is to find the expert and get out of the way.

The second is harder, and it's the one most leadership advice skips. What would each person involved have to give up for this to actually resolve, and is anyone in the situation, including you, currently avoiding naming that loss because naming it is uncomfortable? This requires something Heifetz calls getting on the balcony: stepping back from the immediate dynamics enough to see the pattern rather than just the presenting behaviour [4]. From inside the conflict, the two engineers' disagreements look like a string of separate technical disputes. From the balcony, they look like the same underlying issue recurring in different clothing, which is usually the clearest sign an adaptive problem is being managed rather than addressed.

A better second attempt in the scenario above wouldn't add more process, and it also wouldn't be a single conversation where the leader delivers the diagnosis and both engineers nod. Heifetz is specific that adaptive work has to be given back to the people who own it, not solved on their behalf, because a solution handed down by authority gets treated as another technical fix, however well it's phrased [5]. It looks more like the leader naming the pattern they've observed, without assigning blame, and then asking each engineer directly what they'd need to trust the other's calls again, and doing that more than once, over weeks, without a guarantee the first or second attempt lands. The discomfort in that process isn't a sign it's going wrong. It's usually a sign the actual issue is finally in the room instead of underneath the process.

What this is for

If you've added structure around a problem and watched it come back wearing a different face, this is likely why, and it isn't a failure of leadership so much as evidence you're facing a genuinely different category of problem than the ones your technical training equipped you for. The harder question isn't whether you can tell technical and adaptive problems apart in principle. It's whether you're willing to notice when you, personally, are reaching for a technical fix because it's actually the right tool, or because naming what's really going on would cost you something too.

That's what the next installment in this series looks at. Once you can see the difference and you're willing to sit with it, where the credibility to act on adaptive problems actually comes from, because it isn't the same credibility that got you promoted into leadership.

References

[1] Heifetz, R. A. (1994). Leadership Without Easy Answers. Harvard University Press. Heifetz's technical/adaptive distinction was developed primarily through work with public sector and healthcare leadership, usually involving group-level or organisation-level conflicts over competing values. The illustration above applies the same diagnostic logic to a smaller, everyday interpersonal conflict; the underlying distinction holds at that scale, though it's a lower-stakes case than the one the original theory was built to address.

[2] Heifetz, R. A. (1994). Leadership Without Easy Answers. Work avoidance mechanisms are discussed as a recurring pattern in groups facing adaptive challenges, alongside related behaviours such as scapegoating and denial.

[3] Heifetz, R. A., & Linsky, M. (2002). Leadership on the Line: Staying Alive Through the Dangers of Leading. Harvard Business Review Press. The framing of adaptive resistance as loss rather than mere change resistance is central to this text.

[4] Heifetz & Linsky (2002), on the practice of observing group dynamics from a position outside the immediate action.

[5] Heifetz (1994) and Heifetz & Linsky (2002), on the principle of returning adaptive work to the people who hold it rather than resolving it through authority alone.