I believe the issue relies mostly on how value is quantified by company managers. It seems to me that any relatively modern practice or methodology aimed to organize and value work, especially in software engineering, is not focused on the added value of the work itself, but increasing middle management visibility - another way to "infantilize" the workforce, if you ask me.
Take a finance guy, for instance. You give him a set of rules and objectives, and there is no need to define what "success" is like, based on the output. Success is his ability to make money.
A software engineer may implement features A, B, and C in the product. She may even increase the performance of the pipeline two fold. But there is no way to objectively quantify the impact of such changes within the current work organization frameworks. These are tools for middle management to quantify a team's output, nothing more. Thus a good software engineer would get a nice bonus at the end of the year, and a compulsory, but meaningless, promotion.
Now, I'm not saying that promoting individualism is the way to go, nothing further from the truth. I understand that there are intrinsic differences between finance and software. Yet I believe that there are very few companies out there with the right tools to evaluate the output of software engineers, and recognize it accordingly.
My job is quite interesting in this aspect: I'm a manager,who has to set,monitor,and ultimately award results. Only one direct report is technical and it is quite challenging to quantify his outcomes. I also do development,as part of my role, and it's just so freaking hard to assign values to the work that'd been done. For instance, I did create an orders portal of sorts,which our corporate clients quite like and none of the competitors have anything like that.Our head of sales going from one company to another selling this portal as part of the offering and the execs love it. Sales get revenue, everything is nice and easy. Now what do I get for this portal? Would they have sold if it wasn't there? Did it help to close or was it just icing on the cake? The contribution is clearly there,but how much? 1%, 10%,maybe 0? And that's pretty much the same for most devs. What's the contribution of that logging feature? What's the value of some smart function?
Sometimes measuring someone's effectiveness is as easy as "I sold that, here's the check, that's my effectiveness" but I've also noticed that measurement is often incredibly sloppy in business, and people rarely seem to get called on it. Making a serious effort to eliminate confounders is unusual. I think a lot of folks in non-programming jobs do, to a fairly high degree, just make shit up, pretending that they can measure the effect of various initiatives much better than they can, and for whatever reason this is rarely considered a problem or questioned.
Some of them surely realize they're just slinging barely-if-at-all-justified BS, but I also think lots and lots of people are just terrible at reasoning about that kind of thing and don't realize how meaningless the numbers they're generating are. They're trying, they just suck at it and no-one's bothered to tell them (or seems to care).
Possibly programmers are more sensitive to this than most, and are reluctant to put forward "bullshit" numbers that would, if they did, in fact be accepted as reality by the folks "above" them. Meanwhile someone down the hall's being promoted for numbers that are even more a work of fantasy than those, and may not even be intentionally deceiving anyone.
Note that the sales folks don't sweat over how much of their numbers can be attributed to the people making the thing they're selling. Those numbers are theirs, period. "Did I sell that or did Feature X put it over the top?" fretted no salesperson ever.
Take a finance guy, for instance. You give him a set of rules and objectives, and there is no need to define what "success" is like, based on the output. Success is his ability to make money.
A software engineer may implement features A, B, and C in the product. She may even increase the performance of the pipeline two fold. But there is no way to objectively quantify the impact of such changes within the current work organization frameworks. These are tools for middle management to quantify a team's output, nothing more. Thus a good software engineer would get a nice bonus at the end of the year, and a compulsory, but meaningless, promotion.
Now, I'm not saying that promoting individualism is the way to go, nothing further from the truth. I understand that there are intrinsic differences between finance and software. Yet I believe that there are very few companies out there with the right tools to evaluate the output of software engineers, and recognize it accordingly.