Many things follow from the fact that software is literally invisible to most people. If you can't see it, how can you manage it? As I've detailed before.
In some cases, normal people can, at least, see some evidence of the software, like for example when it's an app or a web site. They may not choose (!) to try it themselves, but it's not too much of a stretch to think that they could.
But for some important classes of software, that's not really an option.
As usual, Dilbert explains it to us:
Note that the big boss has no easy way of knowing whether the software is "done." If it were a new web site, perhaps he could navigate to it. But what if it's a new internal process management system? Even a new customer service routing system? You could walk into a service center and see lots of people on the phone. Just like before. Is the new software done? How would they know?
Is the operating system upgrade done? How about the migration of certain applications to a virtualized environment? No one except the internal people would know the difference, unless of course a disaster happened! Hmmm... Given the track record of these things, maybe the fact that everything continued to run smoothly, with no break at all, means that nothing was changed!
There is a solution. It's pretty simple. The solution is to acknowledge that knowledge of the substance of software is more important -- by far! -- than supposed "knowledge" of generic management techniques as taught in business schools.
Knowledge of substance trumps knowledge of "management" even when you can see what's going on!
My great-great-grandfather was James Law McMillan. He was born in Wanlockhead, Scotland in the 1830's. After he came to this country, he went to work in the anthracite coal mines in the Pittston area of eastern Pennsylvania. He knew how to read and write, but had essentially no schooling. Here's part of his 1907 obituary:
He knew mining -- because he was a miner. He was there, deep in the pits. No one can make the argument that mining and coal is invisible in the way software is, but James was promoted because he could get it done.
Perhaps we could learn a little from the experience of the Pennsylvania company. Get people who can do the work to do it. When you find one like this: "with such energy did he labor and such an intelligent interest did he take in his work, that he soon acquired an excellent practical knowledge of mining," that person should take on management.
In software, most managing is done by people to whom the software is invisible. And what happens too often is that the people who aren't good at programming become managers so they don't have to do it any more!
Maybe those people who ran coal mines are worth emulating, at least in this respect.