Work System Design in Practice

Key Principles

The four frameworks covered in this series are not alternatives to one another — they address different questions and operate at different resolutions. Combining them requires understanding what job each framework does.

1. STSE as a structured design process, not a checklist

Sociotechnical Systems Engineering (STSE) exists precisely because traditional system development approaches failed to account for organizational and social dimensions during implementation. It bridges organizational change work and technical system design by integrating research on work design, information systems, CSCW, and cognitive systems engineering. STSE operates through two complementary activities: sensitization and awareness-building (surfacing the sociotechnical context), and constructive engagement (actively shaping the design with that context in view).

The implication is that analysis and design are not cleanly sequential. Constructive engagement produces new awareness; awareness-building informs construction. Expect iteration.

2. Analytical frameworks need empirical inputs

No amount of framework expertise compensates for bad situational data. Ethnographic methodology is well-suited to STS analysis because it reveals emergent properties, unintended consequences, and actual patterns of human-technology interaction that formal or quantitative approaches systematically miss.

Participatory design extends this further: workers closest to the technology are not merely data sources — they are co-designers. The underlying theory is that operational performance and worker satisfaction both improve when the knowledge and capabilities of workers are leveraged to handle technological uncertainty, variation, and adaptation. Workers gain from the challenge, variety, and responsibility; organizations gain from better technical outcomes.

3. Cherns principles as evaluative criteria for any proposed design

The two most structurally important Cherns principles for multi-framework synthesis are variance control and boundary management.

Variance control states that deviations from expected performance should be controlled as close as possible to their origin rather than being exported across organizational boundaries. If a team must escalate most of its variances to another team or to management, the boundary is mislocated.

Boundary management states that organizational and system boundaries should facilitate coordination and information flow rather than hinder it. The placement of boundaries determines which variances must be handled within a team versus across team interfaces — poor placement multiplies coordination cost.

Minimal critical specification provides a third evaluative lens: a design that over-specifies how work should be done will prevent the self-organization that enables teams to absorb variance and adapt. Be precise about what must be accomplished; leave how mostly to the team.

Together these three principles allow you to audit a proposed team topology without needing to construct a full analytical model: does each team control the variances it encounters? Are boundaries placed where coordination is cheap? Does the design leave teams room to determine their own methods?

4. VSM diagnoses structural completeness; leverage points diagnose intervention impact

The Viable System Model specifies five necessary and sufficient subsystems for any viable organization: System 1 (Operations), System 2 (Coordination), System 3 (Operational Control), System 4 (Development/Intelligence), and System 5 (Policy). The absence of any subsystem predicts eventual failure to maintain viability. VSM diagnosis tells you what structural capability is missing or atrophied.

Meadows' leverage point hierarchy tells you something different: given that a structural problem has been identified, which type of intervention will actually change the system? Parameter changes (adding resources, adjusting targets) are the weakest interventions. Improving information flows, changing rules, and altering feedback loop strengths operate at higher leverage. Paradigm shifts — changing the goals or mental models from which the system operates — are the most powerful and the most difficult.

VSM tells you where the gap is. Meadows tells you at what level to intervene to close it.

A common failure pattern: a team has diagnosed a missing System 4 (the organization has no real development intelligence function — it is not scanning the environment and translating that into structural change). The first instinct is to add a roadmap or a strategy offsite (parameter change, very low leverage). A higher-leverage intervention changes information flows — who gets what signals, when, and with what authority to act on them. The highest-leverage intervention changes the system's goal or the mental model that governs what "development" means in the organization.

5. Wardley mapping as a situational awareness and team-alignment tool

Wardley mapping bridges business strategy and organizational architecture by making the evolutionary stage of capabilities explicit. Components at different evolutionary stages require different organizational approaches:

• Genesis components need innovation-focused teams with high autonomy and tolerance for waste.
• Custom-built components need capability-building teams with strong engineering practices.
• Product components need optimization-focused teams oriented toward user outcomes.
• Commodity components need efficiency-oriented teams (or should be outsourced entirely).

This is not merely a resourcing guide. Applying a commodity-style team structure to a genesis-stage capability will systematically suppress the exploration and failure tolerance that genesis work requires. Applying a genesis-style team to a commodity capability wastes investment and introduces unnecessary variance. The Architecture for Flow framework formalizes this integration with Domain-Driven Design and Team Topologies, creating a complete sociotechnical alignment method.

6. Digital transformation as a stress test for all five principles

Digital transformation requires joint optimization of technical systems and organizational structures — simultaneous changes across strategy, organizational design, work practices, services, and organizational identity. Treating digital change as a technical deployment without corresponding organizational redesign is a well-documented source of unintended consequences. Remote work, platform dependencies, and AI-assisted work create new STS challenges by shifting where variances originate, how boundaries are drawn, and which teams have the information and authority to respond.

Step-by-Step Procedure

This procedure integrates all four frameworks into a structured work system design or redesign effort. It corresponds to the STSE dual-activity model: steps 1–3 are primarily sensitization and awareness-building; steps 4–7 are constructive engagement.

Step 1: Define the system boundary and gather situational data

Before applying any framework, you need empirical input. Use ethnographic observation and participatory methods to generate a picture of:

• Who does what, with what tools, under what conditions.
• Where variances occur most frequently and how they are actually handled.
• What formal structures say versus what informal coordination happens in practice.
• Where people are routinely blocked, escalating, or working around the system.

Do not skip this step to go straight to framework application. The frameworks will produce plausible-sounding but wrong diagnoses if applied to assumed rather than observed work.

Step 2: Run a Wardley map of the organizational context

Map the key capabilities, services, and dependencies from the perspective of user need. Identify where each capability sits on the genesis-to-commodity axis. This establishes:

• Which capabilities are strategically differentiated versus commodity.
• Where evolutionary stage and current team structure are mismatched.
• What is likely to move toward commodity over the planning horizon (and thus needs a different team approach in 18-24 months).

This provides situational awareness that the other frameworks lack on their own.

Step 3: Run a VSM structural diagnosis

Map your organizational system against the five VSM subsystems. For each subsystem, assess: does this function exist? Is it well-resourced? Does it have the information and authority it needs?

Common gaps to watch for:

• No real System 4 (the organization lacks an environmental scanning and adaptation function — it is operationally absorbed and cannot develop).
• System 3 acting as System 4 (management is occupied with operational control and has no capacity for development intelligence).
• System 2 missing or informal (teams coordinate ad hoc; there is no systematic dampening of oscillation between System 1 units).

Document which subsystems are structurally weak. This is the diagnostic input for Step 5.

Step 4: Identify key variances and boundary placement

Using the work system data from Step 1, conduct a variance analysis:

• List the major categories of variance (things that deviate from expected performance).
• Identify where each variance originates.
• Identify where it is currently controlled (who handles it, at what level, after how many handoffs).

Assess whether variance is being controlled close to origin or exported across boundaries. Wherever significant variance is consistently being exported upward or laterally, the boundary is mislocated or the team lacks the capability and authority to handle what it owns.

Step 5: Map VSM gaps to Meadows leverage points

For each structural gap identified in Step 3, consider:

• What type of intervention is currently being attempted? (Most organizations default to parameter changes — adding resources, adjusting targets — which have low leverage.)
• What would a higher-leverage intervention look like? In particular, ask what information flows would need to change, what rules govern the function in question, and what feedback loops currently exist or are missing.
• Is the root cause a paradigm or goal problem? If System 4 is permanently absent, it may be because the dominant model holds that adaptation is management's job, not a systemic function. A rules or information-flow intervention will not fix a paradigm problem.

Rank your candidate interventions by leverage level. This prevents investing effort in low-leverage change while avoiding high-leverage interventions.

Step 6: Apply Cherns principles to evaluate the proposed design

Once a candidate design has emerged (from Steps 2–5, informed by Step 1), evaluate it against the three core principles:

1. Variance control: Does each team own and control the variances it encounters most frequently? If a team regularly exports variances to another team, why? Is it a capability gap (fixable with investment), an information access problem (fixable with boundary or tooling change), or a structural boundary problem (the wrong things are grouped together)?

2. Boundary management: Are boundaries positioned to facilitate information flow and coordination? Team boundaries that cut across a shared technical dependency or a shared customer interaction will consistently generate coordination overhead. Do the boundaries in the proposed design track functional domains or deployment units?

3. Minimal critical specification: Does the design over-specify how work gets done? If the design includes mandated processes, required ceremonies, or specified handoffs that exist because of assumed incapacity rather than actual constraint, remove them. Retain what is genuinely essential; leave method to the teams.

Step 7: Validate with participatory review

Return the proposed design to the people who will work in it. This is not sign-off — it is input. Workers closest to the technology will identify failure modes that the frameworks missed, practical conflicts between the design and operational realities, and improvement opportunities that the analytical view cannot surface. Redesign based on what you learn. Expect at least one significant adjustment.

Annotated Case Study

Platform engineering team restructuring at a mid-scale SaaS company

Context. A Series C SaaS company has grown from 30 to 180 engineers over three years. The engineering organization is structured as eight product teams plus a platform team. The platform team is responsible for CI/CD, observability, developer tooling, and the shared data infrastructure. The CTO has commissioned a redesign because deployment frequency has dropped, platform incidents are increasing, and product teams are consistently blocked on platform work.

Step 1: Ethnographic observation output.

Two weeks of shadowing — attending standups, watching oncall handoffs, sitting in incident reviews, and conducting structured interviews with engineers and team leads — surfaced the following:

• Product teams cannot deploy independently; all deployments require a platform team review step. Product teams export this variance to the platform team as a matter of course.
• The platform team has no slack. All bandwidth is consumed by reactive work: reviewing deployments, investigating incidents, responding to unblocking requests.
• There is no formal coordination layer between product teams on shared infrastructure. When two product teams need incompatible changes to the same data pipeline, resolution happens through informal negotiation, often late in the delivery cycle.
• The platform team lead has a mental model of their role as "gatekeeping quality" rather than "accelerating product teams." This shapes every staffing and prioritization decision they make.

Step 2: Wardley map.

Mapping the platform capabilities reveals:

• CI/CD tooling is commodity (standard tools exist; no competitive differentiation is possible here).
• Observability tooling is in product stage (significant vendor maturity; most teams can use SaaS observability rather than custom infrastructure).
• The shared data pipeline is custom-built (genuinely differentiated; it encodes business logic that competitors cannot easily replicate).
• Internal developer platform (IDP) practices are genesis (the organization is still learning what self-service should mean for their context).

The current team structure treats all four of these as equivalent platform concerns. This is a mismatch: commodity and product-stage capabilities are consuming team capacity that should be focused on the custom-built and genesis work.

Step 3: VSM diagnosis.

The platform team, examined as a system:

• System 1 (Operations): present but overwhelmed. The operational load has crowded out all other functions.
• System 2 (Coordination): absent. There is no mechanism for dampening oscillation between product teams on shared infrastructure. Conflicts resolve through informal escalation to the platform team lead.
• System 3 (Operational Control): performed informally by the platform team lead, but with inadequate information and no capacity for anything other than reactive response.
• System 4 (Development/Intelligence): effectively absent. The platform team has no bandwidth to track the external evolution of platform tooling or to develop a coherent architecture roadmap.
• System 5 (Policy): unclear. There is no articulated platform policy — what the platform is for, what it owns, and what it enables product teams to own independently.

Annotation. The VSM diagnosis reveals that this is not primarily a staffing or tooling problem. The system lacks the structural functions required for viability. Adding engineers to System 1 without building Systems 2, 4, and 5 will delay but not prevent the same pattern recurring.

Step 4: Variance analysis.

The two most damaging variance exports:

1. Deployment readiness variance: product teams export deployment safety checks to the platform team rather than owning them locally. This is a boundary problem.
2. Shared infrastructure conflict variance: product teams export coordination over shared data infrastructure to the platform team rather than to a coordination mechanism. System 2 is missing.

Step 5: Leverage point analysis.

The CTO's initial instinct: hire more platform engineers (parameter change, lowest leverage). The ethnographic data points to higher-leverage interventions:

• Information flow intervention: Instrument and publish real-time platform health and capacity signals visible to all product teams. Currently product teams have no visibility into platform load before they generate more of it.
• Rules intervention: Redefine the platform team's mandate as enabling product-team self-service rather than gating deployments. This changes what work the platform team is authorized to decline and what product teams are required to own.
• Paradigm intervention: The platform team lead's model of "gatekeeping quality" is the root cause of the deployment review bottleneck. The organizational design will not change until this mental model changes. This requires active reframing, not just a reorganization chart.

Step 6: Proposed design evaluated against Cherns.

Proposed redesign: dissolve the platform team into four functional groups aligned to the Wardley analysis (commodity abstraction, observability, data platform, IDP enablement), introduce a platform guild as System 2 coordination mechanism, and transfer deployment ownership to product teams with self-service tooling support.

• Variance control: product teams now own deployment variance. IDP team owns the tooling that makes self-service safe. Data platform team owns shared pipeline variance. Each team controls its own domain.
• Boundary management: boundaries now track evolutionary stage and domain rather than the catch-all "platform" label. The guild provides lightweight cross-team coordination without creating a bottleneck team.
• Minimal critical specification: deployment process is specified by outcome (safe, auditable, reversible), not by procedure. Teams choose their own deployment approach within those constraints.

Step 7: Participatory review output.

The proposed IDP team structure assumed that the two most senior platform engineers would lead it. In participatory review, those engineers flagged that neither of them has IDP experience and that the role requires sustained external learning investment, not just senior technical judgment. Revised: one senior platform engineer plus a new hire with dedicated IDP background; the two senior engineers move to the data platform team where their existing knowledge is directly applicable.

Active Exercise

Multi-framework diagnostic sketch

Setup. Think of a team or system you are familiar with — your own, a client's, one you have been asked to advise on. It should be a situation where things are not working as well as they should. You do not need to know the root cause; that is what the exercise produces.

Task. Complete the following diagnostic sketch. Write two to three sentences per question. Do not produce a full report — the goal is to develop the habit of applying each framework distinctly before synthesizing.

1. Ethnographic grounding. What do you actually observe people doing, as opposed to what the org chart or process documentation says they do? Where is the informal coordination? Where are the workarounds?

2. Wardley positioning. Pick the three or four most important capabilities in the system. Where does each sit on the genesis-to-commodity axis? Is the team structure aligned to those evolutionary stages, or mismatched?

3. VSM gap scan. Which of the five VSM functions (Operations, Coordination, Operational Control, Development/Intelligence, Policy) is weakest or absent? How does its absence manifest in observable behavior?

4. Variance audit. Where are variances being exported? Who ends up handling problems that should be handled elsewhere, and why?

5. Leverage point ranking. What interventions are currently being tried or proposed? What leverage level do they operate at? Is there a higher-leverage intervention that is not on the table — and if not, why not?

6. Cherns evaluation. Does the current or proposed structure violate variance control, boundary management, or minimal critical specification? Which violation is doing the most damage?

Debrief. Review your answers across all six questions. Where do they converge on the same root cause? Where do they point to different problems? The convergence zone is where to focus; the divergence zone is where you need more data.

Boundary Conditions

When this approach is too slow

The multi-framework diagnostic requires time, observation access, and willingness to revisit assumptions. In a genuine crisis — a production system is failing, a critical team has imploded, a deadline is immovable — the diagnostic depth described here is not available. In crisis, use the simplest applicable framework (usually VSM for structural triage, Cherns for design evaluation) and return to fuller analysis once immediate stability is restored.

When the organization will not support participatory design

Participatory design requires that workers have meaningful input into design and exert control over implementation. In organizations where leadership treats consultation as a performance rather than a genuine input channel, participatory methods will generate false confidence. Workers will disengage, provide socially acceptable rather than honest input, and disengage from implementation. If the organizational culture does not support genuine participation, the analytical frameworks can still be applied — but implementation risk increases substantially, since the practitioner is missing the local knowledge that participation surfaces.

When evolutionary stage is contested

Wardley mapping requires judgment about where a capability sits on the evolution axis. Teams and leaders frequently disagree, often because they have different information. A team that has built a capability from scratch will often perceive it as more custom and differentiated than external analysis suggests. This disagreement is itself a diagnostic signal — it often indicates a missing System 4 (no function is scanning the external environment for comparable solutions). Do not shortcut the disagreement by imposing a position; the process of resolving it generates useful alignment.

When the problem is political, not structural

The frameworks in this series model sociotechnical systems in terms of structure, information flows, and design principles. They have less to say about cases where the problem is primarily political — where a structural fix is blocked by power dynamics, where key actors are protecting local interests against system-level optimization, or where a paradigm shift is required but the people who hold the current paradigm have the authority to prevent change. In these cases, the frameworks remain useful for diagnosis and for identifying what a functional system would look like — but the path from diagnosis to implementation runs through organizational politics, not design method.

Digital transformation as a persistent boundary condition

Digital transformation initiatives create a persistent challenge for multi-framework diagnosis: the system under analysis is changing during the analysis. Platform dependencies shift, AI-assisted work tools are introduced mid-cycle, remote and asynchronous work patterns alter where variances originate. Treat the diagnostic as a snapshot, not a definitive map. Build reassessment points into any redesign initiative, and prefer designs that are structurally adaptive — flexible organizational forms, minimal critical specification, self-service capabilities — over designs that require stable conditions to function.