We asked 3,564 operations leaders what kills their gemba walks. 53% gave the same answer: they spot the problems, then nothing happens.

The walk itself often works fine. It's the part after the walk that breaks.

Here's where it comes from.

The floor knows things you don't

In 1989, Sidney Yoshida put a number on something every operations leader has felt but rarely measured. He called it the iceberg of ignorance.

Front-line workers know close to 100% of the problems in their area. Supervisors know about 74%. Middle managers, roughly 9%. Executives, the people with the budget and the authority to fix something, know about 4%.

96% of what's broken sits below the waterline, invisible to the only people who can sign off on a fix.

A dashboard tells you a line is missing its rate. It won't tell you why. The why is usually sitting in plain sight on the floor: a bin staged just out of reach, a scanner with a four-second lag, a fixture that takes three tries to seat right, a label printed too small to read under the shop lights.

Ten minutes of watching shows you what months of reports couldn't.

The walk is how you get below the waterline. It's also the easy part.

What kills the follow-up

Ask enough operations leaders what happens after a walk and a pattern shows up fast.

Paper notes get lost between the floor and the desk. Processes break down across shift changes.

The follow-up that would close the loop never lands. Closing it means an hour of admin work stacked on top of a job that already has too many hours in it.

When a veteran leader retires or moves on, the pattern recognition built over 20 years of walking the same floor walks out with them. Nothing was written down. Whoever replaces them starts from zero.

Plenty of these same companies have spent real money on sensors and connected equipment. The dashboards are there.

Decisions still get made on gut feel. The data just sits there, unused.

The silence loop

One thing makes it worse: operators notice when nothing changes, and they adjust.

The pattern usually looks like this. Someone raises a real issue: a machine that overheats every morning, an approval step that adds three days to every request. A manager says they'll look into it.

Weeks pass. Nothing happens.

The next time something's wrong, that same operator says less. They noticed the same thing before. They just learned that saying so doesn't do anything.

Multiply that across a floor and across a few quarters, and you get a team that's stopped telling you the truth about what's broken, right when you need it most.

Walks keep happening. The people who used to talk during them have gone quiet.

The four delays that eat your response time

There's one number worth designing around here, more than throughput or OEE or any of the usual metrics: the time between an event happening on the floor and a fix landing on it. Call it Gemba Latency.

It breaks into four stacked delays. Insight latency: the event happens, but the person who can fix it doesn't know yet. Analysis latency: you've got the observation, but haven't made sense of it.

Decision latency: the problem's understood, but the fix hasn't been approved. Action latency: the fix is approved, but hasn't taken effect.

Add them up and that's your real adaptation speed. At most sites it runs in weeks. Sometimes the event never gets fixed at all, because the observation died in a notebook before it reached anyone with the authority to act.

A fix loses value every day it waits, and these four delays are what make it wait.

What fixes it

Cutting insight latency starts with a routine that survives the calendar. Same time and same rhythm every week, protected against getting bumped for something "more urgent." Capture on the spot matters too: an observation that lives only in a notebook until end of shift is an observation that's already half gone.

Cutting analysis latency is where most programs stall completely. Sorting through a pile of scattered notes to find what matters used to take a manager's gut feel and a week they didn't have. Tools like an impact-frequency matrix (plotting each issue by how much it hurts and how often it happens) and a waste tracker tagged by type turn scattered notes into a pattern you can act on.

Twenty motion-waste flags in the same aisle point to one layout problem. The pattern only shows up once you're tracking it that way.

Someone still has to act on what's flagged. The tool's job is smaller: keep every issue visible, and put the still-open ones in front of you again at the start of your next walk in that same area.

The operator who raised something in March can see, in April, that it's still on the list. That's what breaks the silence loop: proof that nothing gets forgotten.

Gemba Walk AI is built around exactly that gap. Capture happens on the phone, during the walk. The report writes itself instead of eating an hour at your desk.

The impact-frequency matrix and the waste tracker sort what repeats and where it clusters. Every issue carries a status, and the still-open ones from your last walk in that area are the first thing you see when you open the next one.

Pick one process. Schedule one walk this week. The gap costing you the most right now is probably sitting in the hour after the walk ends.