AI Implementation Failures Are Sociotechnical, Not Technical

I was reading Bostrom and Heinen (1977) last week, the two-part paper in the very first volume of MIS Quarterly, and I had to stop and check the date on the page. The paper opens with an argument that should have changed how every organization thinks about technology deployment. MIS problems and failures, they wrote, are almost always sociotechnical problems, not purely technical ones. The very first issue of the field's flagship journal published this in 1977. I kept staring at that year. Forty years later, IBM spent billions building Watson Health, a system that could match or exceed physicians at diagnostic tasks in controlled settings. The technology worked. The model accuracy was high. And it failed in the market because nobody redesigned the clinical workflow, the physician training, the trust relationship between doctor and algorithm, or the role definitions that a diagnostic AI would displace. The technology was technically present. The social system was theoretically absent. That is Sarker et al.'s (2019) Type I, their label for research where the IT artifact appears in the setting but does no theoretical work. Applied to practice instead of research: the system was present in the organization, but the organization around it was never redesigned to make the system work.

Bostrom and Heinen brought sociotechnical systems theory into the IS discipline at its very founding. The theory itself came from Trist and Bamforth (1951), who studied British coal mines where the longwall method optimized the technical subsystem for continuous production and collapsed the social subsystem in the process. Miners who had worked in autonomous teams were split across three specialized shifts. Absenteeism rose. Conflict between shifts became routine. Productivity fell below the old method. Trist and Emery formalized the lesson into the principle of joint optimization: you cannot design the technical system and then add people around it. The social and technical subsystems must be designed together because optimizing either in isolation degrades the whole system. Bostrom and Heinen took that principle and applied it to management information systems. The failures they observed were almost never caused by technology alone. They were caused by mismatches between the technology and organizational context, reward structures, decision rights, skill distribution, power dynamics.

Straub (2012), looking back at MIS Quarterly's history, called the Bostrom and Heinen papers "landmarks" in the development of sociotechnical theory within IS. Melville (2023) cites them as the foundation for putting humans back in the loop of the fourth industrial revolution. Piccoli et al. (2022) quote their definition of IT as "the technology needed to transform inputs to outputs." The papers are referenced constantly. And yet the pattern they identified has repeated across every technology wave since then.

IBM Watson Health is the clearest post-2010 example. The system could ingest medical literature at a scale no human could match. In controlled studies, its diagnostic accuracy matched or exceeded specialists. But the clinical workflow was never redesigned around it. Physicians had to open a separate interface and manually enter patient data. They could not see the system's reasoning, so they did not trust its recommendations. The accountability structure was unclear. The training was minimal. The result was not resistance to change. It was the exact pattern Trist and Bamforth documented in 1951. The technical subsystem was optimized. The social subsystem was not, and the system-level performance failed.

Google Health's AI for diabetic retinopathy screening followed the same path. The algorithm achieved over ninety percent accuracy in retrospective validation. In deployment, it could not handle the variability in retinal image quality across real clinics, the inconsistency in how technicians operated the cameras, and the absence of a referral pathway for positive results. The model was technically excellent. The social system of real clinical operations was treated as noise instead of as half the system needing design attention.

This is what Sarker et al. (2019) describe through their Transport Test. Take the entire implementation model and move it from an AI-assisted oncology clinic to a school with no computers. If the model still works as specified, the technology was not doing theoretical work in the original context. Apply that test to most failed enterprise AI deployments. The model accuracy transfers. The organizational design does not. The technology was theoretically removable from the organizational context, which is why the organizational context was never designed for it. Sarker et al. found that fifty-six percent of IS research is Type I on this measure. I suspect the proportion is similar for AI implementations in practice.

Joint optimization is not a feel-good principle about listening to users. It is a design constraint. The social subsystem is also purposeful in Ackoff's (1971) sense. It has its own goals, norms, power structures, and identity. It does not adapt passively to technical optimization. It reacts, resists, reshapes, and sometimes rejects the system. The organizations that succeed with AI deployment treat the social subsystem as a first-class design target. They redesign roles, not just interfaces. They retrain for new patterns of work, not just new tools. They create accountability structures that give humans the confidence to override or challenge the system. They do what the longwall method failed to do: design both subsystems together.

I wrote about the origins of this pattern in an earlier post on sociotechnical systems and joint optimization, the Trist and Bamforth story and what it means for digital transformation. The coal miners in Yorkshire are not that different from the radiologists in an AI-assisted reading room. The technology changes. The organizational dynamics do not.

Bostrom and Heinen (1977) should be required reading for every AI product manager. Not because the technology in that paper is relevant, it is not, but because the analytical lens is exactly what AI implementation needs. Ask yourself: is the social system being designed with the same rigor as the technical system? Are you optimizing the model, or are you jointly optimizing the model and the organization around it? If the answer is the former, you are repeating a pattern that has been documented for half a century. And the outcome will be the same, because the constraint has not changed. The technology was never the problem.