That’s really stretching the m idea behind this tentent of lean manufacturing. The idea is that the whole management team should somewhat regularly visit the workshop - the place where work is actually done - so as to stay in contact with what’s happening there and are aware of what’s happening with the process and the team.

If you are a direct manager of a technical team, that point should already be covered. You are always in contact with the working team. You are already in contact with the people knee deep in the work: that’s your the tech leads, the junior and senior engineers and the WPM working for you. Just ask them what’s happening and where process needs work. If you can’t trust your team, well, you have bigger issue than the quality of the code.

No, the point of genchi genbutsu is specifically not to rely on the reports of third parties (including your team) but to actually go and observe for yourself.

This has nothing to do with trust, and is entirely because different people with different experiences in life tend to see different things when they look at a situation.

While the codebase is critically important, the most important aspect is how that codebase translates into user experience. How the design/software changes impact what the customer expects and how the company manages the expectations of both existing and new clients are both vital factors. Managing that journey for both internal software teams and the wider client base to achieve the overall objectives is the real landscape for managers. Especially for small companies, the impact of poor commits can have huge impacts for important clients which then takes time to educate and assist them to handle.

> While the codebase is critically important, the most important aspect is how that codebase translates into user experience.

I'd agree to this, if you include the individual contributors in the set of "users".

> Managers don't need to be making commits that get merged into production, but they should be constantly familiar with the codebase that their team is responsible for, and capable of playing with it and try out ideas.

Bingo!

> They need to walk the genba, the factory floor, and see firsthand what the state of things is.

> With software, the genba is not the office. It is the codebase.

Amusing aside: my dictionary includes "scene of the crime" in the translations for "genba".

It's really a very general work meaning "the place where it happens" -- in the context of lean, where work happens. In a criminal investigation...

That's not quite how I remember it. Maybe it was a different source, but the idea is that the manager should spend a significant chunk of their time doing actual technical work, so they retain enough proficiency to step in and substitute for any of their subordinates e.g. in the case of sickness.

Thus requires a deep hierarchy of managers to even out the administrative burden and give everyone time to do technical work.

What confuses me is that in my experience, a deep hierarchy of managers tends to lead to each layer inventing more administrative work for themselves and the layers below, not help take the burden off...