Humanistic Chaos

In one line

You think chaos engineering is about machines; in fact an organisation is itself a complex distributed system — people are nodes, communication is the network, process is the protocol. The four principles of chaos engineering — define steady state, form a hypothesis, vary real-world events, minimise blast radius — carry over unchanged to safely probe, and even safely change, an organisation.

Glossary

Where it sits

Chapter 10, the second chapter of Part III "Human Factors", written by Andy Fleener, who leads platform operations at SportsEngine, a SaaS company for youth and amateur sports. It follows Ch9's design sessions for surfacing blind spots in people's heads and precedes Ch11, People in the Loop. This chapter turns people from the observers of an experiment into its subject.

The problem this chapter tackles

A typical scene: a SaaS platform with multi-zone redundancy, where any database can fail over automatically. Yet in a major 3 a.m. outage, what actually slows recovery is human: the on-call engineer isn't sure whether to wake the database owner; three teams investigate in three chat channels; support finds out twenty minutes later. No single point of failure in the technology; single points everywhere in the organisation.

The usual approach has two blind spots. It shakes machines but not people: failure drills test automatic failover but never what happens when the person who knows most is absent. It changes organisations without experiments: new on-call rules or a reorg usually flip for everyone overnight, with no canary and no rollback switch — exactly the kind of release chaos engineering argues against on the technical side.

So the question is: can the methods of chaos engineering be applied to people and organisations, exposing organisational weak spots ahead of time and making organisational change as testable and reversible as a code change?

The core ideas, explained

1. Put the "socio" back in sociotechnical

The starting point is an often-ignored fact: the system in an incident is never just software. An alert fires, and everything after that — who sees it, how they judge it, whom they call, when they escalate — is human behaviour. An organisation is a system of systems: each team has its own goals, tools and habits, and teams are coupled by communication.

Seen this way, every familiar technical idea has a counterpart: nodes are people and roles, the network is communication channels, protocols are processes, a single point of failure is the one person who "is the only one who knows", and the round trips of conversation are the organisation's network latency.

2. Adaptive capacity: success and failure are one coin

The chapter takes the "new view" of resilience engineering: on most days nothing breaks not because there are no disturbances but because people keep adjusting, usually unseen — someone restarts a stuck job in passing, someone notices an odd metric and asks about it. Success and failure come from the same adaptive behaviour with different outcomes. (This is what Hollnagel calls Safety-II: studying why things usually go right, not only why they go wrong.)

So the engineering goal is not only "eliminate error" but grow adaptive capacity: more people who can spot weak signals and take over unfamiliar situations. Chaos experiments serve this by manufacturing the unexpected under control and seeing where adaptive capacity holds and where it snaps.

3. Carrying the four principles over to people

• Steady state: organisations have an observable "normal" too — how fast someone takes the IC role in a major incident, how fast the first external update goes out, how many people get pulled in.
• Hypothesis: "Without the person who knows this system best, the team can still locate the problem within the agreed time" — falsifiable, and written down beforehand.
• Vary real-world events: inject what genuinely happens — a key person on holiday or unreachable, the main chat tool down, a new hire's first on-call shift.
• Minimise blast radius: start in a drill, start with one team, stop at any time; participants know, and results improve process rather than grade individuals.

4. Three case studies from SportsEngine

The chapter grounds these principles in three cases from the author's platform operations team and the wider product development organisation. Each leaves one criterion worth taking away:

• Gaming Your Game Days: a game day should test not only whether machines heal but people — who commands, how information flows between teams, whether the runbook matches what people actually do. Criterion: if a game day ends with only technical findings and nothing about roles or communication, it exercised half the system.
• Connecting the Dots: weak signals before an incident are usually scattered across different people, each harmless on its own. Criterion: ask "who saw this signal, and whom would they tell?" If the answer is "nobody would say anything", that link in the organisation is broken — the same defect as an alert nobody subscribes to.
• Changing a Basic Assumption Safely: every organisation runs on premises everyone assumes and nobody has tested. Changing one is like shipping a risky release: write the hypothesis and success metrics, pilot small, watch steady state, keep a way back. Criterion: any organisational change should be able to answer "what is the blast radius, and how do we roll back?"

5. Communication is latency; leadership is emergent

In an incident, communication is the organisation's network latency: the same finding repeated in three channels and an IC unsure which message is newest amount to packet loss plus retransmission. ICS-style fixed roles (command, operations, external communication) and a single incident channel are, in effect, a protocol for that network.

The other observation is that leadership is an emergent property of the system, not a job title. Who coordinates an incident should follow from role and training, not seniority — so IC should be a rotating, trainable role, and experiments can test specifically "when the usual IC is away, can someone else step in?"

Key trade-offs and choices

Table one: the same principle, applied to machines versus people.

People learn and remember being "set up", so the blast radius of an organisational experiment must be measured in trust, not only in user impact.

Table two: choosing among organisational disturbances.

• The process lives in a few people's heads: write it out in a tabletop first, then run a game day.
• The team has an obvious hero: run a game day with the hero absent; it exposes knowledge single points fastest.
• You need to change a rule everyone assumes: don't flip it overnight; pilot it like a canary release, measure, keep a way back.

Why it matters / in real systems

ICS is itself a successful precedent for designing people as a system: it emerged from multi-agency firefighting during the 1970s California wildfires and was later widely borrowed for software incident response. This chapter goes one step further — don't just adopt the protocol; use experiments to check whether it actually works in your organisation.

Asked in an interview or design review "does your system have single points of failure?", answering with database replication is one level. Adding "we also check for people single points: game days remove the main owner, and IC is a rotating, trained role" shows you understand reliability as a property of a sociotechnical system.

Pitfalls and debates

• Turning "shaking people" into an ambush. Pulling someone without warning to watch the team flounder may expose problems short-term, but destroys psychological safety — next time nobody speaks honestly. That is precisely what "humanistic" is about.
• Grading people on the results. A drill tests process and organisation, not individuals; once results feed performance reviews, people perform for the drill.
• Assuming organisational experiments are repeatable. People learn, so the same drill is distorted the second time; keep varying the scenario rather than rerunning one script.
• Adopting only ICS vocabulary. An IC role that is never exercised and that only one person can fill is redundancy on paper.
• Metrics drowned in noise. Organisational changes have long cycles and few samples; a few weeks' change in "time to IC" is hard to attribute. Be honest about uncertainty.
• Limits. The chapter rests mainly on one company's practice, with little cross-organisation quantitative evidence; for small teams, dedicated human experiments may cost more than they return. But it pushes the boundary of reliability from machines to organisations, setting up Ch11 and Ch18.

Key takeaways