mcpbeat

Grad Sociotechnical

asgard-ai-platform/grad-sociotechnical

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
npx skills add https://github.com/asgard-ai-platform/skills --skill grad-sociotechnical

What comes with it

7 570 bytes besides the instruction
examples/sample_scenario.md

The instruction itself

13 sections, as written by the author

Sociotechnical Systems Theory (STS)

Overview

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
  • Individual-level technology acceptance (use TAM/UTAUT)
  • 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
  • Processes: workflows, procedures, task sequences
  • Physical environment: workspace layout, infrastructure
  • Variance: where in the process do deviations and exceptions occur?

Step 3 — Analyze interdependencies and misalignments

Map how changes in one subsystem affect the other. Look for:

  • Technical changes that eliminate worker autonomy or skill variety
  • Social structures that block effective use of technical capabilities
  • Variance that is handled by the wrong subsystem (e.g., automated where human judgment is needed, or manual where automation is appropriate)

Step 4 — Redesign for joint optimization

Apply STS design principles:

  • Minimal critical specification: specify only what is essential; leave room for worker discretion
  • Variance control: handle variance at its source, by those closest to it
  • Boundary management: ensure the work system can adapt to environmental changes
  • Support congruence: align reward systems, training, and management with the new design

Output Format

## Sociotechnical Analysis: [Work System / Organization]

### Social Subsystem
| Element | Current State | Issues |
|---------|-------------|--------|
| Roles & Skills | | |
| Team Structure | | |
| Culture & Norms | | |
| Worker Autonomy | | |

### Technical Subsystem
| Element | Current State | Issues |
|---------|-------------|--------|
| Technology | | |
| Processes | | |
| Environment | | |
| Key Variances | | |

### Interdependency Map
| Technical Change | Social Impact | Severity |
|-----------------|--------------|----------|
| | | |

### Joint Optimization Recommendations
| Principle | Current Gap | Recommended Action |
|-----------|-----------|-------------------|
| Minimal Critical Specification | | |
| Variance Control | | |
| Boundary Management | | |
| Support Congruence | | |

### Implementation Priorities
1. ...
2. ...

Gotchas

  • "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.