The origin story of sociotechnical systems theory is not a feel-good tale about teamwork. It is a cautionary tale about what happens when you optimize only the machines.
I keep reading the same phrase across IS papers: "the social and technical subsystems must be jointly optimized." Every time I see it, I wonder whether the person writing it has sat with what that actually costs. Joint optimization is not a platitude about listening to users. It is a hard constraint, and the evidence for it starts in a coal mine where optimizing only the machines made everything worse.
The story goes like this. In the late 1940s, British coal mines introduced the longwall method of coal-getting. The method broke a single shift of miners into three separate shifts, each doing one narrow task. Before the longwall method, miners worked in small, autonomous groups. Theycontrolled the entire cycle of extraction, from blasting to loading to transporting. They knew each other, they adjusted in real time, they took collective responsibility for output. The longwall method replaced that system with one designed around the technical requirements of continuous production. Each shift specialized. The work was technically efficient, or at least it looked that way on paper.
What Trist and Bamforth (1951) documented was the social collapse that followed. Absenteeism rose. Conflict between shifts increased. Miners on one shift would blame miners on the previous shift for problems they inherited. The social fabric that had made the single-group system resilient, the mutual support, the informal coordination, the shared identity, was gone. And productivity, the thing the longwall method was supposed to improve, fell below the levels of the old method. The technical optimization destroyed the social system, and then the social collapse dragged the technical performance down with it. This is not a story about resistance to change. This is a story about what happens when you optimize one subsystem in isolation and discover that the subsystem you ignored was not a luxury, it was load-bearing.
Trist and Emery formalized the lesson into sociotechnical systems theory. The core claim is deceptively simple: any organization contains a technical subsystem and a social subsystem, and optimizing either one alone degrades the performance of the whole. Joint optimization is the alternative. You design both subsystems together, explicitly accounting for how changes to one ripple through the other. The theory does not say "listen to users" or "put people first." It says the system has interdependent parts, and treating those parts as independently optimizable is not just incomplete, it is actively harmful.
Ackoff (1971) made the same point from a different angle. He argued that analyzing a system by decomposing it into parts and optimizing each part independently can degrade overall system performance, because the performance of a system depends primarily on how its parts interact, not on how well each part performs individually. A system with brilliant individual components and poor coordination will underperform a system with mediocre components and excellent coordination. Ackoff classified four system types: deterministic systems where neither parts nor whole are purposeful, animate systems where the whole is purposeful but the parts are not, social systems where both parts and whole are purposeful, and ecological systems where the parts are purposeful but the whole is not. IS research, he would argue, often treats sociotechnical systems as deterministic, decomposing them into components and optimizing each one separately, when in fact they are social systems whose parts and whole are both purposeful and whose interaction patterns cannot be reduced to component optimization.
When Bostrom and Heinen (1977) published their two papers in the very first volume of MIS Quarterly, they brought STS directly into the IS field. They argued that MIS problems and failures are almost always sociotechnical problems, not purely technical ones. The very first issue of the field's flagship journal opened with the claim that you cannot understand system failure without understanding the social system surrounding the technology. That is a remarkable editorial statement if you think about it. And yet Sarker et al. (2019) found that only about 13% of IS research actually operates at genuine sociotechnical interaction, what they call Type IV, where social and technical factors genuinely shape each other. The other 87% either treats technology as background, as a control variable, or as a deterministic force.
Mumford took STS further with her ETHICS methodology, a participatory design approach that insisted the people who would use a system should be involved in designing it. ETHICS stands for Effective Technical and Human Implementation of Computer-based Systems. The method asks designers to map both the technical requirements and the human requirements before any system is built. It is not a consulting framework or a box-checking exercise. It is a design discipline rooted in the same observation Trist and Bamforth made: if you design the technical system first and then try to fit people around it, you will produce the organizational equivalent of the longwall method.
Every time I read about a new technology failure, I see the longwall method. Hospital electronic health record systems are optimized for documentation and billing, the technical subsystem, while the social subsystem of clinical workflow, nurse-physician communication, and patient interaction is treated as an afterthought. The result is burnout, not because clinicians resist change, but because the system was designed around the wrong optimization target. Zoom fatigue is the same pattern. Video calls were technically optimized for continuous face-to-face presence, but the social norms around meetings, breaks, attention, and presence were never redesigned. The technical subsystem changed overnight. The social subsystem was left to figure it out alone.
The Boeing 737 MAX crashes are the clearest recent case. MCAS was a technical optimization that automated a stability correction. But the social system around it, pilot training, pilot awareness of the system, and the regulatory relationship between Boeing and the FAA, was not jointly optimized. The technical system was designed to act without full pilot awareness. When the social system could not compensate for a sensor failure that the technical system was not designed to handle alone, 346 people died. That is what happens when you optimize the technical subsystem and assume the social subsystem will adapt.
I think "move fast and break things" is the longwall method for software. It optimizes for technical iteration speed while treating the social systems around it, community norms, institutional trust, worker well-being, democratic discourse, as externalities. And just like the longwall method, it produces technical gains that are real but temporary, followed by social costs that compound. When people say "human-centered AI" or "human-in-the-loop," I think they are restating STS theory in modern clothing without citing it. The observation is the same one Trist and Bamforth made in 1951: the system with only technical optimization will underperform the system where both subsystems are designed together.
The frustrating part is that we have known this for over seventy years. The theory is not new. The evidence is not ambiguous. What keeps going wrong is the same thing Ackoff identified: we keep decomposing sociotechnical systems into their components and optimizing each one separately, then acting surprised when the system as a whole degrades. Joint optimization is not about being nice to users or adding a feedback loop at the end. It is a design constraint. You ignore it at your peril, and history keeps demonstrating that peril, from coal mines in Yorkshire to hospital wards in Chicago and airline cockpits over Java.