Go and see — Go and see is a practical application of the Genchi Genbutsu principle, emphasizing firsthand observation.

In plain English

Go and see is when you leave the desk and look at the real work where it happens. It exists because reports and opinions miss details, and small details cause big problems.

It works by going to the place, watching the process, and asking simple questions. You look for what actually happens, not what the procedure says. You check the parts, tools, screens, and handoffs. You compare what you see to the expected standard. You write down facts, times, counts, and conditions. Then you come back with a clear problem statement and next steps. The goal is shared understanding and better decisions based on reality.

What they actually mean

On paper, “go and see” means leaders learn the work and remove barriers.

In reality, it often turns into a scheduled tour with clean floors and rehearsed answers.

  • Managers show up with a solution already picked
  • People stop the messy work until the visitors leave
  • Questions are leading, like “So we just need more training, right?”
  • Notes get written, actions do not

Uncomfortable truth: If the visit ends with “remind everyone to follow the process,” you did not go and see. You went and judged.

It also gets misused as surveillance. That creates hiding, not learning. Then the next “go see” is even less real.

Often confused with a gemba walk that is just optics, or used to “validate” a weak root cause analysis after the conclusion is already decided.

When done right, it is calm and specific: observe the work as-is, ask what makes it hard, capture facts, and leave with one owned action that changes the system.


Go and See vs Genchi Genbutsu

Genchi Genbutsu is the principle: go to the actual place and see the actual thing to understand the facts.

Go and see is the behavior. It’s the decision to leave the desk, observe the work, and base conclusions on firsthand evidence.

Without the principle, the visit becomes a tour. Without the visit, the principle becomes a slogan.



Creating a Lean Culture, explains how leader standard work, daily walks, and visual management turn “go and see” into a habit instead of an occasional visit.Creating a Lean CultureThe new edition of this Shingo Prize-winning bestseller provides critical insights and approaches to make any Lean transformation an ongoing success. It shows you how to implement a sustainable, successful transformation by developing a culture that has yRecommended (affiliate)

Example

A packaging line is missing ship dates twice a week. The dashboard says “low productivity on Line 3.” The supervisor does a go-and-see during the 2nd shift, not during the morning tour.

They watch three changeovers. Two operators wait 14 minutes each time for the label printer to reboot and reconnect. The printer is shared with another line. IT pushed an update that forces a login after idle time. Operators do not have credentials, so they call the lead every time.

The action is not “work faster.” The action is to assign kiosk credentials and dedicate a printer to Line 3 during peak hours, then track changeover time for a week.

Where you’ll hear it

Used in Lean operations, manufacturing, logistics, healthcare, and software/IT operations when you need facts about how work actually runs, especially for quality issues, delays, and safety concerns.

“Before we debate fixes, we’re going to the floor and watching two cycles end to end.”

Does it actually matter?

Yes — when the problem is tied to real work steps, handoffs, equipment, or timing.

Go and see matters because it replaces assumptions with observable facts. It helps you define the real problem, find constraints, and avoid “solution first” decisions. It also builds trust when people see leaders learning instead of blaming.

⚠️ Watch out: If leadership treats it like an audit, people will stage the scene. Then you get confident decisions based on a fake process.

Common misconceptions


  • It is a quick walk-through.
    It is observation of real cycles, with notes you can verify.

  • It is for managers only.
    Anyone solving the problem should do it, including engineers and support teams.

  • It is about catching mistakes.
    It is about seeing how the system produces the outcome.

  • Asking “why” is enough.
    You need times, counts, conditions, and step-by-step facts.

  • One visit is sufficient.
    If the issue is intermittent, you may need multiple shifts, days, or conditions.

Red flags


  • 🚩 Visits are announced and staged.
    Problem because you observe the “best behavior” process, not the normal process, so fixes miss the real constraints.

  • 🚩 The first question is “Who did this?”
    Problem because people hide issues and stop sharing workarounds that reveal the real failure points.

  • 🚩 Leaders talk more than they watch.
    Problem because the visit becomes persuasion, and the team leaves without new facts.

  • 🚩 Everything ends in “retrain operators.”
    Problem because training becomes a catch-all, and systemic causes (tools, access, workload, specs) stay untouched.

  • 🚩 No follow-up owner or date.
    Problem because the observation creates awareness but not change, so the same issue returns next week.

Worth learning?

5/5

Worth learning because it is a low-cost way to get to reality fast and prevent expensive wrong fixes. It also improves problem statements and makes improvements stick when you convert observations into owned actions.


Was this useful?
This helps us prioritize which terms to improve.
0 yes · 0 no
Report an error

Found something wrong or misleading? Let us know — we want this site to stay fact-based (even when we joke).