Technology Is Never Only Technical

By the end of this lesson, you will be able to...

• Distinguish a component diagram from a sociotechnical system model.

• Draw a useful system boundary that includes software, people, rules, incentives, and institutions.

• Trace how a technically correct workflow can still produce a harmful or unfair outcome.

Idea in one sentence: A technological system behaves through code, people, rules, incentives, and resources acting together, so reviewing only the software leaves part of the mechanism invisible.

Core Insight

A city launches an online portal for housing-support applications. The portal collects forms, checks required documents, creates a case, and places that case in a queue for a caseworker.

The technical design looks sensible:

application form
      |
      v
document check -> case database -> caseworker queue -> status message

The team tests the form. Required fields work. Documents upload correctly. Cases enter the queue in the right order. Status messages are sent. From the component diagram, the portal works.

Three months later, the city notices a pattern. Applications from people with unstable internet access are closed more often. The portal gives applicants seven days to upload missing documents. The reminder is sent by text message to one phone number. Caseworkers are measured by how many cases they close each day, so an incomplete case is faster to close than to investigate. Community organizations have learned to call a supervisor when an applicant loses access, but that workaround is not visible in the software.

No single component is obviously broken. The form validates correctly. The deadline rule runs correctly. The queue works as configured. The text message is sent.

Yet the system is producing unequal access.

The mistake is not merely that the team forgot a user story. The deeper mistake is treating the software as the whole system. The outcome is produced jointly by the portal, the deadline policy, access to phones and documents, caseworker incentives, staffing, and informal repair paths.

The Naive Boundary

A boundary tells us what we are treating as part of the system for the decision in front of us.

The portal team begins with a narrow boundary:

inside: form, validation service, database, queue, messaging service
outside: applicants, caseworkers, policy, staffing, document access

That boundary is useful for some questions.

• Does the upload endpoint accept the expected file type?
• Does every submitted application create one case?
• Does the message service retry after a temporary failure?

But it cannot answer other questions.

• Who can complete the workflow under the seven-day deadline?
• What happens when the text message reaches a shared or disconnected phone?
• Why does a caseworker close an incomplete case instead of calling the applicant?
• Who can contest an automatic closure?

The narrow boundary does not make the technical tests wrong. It makes them incomplete for a decision about access, burden, or accountability.

This is the first important move: a system boundary is chosen, not discovered. Different questions require different boundaries.

From Technical Product to Sociotechnical System

Plain meaning:

A technical product never acts alone. People interpret its outputs, rules constrain its options, incentives shape behavior, and institutions decide what counts as success or failure.

In this scenario:

The portal does not close an application by itself. Closure emerges from a validation rule, a seven-day policy, a message channel, the applicant's circumstances, the caseworker's workload, and the city's performance metric.

Technical name:

This is a sociotechnical system: a system whose behavior is produced by interacting technical and social parts. “Social” here does not mean casual conversation or social media. It includes people, roles, procedures, incentives, authority, institutions, and material conditions.

The technical and social parts are not two independent boxes connected at the end. They shape each other.

• The portal makes the seven-day policy automatic and repeatable.
• The policy determines which states the portal must represent.
• The closure metric changes how caseworkers use the queue.
• Caseworker workarounds hide failure from product analytics.
• Applicants adapt by seeking help from community organizations.
• Those organizations become an unofficial support layer without formal authority or funding.

The full behavior appears only when these interactions are visible.

A Coupled-System Sketch

Start with five kinds of elements. They are not a universal checklist, but they are a good first sketch.

Now connect them around one outcome:

missing document
      |
      v
portal starts seven-day timer <--- policy defines the deadline
      |
      v
text reminder sent -----------> applicant may not receive it
      |
      v
case stays incomplete --------> closure metric rewards quick resolution
      |
      v
caseworker closes case --------> applicant must find an appeal path
      |
      v
closure appears as throughput, not as failed access

The final line matters. The reporting system may classify the closure as completed work. The metric then tells managers that throughput improved. A technical success signal can hide a social failure.

Worked Trace: One Application Through Two Models

Consider Ana, who submits an application from a public library computer.

Step 1: Input

Ana completes the form but cannot upload one income document. The document is stored in an email account she cannot access from the library computer.

The portal accepts the application and marks it missing_document.

Step 2: Automated transition

The portal starts a seven-day timer and sends a text reminder. Ana recently changed phone numbers, so the message reaches an inactive number.

The messaging service records delivered because the mobile network accepted the message. It cannot know whether Ana read it.

Step 3: Intermediate human state

The case enters a caseworker queue. The dashboard shows 42 open cases and highlights cases near the deadline. Caseworkers are evaluated partly by daily closure count.

Calling Ana would require searching another system for contact details and writing a manual note. Closing the incomplete case takes one click.

Step 4: Output

On day eight, the caseworker closes the application. The portal records a valid state transition. The city's report counts one resolved case.

Ana experiences a different output: no housing support and no clear explanation of how to recover.

Step 5: Naive failure contrast

The technical-only model says:

The workflow executed correctly. The applicant missed the deadline.

The sociotechnical model says:

The outcome was jointly produced by document access, a fixed deadline, one contact channel, queue design, staffing, a closure incentive, and a weak recovery path.

The second statement does not automatically assign blame or prove discrimination. It creates a better object for investigation. Each link can now be checked with evidence.

Check: If the team adds message retries but keeps the old phone number, fixed deadline, closure metric, and appeal path, has it repaired the system?

Think first, then reveal.

Answer: It has repaired one delivery failure, but not the coupled mechanism. Retrying a message to an inactive number does not improve document access, caseworker incentives, or recovery after closure. The repair is technical, while several causes remain outside the technical boundary.

Choosing a Useful Boundary

If every relevant person, institution, market, historical cause, and future consequence enters the diagram, the map becomes unusable. “Everything is connected” is true in a weak sense, but it does not guide a decision.

Use the decision to shape the boundary.

For the question “Should we change how incomplete applications are handled?”, include an element when at least one of these is true:

1. It changes whether an application advances, waits, fails, or recovers.
2. It changes who carries time, cost, risk, or proof burden.
3. It has authority to set a rule, override a decision, or repair an error.
4. It produces a signal used to judge success.
5. It predictably adapts when the system changes.

This creates a bounded map:

core workflow:
portal + messages + queue + caseworker actions

operating environment:
staffing + performance metrics + support channels

institutional environment:
evidence policy + deadline authority + appeal rights

You can zoom between these layers. You do not need the whole city government in every diagram. You do need the parts that can change the outcome under review.

What the Wider Model Changes

Once the boundary is wider, the design conversation changes.

Instead of asking only “How do we make the upload flow more reliable?”, the team can compare interventions at several points:

No single intervention solves the whole system. That is normal. The wider model helps the team place changes where they can affect the mechanism, then define what evidence would show whether the change worked.

It also makes ownership more precise. Engineering may own notification state. Operations may own queue handling. Policy leaders may own deadlines and evidence rules. No team should be assigned responsibility for a lever it cannot move.

Trade-offs and Limits

A sociotechnical boundary improves visibility, but it has a cost.

• A wider map takes more time to build and validate.
• More actors and rules create more disagreement about causality and ownership.
• Some evidence will be missing, especially for people who leave the process silently.
• A map can become a performance: many boxes, no changed decision.

The central trade-off is between clarity and completeness. A narrow technical model is easy to inspect but may omit decisive causes. A very broad model may capture more context but become too vague to test or act on.

This approach also has limits.

• It does not prove that one factor caused an outcome. That requires evidence.
• It does not decide which values should win when they conflict.
• It does not guarantee that every affected person has been identified.
• It does not replace detailed security, privacy, legal, or policy analysis.

You can see the boundary failing when important outcomes repeatedly appear as “external surprises,” when workarounds grow outside the official workflow, or when the people who bear the cost have no path into the system's feedback.

Common Confusions

Confusion: “The technology works; the problem is user behavior”

Why it is tempting:

The software may satisfy every specification, while users miss deadlines, enter unexpected data, or create workarounds.

Better model:

User behavior is often part of the operating mechanism. Ask what information, incentives, constraints, and recovery options shape that behavior. This does not mean every user action is caused by the product. It means the review should not label predictable interaction as external noise.

Confusion: “Sociotechnical means adding humans to the architecture diagram”

Why it is tempting:

Adding a box named caseworker appears to widen the model.

Better model:

The important part is the coupling: what the caseworker can see, which action is cheap, which metric matters, who can override a closure, and how the portal changes those choices.

Confusion: “A wider boundary must include everything”

Why it is tempting:

Once hidden dependencies become visible, stopping the expansion can feel arbitrary.

Better model:

Every boundary is selective. Include elements that can change the decision, distribute burden, exercise authority, produce success signals, or adapt to the intervention. Record important omissions instead of pretending the map is complete.

Check: A dashboard reports that application processing time fell by 20%. What must you inspect before calling the portal successful?

Think first, then reveal.

Answer: Inspect how the metric is produced and distributed: whether more cases are being closed as incomplete, who waits or exits, whether appeals increased, and whether caseworkers changed behavior to improve the measured number. Faster processing can reflect a better service or faster exclusion.

Practice: Repair the Boundary

A company introduces a shift-scheduling tool. Managers enter staffing needs. The tool assigns shifts using worker availability and sends notifications. After launch, unfilled shifts decrease, but late cancellations and worker turnover increase.

Draw a small sociotechnical map for the decision “Should the company change the scheduling process?” Include:

1. The core technical workflow.
2. Two human roles and what each can see or change.
3. One rule or policy that shapes the schedule.
4. One incentive or resource constraint.
5. One feedback or repair path.
6. One important omission that you would investigate later.

Then write one sentence describing how the system could be technically correct while producing a poor outcome.

Use this rubric to review your answer:

• Boundary: The map includes more than software components but remains tied to the scheduling decision.
• Coupling: At least one connection explains how a rule, incentive, or human action changes technical behavior or its outcome.
• Distribution: The map shows who receives flexibility and who carries cancellation or availability burden.
• Feedback: A worker can report, contest, or repair a harmful assignment, or the missing path is named.
• Uncertainty: The answer distinguishes a plausible mechanism from a proven causal claim.

A strong answer might connect manager staffing targets, worker availability data, an attendance penalty, notification timing, and a cancellation appeal path. It would not stop at “the algorithm made bad schedules.”

Resources

• [BOOK] Design Justice - Focus on how design processes define who participates, who benefits, and whose knowledge counts.
• [ARTICLE] Value Sensitive Design - Focus on methods for connecting human values to concrete technical and design choices.
• [BOOK] The Alignment Problem - Focus on cases where technical objectives interact with institutions, data, and social consequences.

Key Takeaways

• A component diagram can be correct while its boundary is too narrow for questions about access, burden, power, or accountability.
• A sociotechnical system produces behavior through software, people, rules, incentives, resources, and institutions acting together.
• A useful boundary follows the decision: include elements that change outcomes, distribute burden, exercise authority, produce success signals, or adapt.
• The main trade-off is clarity versus completeness. Wider models reveal hidden causes but become harder to validate and act on.
• A sociotechnical map should lead to testable questions, assigned ownership, and a changed decision—not merely a larger diagram.