4 ms·

I'd say n mandatory coding days per month for every software manager to keep them on the ground.

by ls15 4y ago

jbay808 4y ago
The Toyota Way emphasizes that managers cannot merely read and listen to reports. 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. 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. See the technical debt with their own eyes. Understand firsthand why their report says that making certain minor changes is such a difficult task.
- emrah 4y ago
  > 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!
- stoneman24 4y ago
  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.
  - ytygg775 4y ago
    > 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".
- WastingMyTime89 4y ago
  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.
  - kqr 4y ago
    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.
- Izkata 4y ago
  > 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".
  - kqr 4y ago
    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...
- kqr 4y ago
  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...
ytygg775 4y ago
No. If you need to make it mandatory then they are the wrong people anyway. What you should ensure is that they can do that. That their schedule permits this. If they are the right people, they will gladly take the opportunity.
cma 4y ago
Fire Linus?
icedchai 4y ago
For some managers I worked with in the past, this was an impossible task. One person took over a year to set up their development environment. He never even ran the application. Though you don't have to actually code, there is a ton of value in knowing what the people you manage are actually working on.

I'd say n mandatory coding days per month for every software manager to keep them on the ground.

by ls15 4y ago

I'd say n mandatory coding days per month for every software manager to keep them on the ground.

The Toyota Way emphasizes that managers cannot merely read and listen to reports. 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. 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. See the technical debt with their own eyes. Understand firsthand why their report says that making certain minor changes is such a difficult task.

emrah 4y ago
> 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!
stoneman24 4y ago
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.
- ytygg775 4y ago
  > 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".
WastingMyTime89 4y ago
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.
- kqr 4y ago
  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.
Izkata 4y ago
> 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".
- kqr 4y ago
  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...
kqr 4y ago
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...

ytygg775 4y ago

No. If you need to make it mandatory then they are the wrong people anyway. What you should ensure is that they can do that. That their schedule permits this. If they are the right people, they will gladly take the opportunity.

cma 4y ago

Fire Linus?

icedchai 4y ago

For some managers I worked with in the past, this was an impossible task. One person took over a year to set up their development environment. He never even ran the application. Though you don't have to actually code, there is a ton of value in knowing what the people you manage are actually working on.