Visual Management
Visual management makes work visible. That is not the same as making the constraint visible. When the two are confused — when the Kanban board shows where work is piling up but nobody asks why it is piling up there — visual management becomes a sophisticated way of recording the problem rather than solving it. This is the honest guide to what visual management can and cannot do — and the one question that determines which one you have.
A Kanban board makes work visible. It does not make the constraint visible. When the two are confused, the board becomes a sophisticated way of recording the problem rather than solving it. The pile of work on the board shows you where work is accumulating — not why it is accumulating there, and not what structural feature of the system is producing the accumulation.
The one question that determines whether visual management is working: has seeing the work pile up changed what the system does, or only changed what the team talks about? Bootstrap CUSUM on the outcome metric answers that question honestly.
☰ Contents
What visual management is
Visual management is the practice of making the state of a system visible to the people working within it — through charts, boards, indicators, signals, and displays at the point of work. The underlying principle is simple and correct: you can only manage what you can see. If the system state is invisible, decisions will be made on assumptions, reports, and memory rather than on current reality.
Toyota developed visual management as part of the Toyota Production System. The Andon cord — which any worker could pull to stop the production line when a defect was detected — is the most famous example. It made quality problems visible immediately, at the point of occurrence, to everyone with authority to act on them. The information did not travel upward to a report or a meeting. It was present in the environment, visible to everyone, demanding an immediate response.
The principle is sound. The application in most organisations is not.
The critical distinction
Visual management in Toyota’s original conception made the constraint visible — the specific point in the system where quality failed, where flow was interrupted, where throughput was limited. The Andon cord did not just show that work was happening. It showed that something had gone wrong at a specific point and needed immediate attention.
In most adoptions of visual management, the constraint-identification function was lost and the work-tracking function remained. The Kanban board shows where work is. It does not show why it is there, what structural feature is causing it to accumulate, or what would need to change for the accumulation to stop.
The two questions visual management must answer
For visual management to produce structural change rather than sophisticated problem recording, it must answer two questions — not just one:
- Where is work accumulating? (Most Kanban boards answer this)
- What structural feature of the system is causing the accumulation? (Almost no Kanban boards answer this)
The first question makes work visible. The second question makes the constraint visible. Both are necessary. The first without the second produces a board that records the problem. The second requires a different instrument — the six-phase constraint-finding process, the Evaporating Cloud, or direct observation through Going to the Gemba.
The Kanban board — the honest assessment
Kanban boards became ubiquitous in software development, NHS improvement, and project management in the 2010s. In most organisations they have produced a familiar pattern: the board is populated, the work is tracked, the meetings happen around the board — and the underlying process constraint persists unchanged.
The reason is structural, not motivational. The Kanban board correctly identifies where work is piling up. If Customer Acceptance Testing has twenty tickets in the “waiting” column and three in the “done” column, the board has correctly identified that Customer Acceptance Testing is the bottleneck. That is Goldratt’s Theory of Constraints working exactly as intended: the pile of work makes the constraint visible.
But the pile of work shows you where the constraint manifests. It does not show you why the constraint is there. And in most cases, the reason the constraint persists is not a process problem that more resource or better process design would fix. It is a structural assumption that has never been questioned.
The Kanban board shows CAT as the bottleneck. The team can see this. The managers can see this. But the constraint persists because two assumptions are keeping it in place:
Assumption 1: “The customer controls the acceptance testing process and won’t change it.” This assumption has never been tested. Nobody has shown the customer the Kanban board and asked: “This is where delivery time is being lost — can we work together to redesign this stage?”
Assumption 2: “Raising this with the customer will damage the relationship.” The fear of the customer’s response keeps the constraint invisible at the level where it could be addressed — the same way fear of management keeps front-line constraints invisible in healthcare.
The Kanban board has made the symptom visible. The Evaporating Cloud would make the assumption visible. Until the assumption is named and tested, the board records the problem indefinitely.
Visual management tools and what each makes visible
| Tool | What it makes visible | What it does NOT make visible | The additional instrument needed |
|---|---|---|---|
| Kanban board | Where work is accumulating — the location of the bottleneck | Why work is accumulating there — the structural cause of the bottleneck | Evaporating Cloud, Gemba walk, five whys of the assumption |
| Andon cord | That a defect has occurred, at the specific point and moment of occurrence | The root cause of the defect — why the system produced it | Root cause analysis, 5 Whys, CLD |
| Run chart on the wall | The pattern of the metric over time — whether it is improving, stable, or deteriorating | Whether the pattern is common cause or special cause variation — and whether any improvement is structural | Shewhart control chart, Bootstrap CUSUM |
| Bed state board (NHS) | Current occupancy, available beds, patients ready for discharge | Why discharge-ready patients are still in beds — the structural constraint on discharge | Gemba walk, stakeholder mapping, Evaporating Cloud (NHS/social care boundary) |
| Dashboard / KPI display | The current state of the metrics being tracked | Whether the metrics are the right ones, whether movement is structural change or noise, whether improvement is real or seasonal | Types of measures framework, Bootstrap CUSUM, pre-committed prediction |
| Control centre (Gloucestershire) | Real-time system state across all departments simultaneously — visible to everyone with authority at the same moment | The structural causes of what the centre shows — these require Gemba observation and constraint analysis | Gemba walk with authority, Evaporating Cloud for persistent constraints |
When visual management fails — the assumption trap
Visual management fails predictably when the constraint it reveals is being kept in place by an assumption that the organisation is unwilling to question. The board shows the problem. The assumption prevents the solution. And because the assumption is invisible — it has never been made explicit — the team continues to look at the board and discuss the symptom without ever reaching the cause.
Four assumptions that commonly block visual management from producing structural change:
When visual management works
Visual management produces structural change when three conditions are simultaneously met — the same three conditions as Going to the Gemba:
- The right thing is made visible — not just where work is but where throughput is actually limited
- The person seeing it has authority to act — immediately, without escalation
- Psychological safety means what is shown is real — not a performance for the board meeting
Toyota’s Andon cord met all three: it made the defect visible at the point of occurrence (right thing), any worker could stop the line (authority), and stopping the line was rewarded rather than punished (psychological safety). That is why it produced structural change rather than sophisticated problem recording.
Most Kanban boards meet the first condition partially and neither of the other two. That is why they produce boards full of accumulated work and discussions about the boards rather than structural change in the constraint.
Bootstrap CUSUM — the test
The honest test of whether visual management is working is not whether the board is populated, the meetings are happening, or the team feels productive. It is whether the outcome metric has structurally improved.
Bootstrap CUSUM applied to the relevant outcome metric — not the activity metric (tickets moved) but the outcome metric (delivery time, patient waiting time, defect rate) — will show either a structural change point or a flat line. The flat line is the most important output: it tells you that visual management has been producing activity without structural change, and that the constraint has not been reached.
Test whether your visual management is producing structural change
Upload your outcome metric data to the StepChange Analyzer. Bootstrap CUSUM will tell you whether a structural change point has appeared — or whether the board is recording the problem rather than solving it.
▶ Open the StepChange Analyzer