What is genchi genbutsu, and can it work for software teams?

Where it comes from

Genchi genbutsu is one of the foundational ideas of the Toyota Production System, and sits alongside the related practice of the gemba walk — gemba meaning "the actual place."

The instruction to a manager is explicit: don't just read the report. Go to where the work is happening and look at it.

On a factory floor that means something concrete. You walk the line and see where it slows down, and where work is piling up in front of a station because the operation ahead can't keep pace. You see the machine that's been juddering for a fortnight and the operator who has quietly built a workaround for it. You notice that the parts bin is positioned so that every unit requires an extra turn, or that the station is badly lit, or that the same two people are covering for a third who left and hasn't been replaced.

None of that appears in the weekly report. The report says output was 94% of target. It does not say that the number was achieved because two people stayed late every night, that a machine is weeks from failing, or that the bottleneck everyone is working around has been there so long nobody mentions it any more. The report contains the outcome; the floor contains the reasons.

That's the argument in full. A report about a problem is a description of a problem, written by someone who made choices about what to include, for an audience they were imagining. Standing where it happens gives you the thing itself — along with all the context nobody thought to write down, or thought wasn't worth reporting, or preferred not to raise. When the two disagree, and they routinely do, the thing itself wins.

The principle contains a mild accusation, which is part of why it endures: it assumes that reports systematically fail to represent reality, and that this failure isn't fixable by asking for better reports. It's a claim about the structure of reporting, not about the diligence of the people writing them.

The translation problem

Applying this to software runs into something obvious. On a production line, the work is visible. You can watch a part being fitted, see where the line backs up, and observe the operator working around a jig that doesn't quite fit.

Software work is invisible. There is no line to walk, nothing visibly backing up, no machine you can watch juddering. An engineer at a keyboard looks identical whether she's three hours into productive flow or three hours into a problem she can't solve. Standing behind her tells you nothing except that she's typing, and it makes her deeply uncomfortable. The artefacts — tickets, commits, pull requests — are the residue of work rather than the work itself, and they lag it.

The equivalents of the juddering machine and the badly placed parts bin all exist — the flaky test suite everyone reruns twice, the deployment process that takes an afternoon, the dependency on a team that never replies, the piece of the system one person understands and everyone routes around. They're every bit as real as their factory counterparts, and every bit as absent from the status report. They're just not visible from anywhere you could stand.

And the most important thing about a software project's state usually isn't observable at all. It's the collection of beliefs held by the people doing it: which parts they think are solid, which they suspect will bite, how much of the estimate they privately doubt. That's genuinely inside people's heads, and no amount of walking will surface it.

What the hallway was doing

Before remote work, engineering leaders had an approximation, and several of the people we interviewed described relying on it. They talked about "walking the halls," about the water cooler, about program managers who acted as their eyes and ears.

"Hallway and water cooler conversations. Program managers were my ears and eyes." — group project manager, 100–150 engineers

That worked, partially. It wasn't observation of the work — it was cheap, frequent, low-stakes contact with the people doing it. Tone of voice, who looked tired, an offhand remark on the way back from lunch. None of it would survive being written down, which is exactly why it was honest.

Distributed work removed that channel almost entirely, and the standard replacement — more scheduled calls — doesn't reproduce it. A calendared thirty-minute video call is not a low-stakes passing remark; it's a meeting, with the performance that implies.

What actually survives the translation

Strip away the factory imagery and the principle reduces to two instructions.

Go to the source, not the summary. The manufacturing version happens to require walking because that's where the parts are. The software version means asking the people doing the work directly, rather than reading someone's account of what they said. The failure mode the principle guards against — information degrading as it's compressed and passed along — is identical in both settings. It's covered in detail in why bad news gets softer as it travels up.

Do it routinely, not in response to trouble. A gemba walk isn't an investigation. It's a habit, performed when nothing is wrong, which is what makes it useful when something is. A leader who only appears when a project is in difficulty has created a signal that their appearance is bad news — and taught everyone to delay the moment that triggers it.

How it gets misapplied

Two failure modes are worth naming, because "go and see for yourself" is easily read as a licence for both.

It becomes surveillance. Going to see the work is not the same as watching the workers. In knowledge work the distinction is sharper than in manufacturing, because there's nothing to observe except people — so "going to see" collapses into monitoring individuals unless you're deliberate about it. Activity dashboards and commit-frequency charts are usually genchi genbutsu misunderstood.

It becomes intervention. The principle is about understanding, and understanding is not the same as acting. A head of engineering told us:

"Me jumping on an issue is threatening to engineers."

A leader who investigates and then immediately intervenes has converted a cheap information-gathering habit into an expensive event, and the organisation will start managing the information to avoid triggering it.

What it means for a modern team

The practical version, for a leader who can't walk anywhere:

• Get information from everyone, not from a designated reporter. The dev manager's summary is a report. Six people's own assessments are closer to the source.
• Make it routine and cheap. Something that costs seconds can happen weekly without becoming an event. Anything that costs an hour will become an event, and events distort what they measure.
• Ask about the thing you actually want to know. Not activity, not output — whether the people doing the work believe it will land.
• Separate seeing from acting. Most of what you see should produce no visible response at all. That restraint is what keeps the channel open.

Why we're called Genchi

The name is the argument. Genchi collects a two-second answer from every person doing the work — how confident are you that we'll achieve our goal? — and aggregates it without anyone summarising it on the way.

It's an attempt at the same thing the principle asks for: getting the picture from the place the work is actually happening, rather than from a report about it. For an organisation of twelve teams across four time zones, that isn't a walk. But it's the same instruction.