A technical problem is a challenge that can be addressed through the application of existing knowledge, established procedures, or recognized expertise. A broken system, a misaligned process, a skill gap—each is technical because an authority figure can diagnose it, prescribe a solution, and implement the fix. The people affected may need to follow instructions or learn new procedures, but they do not need to change who they are. Installing AI coding tools is a technical problem; figuring out what it means to be an engineer when AI writes code is adaptive. Heifetz's framework insists the distinction is not about difficulty—technical problems can be enormously complex—but about whether the solution already exists in someone's repertoire or must be constructed through the painful learning of the people who hold the problem.
Heifetz developed the technical-problem category to provide contrast and precision to the adaptive challenge. Organizations default to treating every problem as technical because technical problems are manageable: there is a known path from diagnosis to resolution, and the authority structure that governs organizational life is designed for exactly this kind of problem-solving. The CEO who faces a supply chain disruption (technical) mobilizes logistics expertise. The manager who faces a software bug (technical) directs engineering resources. The system works smoothly when problems are genuinely technical, and it produces the illusion of competence when problems are misdiagnosed as technical but are actually adaptive.
The AI transition presents both technical and adaptive dimensions simultaneously, and the most dangerous organizational error is the failure to distinguish between them. Selecting which AI platform to adopt: technical. Training employees to use the platform: technical. Reorganizing workflows to incorporate AI outputs: technical. Each of these has a known solution set—vendor evaluation frameworks, training curricula, process redesign methodologies. But underneath the technical surface lies the adaptive depth: the identity crisis of professionals whose signature skills are being absorbed by the tool, the grief that cannot be processed in a sprint retrospective, the existential question of contribution that no reskilling program addresses. Organizations that treat the entire transition as technical implement excellent solutions to the wrong problem—producing compliance, productivity metrics, and reorganized teams while the adaptive challenge compounds silently beneath.
The distinction maps directly onto the difference between what can be planned and what must emerge. Technical problems submit to planning because the solution space is known. The Gantt chart, the project roadmap, the transformation timeline—these are appropriate tools for technical work. Adaptive challenges resist planning because the solution does not yet exist and cannot exist until the learning has produced it. The engineer discovering what she contributes when AI writes code cannot be given a timeline for that discovery. The discovery has its own tempo, governed by the pace at which she can mourn the old identity and construct the new one. Leaders who impose technical timelines on adaptive processes do not accelerate the work—they drive it underground, where it continues as suppressed anxiety, quiet disengagement, and the performance of transformation without its substance.
The technical-adaptive distinction draws on Heifetz's training in medicine and psychiatry, where the difference between curable conditions and chronic conditions requiring patient adaptation is foundational. A bacterial infection: prescribe antibiotics, the patient recovers. Diabetes: the patient must reconstruct her entire relationship to food, activity, and self-monitoring, or the medical interventions fail. Heifetz observed that organizations exhibit the same duality—some challenges yield to expertise applied from outside, others require the affected people to change from inside—and that leadership frameworks had systematically neglected the second category.
The concept was sharpened through Heifetz's decades of teaching at the Kennedy School, where students brought case studies from government, business, and civil society. The cases that most reliably produced leadership failure shared a structure: a genuine adaptive challenge (healthcare reform, educational transformation, organizational culture change) treated as a technical problem (better policy, better curriculum, better org chart). The misdiagnosis was so consistent, and so consistently catastrophic, that Heifetz built his entire framework around teaching leaders to recognize the difference before designing any response.
Known solutions. Technical problems are solvable through existing expertise—someone already knows how to fix this, and the task is mobilizing that knowledge effectively.
Authority-driven. Technical problems are appropriately solved by authority figures applying their specialized knowledge—the organizational hierarchy exists largely to enable this kind of problem-solving.
No identity change. Solving a technical problem does not require the affected people to change their values, beliefs, or sense of self—they may need new skills, but not new identities.
Misdiagnosis danger. The most common leadership failure is treating an adaptive challenge as technical—producing confident, well-funded plans that address symptoms while the underlying condition worsens.
Both dimensions coexist. Most real-world challenges (including AI) have technical and adaptive components; the art is distinguishing which response serves which dimension without collapsing the adaptive into the technical.