Apply Sociotechnical Systems Theory to analyze and design work systems through joint optimization of social and technical subsystems. Use this skill when the user needs to diagnose why a technology implementation disrupted work practices, design IT-enabled work systems that balance human and technical needs, or when they ask 'why did this system hurt productivity despite being technically sound', 'how do we design work around new technology', or 'why are people resisting this technically superior system'.
3k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
223
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
Sociotechnical Systems Theory, originating from the Tavistock Institute (Trist & Bamforth, 1951), holds that organizations are composed of interdependent social and technical subsystems. The social subsystem encompasses people, roles, relationships, and culture; the technical subsystem encompasses tools, processes, and technologies. Optimizing one subsystem in isolation degrades the other — effective design requires joint optimization of both.
When to Use
Designing or redesigning work systems that involve new technology
Diagnosing why a technically sound system implementation failed or caused resistance
Balancing automation with human autonomy and job quality
Planning IT-enabled organizational change that considers human and social factors
When NOT to Use
Pure technical architecture decisions with no human workflow impact
When the analysis scope is a single user interface, not a work system
Assumptions
IRON LAW: Optimizing the technical subsystem alone DEGRADES the social
subsystem (and vice versa) — joint optimization is required for system
effectiveness.
Key assumptions:
Organizations are open systems that interact with their environment
Social and technical subsystems are interdependent — changes in one propagate to the other
There are multiple ways to design a work system (equifinality); the best design jointly optimizes both subsystems
Workers should have autonomy to manage variance at the point where it occurs (minimal critical specification)
Methodology
Step 1 — Map the social subsystem
Identify the human elements of the work system:
People: roles, skills, knowledge, needs
Relationships: team structure, communication patterns, power dynamics
Culture: norms, values, informal practices
Autonomy: degree of control workers have over their tasks
Step 2 — Map the technical subsystem
Identify the technological and process elements:
Tools and technology: hardware, software, automation level
"Joint optimization" does not mean equal investment — it means neither subsystem is sacrificed for the other
STS originated in industrial/manufacturing contexts; translating to knowledge work and digital systems requires adaptation
The theory is prescriptive (how to design) but often used only as diagnostic (what went wrong) — push toward actionable redesign
Modern extensions (e.g., Clegg, 2000) add principles for information systems specifically — use these for IS projects
Do not confuse STS with simple "people + technology" checklists — the core insight is interdependence and joint optimization, not mere acknowledgment of both
Resistance to technology is often a rational response to social subsystem degradation, not irrational Luddism — investigate before dismissing
References
Trist, E. L., & Bamforth, K. W. (1951). Some social and psychological consequences of the longwall method of coal-getting. *Human Relations*, 4(1), 3-38.
Cherns, A. (1976). The principles of sociotechnical design. *Human Relations*, 29(8), 783-792.
Clegg, C. W. (2000). Sociotechnical principles for system design. *Applied Ergonomics*, 31(5), 463-477.
Mumford, E. (2006). The story of socio-technical design: Reflections on its successes, failures and potential. *Information Systems Journal*, 16(4), 317-342.
How to use it
Copy the folder
Take asgard-ai-platform/grad-sociotechnical from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
Check the name does not clash
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.