> 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!

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.

In addition, it gets very difficult to critique a commit made by a manager (or worse a director who still wants to code) which is not consistent with rest of the team or the technical goals. They may have the best intentions but not reflect the current design/techniques that the rest of the team are using to improve the code base. The power structure just doesn’t allow the team to work. Seen many good people quit over this.

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.

> 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".

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...