Sociotechnical Systems in Practice

You can distinguish between a headcount problem and a coordination system failure, and name why the informal mechanisms that made a small team work structurally cannot carry a large one.

You can identify which subsystem a proposed organizational intervention addresses, and name the gap it leaves on the other side.

You can recognize when a leadership team's impasse comes from the absence of a shared picture of the system rather than from disagreement, and identify the question that makes the impasse productive rather than circular.

You can define a sociotechnical system, explain why the Longwall coal mine case is relevant to software organizations, and identify the failure mode that occurs when one subsystem is improved without considering the other.

You can identify five key Cherns principles from 1976, match real organizational situations to the principles they violate, and explain why the friction with these principles is not a comprehension problem but a tooling problem - the social system has no equivalent of a pull request.

You can explain what full-lifecycle ownership means in software organizations, connect Vogels' "you build it, you run it" to the sociotechnical tradition, and articulate why the boundary between technical and social subsystems is a design decision rather than a discovered fact.

You can read a set of competing solution proposals as a diagnostic signal, and identify which part of the system each proposer can and cannot see.

You can apply the Stacey Matrix to classify an organizational problem along two axes, certainty and agreement, and name what the classification tells you about the appropriate type of intervention.

You can apply the Cynefin framework to refine a Stacey classification, and explain why Disorder, not Complicated, is the honest starting point for most organizational problems.

You can identify the failure mode of applying Cynefin as a situational autonomy switch, and formulate a durable enabling constraint for a Complex organizational problem instead.

You can identify why a structural reorganization failed to change organizational behavior - and name the Conway's Law mechanism that explains the gap.

You can distinguish between Conway's Law as a slogan and Conway's Law as a precise mechanism - and use the precise version to explain why a specific organizational intervention failed to produce the expected architectural outcome.

You can identify which proposed architectural changes also imply changes to communication structure - and explain why architectural change without planned communication structure change systematically fails.

You can identify when a scaling proposal violates a biological constraint - and explain why adding coordination mechanisms makes the underlying problem worse, not better.

You can classify the cognitive load carried by a proposed team structure - and identify where extraneous load makes a boundary unsustainable before the team is even formed.

You can evaluate a proposed team boundary for linguistic coherence - and identify where cognitive load from cross-domain translation makes a cut structurally unsustainable.

You can classify a proposed team structure using Team Topologies vocabulary - and explain why the four-type model is a design language rather than a scaling prescription.

You can identify the structural preconditions that made Spotify's org model work at Spotify - and explain why copying the structure without those preconditions reproduces the problems it was designed to solve.

You can assess whether an organization has reached the coordination scale that SAFe addresses - and name the cognitive load costs SAFe imposes before those conditions are met.

You can explain LeSS's scaling philosophy as structural subtraction - and identify the organizational and political conditions that determine whether subtraction is feasible in a given context.

You can construct a value chain for a software product - ordering its capabilities from user-visible to infrastructure - and explain why that ordering is the prerequisite for any team design decision.

You can position a software product's capabilities on the evolution axis - and identify where a mismatch between actual evolutionary stage and investment level is costing the organization competitive focus.

You can map a capability's evolutionary stage to a team energy type and a Team Topologies team type - and derive a Build vs. Buy recommendation from the same map.

You can identify when an organization is misdiagnosing an alignment problem as an autonomy problem - and explain why applying the wrong lever makes the underlying dysfunction worse.

You can name the specific alignment gap that is producing a team's dysfunction - and explain why alignment is not consensus, not process, and not quarterly planning.

You can select and formulate a structural alignment intervention for a given team or capability - matching the instrument to the Kniberg quadrant, not to the most available solution.

You can evaluate whether a Platform Team is warranted in a given organization - by reading CLT signals and Wardley evolution signals together, not by architectural instinct.

You can distinguish a Platform Team that shifts domains from one that merely relocates work - and articulate the Domain Shifting mechanism that makes the difference.

You can design the interaction model for a Platform Team - specifying what X-as-a-Service requires, how the Collaboration phase is bounded, and what the transition between them demands organizationally.

You can size a Platform Team correctly - applying the Thinnest Viable Platform principle and DORA health signals to distinguish what a platform must do from what it could do.

You can identify when a structural decision has been announced but not adopted, and explain the mechanism by which formal acceptance produces zero behavioral change.

You can distinguish identity resistance from structural resistance from information resistance, and explain why applying the wrong treatment to the wrong type makes each of them worse.

You can identify the informal communication structures that persist after a formal organizational change, and design interventions that target the informal layer, not just the formal one.

You can design a sequenced change plan for a specific structural transition, selecting and ordering Fearless Change patterns to address identity, structural, and shadow-org resistance in the right sequence.

You can design the quiet phase for a structural change: determining what the leadership team must align on internally, which steps cannot be communicated before a hard dependency is resolved, and which stakeholders need a sensing conversation before any announcement.

You can classify each step in a change plan as a hard dependency, a soft sequence, or a real experiment, and use a pre-mortem to identify where your classification is wrong before it costs you.

You can make an explicit communication decision for a structural change: naming what gets communicated to whom and when, and what gets deliberately withheld and why.

You can identify when AI agent adoption in a software organization is already changing its communication structure, and name the Conway mechanism that makes this consequential whether it was planned or not.

You can distinguish the three active positions in the Conway-and-AI-agents debate: name what each one claims, what evidence it rests on, and where each one breaks down.

You can articulate a reasoned position on Conway's Law in the age of AI agents, grounded in the course's diagnostic framework and specific enough to defend in a leadership conversation.