Eight frames for reading a floor.

Cynefin — choose the method by the domain

Most "method failures" are domain errors. Before you plan a change, know where the problem actually sits — complicated problems respond to analysis and best practice; complex ones require probing first. A complicated-world tool used on a complex problem fails not because it's bad, but because it's in the wrong domain. When standard work drifts despite training, when a metric looks fine but the operation isn't, the first question isn't "how do we push harder?" It's "are we in the right domain?"

Legibility first — standardize → automate

Standardize → automate is an order, not a menu — but how strictly depends on the domain (→ F1). Standardized data is the precondition for automation, digital twins and reporting anyone trusts. In a complicated, knowable environment — much of software — you can probe and automate with a lighter standard, because the same inputs reliably give the same outputs. On a complex floor, where they don't, skipping legibility is exactly what puts the project on sand. And resistance to a mandated standard is rational when the thing being changed is still invisible — the fix isn't to push harder, it's to make it legible first.

Shared signals — legibility as coordination

Most operational complexity is social. Many people, tacit knowledge scattered across them, and the constant cost of staying in sync — that's n² coordination links: every order, check, conversation. A shared signal cuts that to n: each person connects to the signal, not to every other person. Sun Tzu commanded armies this way — not by watching every soldier, but by drum and flag. Andon, a kanban card, 5S floor tape: the same logic, 2,500 years on. And it closes a loop: when the gap between the real method and the documented one is visible to everyone — including the person doing the job — the operation converges on the standard with no one enforcing it. Legibility doesn't just communicate; it coordinates. (This is also where Agile lives → F8.)

Tacit vs explicit — why the manual fails

A standard is an attempt to externalize tacit knowledge — and it's always partial. The drift between the documented method and the real one is almost never negligence; it's tacit knowledge correcting an incomplete standard. The operator who skips step 3 isn't being careless — they've learned that step 3 as written doesn't account for the variation that arrives every Tuesday. The retiring expert doesn't take their knowledge out the door because they're secretive; the knowledge was never legible enough to write down. The drift is a signal: it's the floor telling you the standard is wrong.

Vanity metrics — what OEE hides (Goodhart)

A green OEE can hide the exact loss it's meant to expose — not through dishonesty, but because that's what any single metric does once it becomes a target (Goodhart's law). OEE is an accounting metric: it's only as honest as the definition of "good" underneath it. File rework as "standard process" and a reworked unit still counts as good — OEE never sees it.

Goodhart isn't a dead end, though — it's a design rule. The way out isn't a more accurate OEE; it's anchoring at least one indicator to something you can't redefine. A physical metric — energy, mass, real time — obeys physics, not your accounting. An energy-per-unit indicator can't be flattered by overtime: rework burns the energy whether you book it as good or not. Read a physical measure against a counted one and the gap appears on its own — and that gap is the most useful signal you have. (This is exactly how an ISO 50001 energy indicator exposed an OEE that wasn't lying on paper — see Case 03.)

The sociotechnical seam — where change actually fails

Failures live at the interface between the technical design and the human system around it — joint causation, in the overlap. The human and organizational factors weigh at least as much as the technical ones, and get a fraction of the planning. A robotic cell can be technically flawless and operationally stranded because the operators have no visibility into which program is running and no way to detect a wrong parameter. The seam is where the design ends and the human experience begins. Design for the seam — not as an afterthought, but as a constraint from the start.

The 70% myth, and resistance as information

It's a phantom statistic — the sources cite each other in a loop, with no empirical ground. No one can trace it to data; the original author disowned it. The field can't agree on a definition of "change failure," which is itself a sign we're in a complex domain — one where the answer isn't measured, it's interpreted. The myth does real damage: it scripts resistance as something to overcome with more communication and more change management budget. But resistance is information. When people push back on a change, they're usually telling you something true about the gap between the plan and the floor. Investigate it — don't overcome it.

Agile — growing change in the complex domain

You can't plan a change whose outcome can't be known in advance. In the complex domain (F1), cause and effect only line up in hindsight — so a long, detailed plan aimed at a fixed target is a bet that the target won't move. It always moves. Agile is the answer: don't plan the whole change, grow it — deliver value in increments small enough that you learn and correct before the change has already failed. Probe, sense, respond.

Agile was written for software, and bolting "sprints" onto a furnace is naive — you can't iterate a casting cycle. What transfers isn't the ceremonies; it's the logic underneath: empiricism over prediction, tight feedback loops, working output over documentation. That logic is the only honest way to run a change you can't fully foresee — on a line or in a codebase.

The discipline is knowing which domain you're in. Agile on a complicated, knowable problem is overhead an expert could have planned away; a fixed plan on a complex one is the expensive bet. Most operations are both at once — the machine is complicated, the people changing around it are complex.

Which is why this frame sits at the end. Everything before it makes a change visible — the domain (F1), the sequence (F2), the signals that coordinate it (F3), what resists being made visible (F4), what hides in the numbers (F5), where it fails at the seam (F6), why it's resisted (F7). Agile is what makes a change correctable. A change becomes safe when it's both — see it, and grow it.