The standard explanation for a failed AI implementation is technical. The model underperformed, the data was messy, the integration was harder than scoped.
Sometimes that’s true. More often the technology worked exactly as specified, and the organization got worse anyway. That failure has a different cause, and it isn’t taught in either of the two degrees that dominate the room where these decisions get made.
What Each Curriculum Teaches, and What It Leaves Out
A computer science education teaches you to build a thing that works. Decomposition, abstraction, correctness, complexity, the discipline of reducing a problem until it’s tractable. This is genuinely hard training and it produces people who can make systems behave.
What it optimizes for is a bounded problem with a definable correct answer. The user is largely a source of input and a recipient of output — modeled, not understood.
A business education teaches you to make a decision under uncertainty. Frameworks, financial modeling, competitive analysis, the case method. Also genuinely valuable, and it produces people comfortable choosing without complete information.
What it optimizes for is a bounded decision with identifiable variables. The case study ends. Second-order effects that materialize in year three rarely appear in the exhibits.
Neither program teaches the thing in between: how a change propagates through a system of people, incentives, information flows, and technology, where the effects arrive late, in the wrong department, and don’t look like consequences of the original change.
That discipline exists. Jay Forrester built system dynamics at MIT in the 1950s; Donella Meadows made it legible to non-specialists in Thinking in Systems; Russell Ackoff spent a career arguing that improving each part of a system separately reliably degrades the whole. It’s a real field with real tools. It’s just almost never a required course in the programs that feed enterprise technology decisions.
What This Looks Like When It Goes Wrong
Consider a support organization that deploys an AI assistant to deflect inbound tickets. Reasonable project, clear business case, competent execution.
It works. Ticket volume reaching human agents drops roughly 40 percent. The project is declared a success and the team moves on.
Over the following two quarters:
- Average handle time rises sharply. The assistant deflected the easy tickets, which is what it was built to do. The remaining queue is now entirely hard cases with no simple ones to balance the day. Agent burnout follows.
- New agents take much longer to become competent. Nobody had written down that the easy tickets were the training ground — the volume of simple cases was how new hires built pattern recognition before facing complex ones. That pathway was removed without anyone deciding to remove it.
- The product team loses a signal it depended on. Ticket clusters had functioned as the organization’s most reliable detector of usability defects. Now the defects are quietly absorbed by the assistant, and the product roadmap goes partially blind.
- A cohort of customers churns without complaint. They tried the assistant, didn’t get resolution, and left rather than escalating. They never appear in the support data because they never filed a ticket.
Every individual team’s metrics looked fine or improved. The support director hit the deflection target. The AI vendor delivered to spec. And the organization is measurably worse off.
No engineering error occurred. No business judgment was obviously wrong. What was missing was anyone asking whose work changes when this ships, what this queue was doing besides handling tickets, and what signal we’re removing along with the volume.
Those are systems questions. They belong to nobody’s job description.
Why AI Makes the Gap Wider
Enterprise software has always had second-order effects. Three things make AI a sharper case.
It relocates work rather than eliminating it. Automation rarely deletes effort — it moves it, usually to a different team, often in a different form. The savings are visible and land in one budget; the new work is diffuse and lands in several. Standard ROI analysis captures the first and misses the second entirely.
It optimizes whatever proxy you hand it, relentlessly. A human given a slightly wrong target applies judgment and quietly does the sensible thing. A system given a slightly wrong target pursues it to the edge of the specification. Goodhart’s law has always been true; AI makes it operational at a speed and scale that leaves no room for the informal correction that used to absorb it.
Its effects are delayed and displaced. The deflection rate moves in week one. The training pipeline damage surfaces in month nine, in a different department, attributed to hiring quality. By the time the consequence is visible, the causal chain back to the decision is cold.
Delay plus displacement is precisely the condition under which humans reason worst — and it is the defining characteristic of AI deployment.
The Profile That’s Actually Missing
One useful shorthand for the person who fills this gap: an extrovert IT professional with a business degree. Someone who builds for users first rather than systems first.
It’s a deliberately awkward phrase, and the awkwardness is the point — it describes a combination our institutions don’t produce on purpose. The people who have it usually assembled it accidentally, through an unusual career path.
What it actually names is someone who can hold three things at once: enough technical depth to know what is genuinely possible and what is a vendor’s aspiration, enough business fluency to know which outcomes matter and which are vanity, and enough interest in people to find out how the work is really done rather than how the process document says it is.
The third one is where most implementations are lost, and it’s the least respected of the three. It is not a soft skill. Knowing that the support queue was doubling as a training pipeline requires having talked to a new agent about how they learned the job. No architecture diagram contains that fact.
What the Missing Curriculum Would Contain
If someone were designing this course, six things would earn their place:
- Feedback loops. Reinforcing and balancing. Why a system that seems to resist your intervention is usually doing exactly what it was structured to do.
- Delay and accumulation. Why cause and effect are rarely close in time, and why organizations consistently over-correct as a result.
- Measurement effects. Goodhart’s law taken seriously — how choosing a metric changes the behavior it measures, and how to select proxies that fail gracefully.
- Boundaries. Every analysis draws a line around what counts as the system. Most failures live just outside where somebody drew it.
- Second-order thinking. The practiced habit of asking “and then what happens” three times before stopping.
- Translation. The discipline of moving a concept between technical and business language without losing the part that matters. Currently treated as a personality trait rather than a teachable skill.
None of this is exotic. It’s simply nobody’s requirement.
Building It Without the Degree
Waiting for curricula to change is not a strategy. A few practices develop the same capability inside an organization:
- Before building, map who else’s work changes. Not stakeholders to inform — people whose daily reality is different afterward. If that list has one name, the map is wrong.
- Ask what the current process does besides its stated purpose. Almost every long-standing process has a second, undocumented function. Automating the first while destroying the second is the most common failure in this category.
- Run post-mortems on system effects, not just incidents. Six months after a deployment, ask what changed that nobody predicted. That review is where the expensive lessons live, and almost nobody schedules it.
- Put technical people in front of users regularly. Not a research readout — actual exposure. The detail that saves a project is rarely in the summary.
- Reward the person who finds the second-order problem. They are, in the short term, slowing the project down. If the culture punishes that, the capability never develops regardless of who you hire.
The Real Bottleneck
The models will keep improving. That has been the safest prediction in technology for several years and there is no reason to expect it to stop.
What is not improving at the same rate is the supply of people who can look at an organization and see a system rather than a set of departments — who understand that changing one node ripples unpredictably through every other, and who know to go looking for the ripples before shipping.
