You hit on the fundamental assumption of calling IT a factory, and why that’s invalid.
IT is not a factory, it builds factories.
I believe a lot of developer/management conflict stems from a lack of terms for what we call manager. A McDonald’s manager supervises employees to ensure they’re following a process that produces a product. Failure to adhere to the process is obvious, the process is assumed to be valid as a given, and failure to produce the outcome is obvious.
Whereas a programmer is employed to develop processes that a machine will follow. A manager over this employee may have a process for the programmer to follow, it may be obvious whether this programmer is following the process, but it is uncertain if the process is valid and will connect specific actions to prescribed outcomes and the outcomes themselves may be non-obvious.
But we call both people in these roles “managers”, despite them being very different.
Programmer, in this machines analogy, is a different type of manager. One that presides over machines, and not people. But these machines are turned loose on the world, left to their own devices and not watched over by the programmer.
I think this is great insight. It reflects why I often feel like I'm having to be the product and program manager as well. Even though I'm not, so often ideas on what could be improved, what could be done better, how to do things better can only come from the programmers, because the people whose title is manager are too removed from the actual management of the machines that are the ones executing the process that yields actual outcomes.
IT is not a factory, it builds factories.
I believe a lot of developer/management conflict stems from a lack of terms for what we call manager. A McDonald’s manager supervises employees to ensure they’re following a process that produces a product. Failure to adhere to the process is obvious, the process is assumed to be valid as a given, and failure to produce the outcome is obvious.
Whereas a programmer is employed to develop processes that a machine will follow. A manager over this employee may have a process for the programmer to follow, it may be obvious whether this programmer is following the process, but it is uncertain if the process is valid and will connect specific actions to prescribed outcomes and the outcomes themselves may be non-obvious.
But we call both people in these roles “managers”, despite them being very different.
Programmer, in this machines analogy, is a different type of manager. One that presides over machines, and not people. But these machines are turned loose on the world, left to their own devices and not watched over by the programmer.