Skip to main content

Reading the Game

The thinking happens when you design the sign. The reading happens at speed.

The Improvement Loop runs after the game — DOCUMENT, MEASURE, ANALYZE, IMPROVE, STANDARDIZE. But during the game, a different loop runs. Faster. Less forgiving. The operator reads a picture, matches it to a predetermined response, acts within structure while adapting to what's actually there, then debriefs the decision — not the outcome.

Rugby calls it reading the game. Business calls it operational awareness. Both are the same cycle: pre-designed instruments read at speed by trained operators who have freedom within scaffolding.

The Cycle

Five phases. Design happens once. The other four repeat at the speed of the environment.

PhaseWhat happensRugbyBusiness
DesignBuild pictures before the gameGame plan, set plays, shape callsDashboard, KPI thresholds, response checklists
ReadScan the instrument at speedRead the field, see the gapRead the sign, match to threshold
ActExecute structure, read the momentRun the play, adapt off the ruckFollow checklist, adapt to conditions
DebriefReview decisions, not outcomesPost-match: what did we miss?Retrospective: what signal was late?
CompressDistil to what survives at speedMantra: "low body, fast hands"Setpoint: the number you carry without looking

The Sign

A bad KPI is a road sign pointing the wrong way. A good KPI is a predetermined decision compressed into a number.

The sign dictates the response, but only if you designed the sign well enough. Each state maps to a predetermined action — the thinking was done when the sign was built, not when it's read.

Sign stateWhat it meansPredetermined response
GreenWithin thresholdMonitor, don't intervene
AmberApproaching thresholdReview checklist, prepare response
RedThreshold crossedExecute predetermined workflow
BlackOutside known rangeEscalate, read environment, decide

Green, amber, and red are procedural knowledge — the response is already written. Black is where the operator earns their role. The checklist says what to check. It doesn't say what you'll find.

The Scaffolding

Structure enough to not freeze. Freedom enough to read.

In rugby, the set play off a ruck has a shape — first receiver, second receiver, runner lines. Every player knows the structure. But the halfback reads the defence. If the gap is on the short side, the call changes. The scaffolding held the shape. The read found the opening.

Business scaffolding works the same way. A response checklist for an amber KPI says: check these three things, in this order, report to this person. It doesn't say what the three things will reveal. The player who reads the picture through the scaffolding and acts on what's actually there — that's where value gets created.

Three properties of good scaffolding:

  • Constrains without scripting — limits the search space, doesn't dictate the answer
  • Survives contact — still useful when the situation deviates from the plan
  • Trains the read — repeated use builds pattern recognition, not dependence

The Debrief

Review the decision flow, not the outcome.

A try scored from a broken play is not proof the play works. A try missed from a good read is not proof the read was wrong. Debriefs that focus on outcomes teach luck. Debriefs that focus on decisions teach skill.

Three debrief questions:

  1. What did you see? — The picture the operator read at the moment of decision
  2. What sign was late? — Which instrument should have fired earlier
  3. What would you design differently? — Feed back into the Design phase

The debrief closes the loop back to Design. Every late sign becomes a redesign candidate. Every missed read becomes a training priority. The improvement loop runs on the same principle at a slower cadence — the debrief is the in-play version.

The Mantra

Compress the lesson until it survives at speed.

"Shape before contact." Three words. A rugby player carrying the ball into a tackle doesn't have time for a checklist. The mantra is what's left after the debrief strips everything that doesn't survive under pressure.

A dashboard is a picture you read when you have time to look. A mantra is a picture you carry when you don't. The compression sequence: dashboard → checklist → setpoint → mantra. Each stage strips detail and adds speed.

FormDetailSpeedWhen used
DashboardFullSlowPlanning, design
ChecklistStructuredMediumProcedure, response
SetpointSingle numberFastMonitoring, threshold
MantraWords onlyInstantUnder pressure, in motion

The Connection

PhaseVVFL stationProcess levelSite page
DesignIntention (setpoint)STANDARDIZEPictures, Control System
ReadMeasurement (gauge)MEASUREScoreboard
ActCorrection (controller)IMPROVEProcess Optimisation
DebriefValidation (verification)ANALYZETight Five Loops
CompressEvolution (learning loop)DOCUMENTPrompts, Mantra

Context

  • Control System — The setpoint-gauge-controller architecture that pictures implement
  • Pictures — How to design the visual instruments this cycle reads
  • Scoreboard — The gauge that measures whether the sign was right
  • Governing Metaphor — The scrum as binding force — shape, bind, direction
  • Process Optimisation — The improvement loop that runs after the game
  • Tight Five Loops — Feedback loop architecture — the debrief is one instance
  • Situational Wisdom — Embedded knowledge that survives at speed
  • The Game — Life as a game worth playing — the container this cycle serves

Questions

When the sign fires, how much of your response is predetermined — and how much requires a read?

  • Which of your KPIs are genuine predetermined decisions, and which are just numbers on a screen with no attached response?
  • Where in your operation does the scaffolding script the answer instead of constraining the search — and what read does that prevent?
  • When did you last debrief the decision flow instead of the outcome — and what did the difference reveal?
  • What lesson from your last failure has been compressed into a mantra that survives under pressure?