> the work generated by those groups is understood by upper management as a key to success
I think you could have left off the "as a key to success" part. Software engineering, as a discipline, is very hard to quantify and hard to understand. Every metric that anyone proposes for measuring the output and quality of work of a developer has largely been shown to be possible to game and not representative of good work. We wax poetically about an extremely productive day in which we got rid of 200 lines of code...no sales person would consider losing a customer to be a success, so you can see how that would sound confusing to a non-engineer. And the interview process is largely lampooned for asking questions that have very little applicability to the actual work being done and, yet, no one can agree on what questions a good candidate should be able to answer. Even engineers can have vastly different stances on what constitutes good work.
There's an old saying, "that which cannot be measured cannot be managed." A sales team can easily be stack ranked and their dollar value to the company measured to the penny. A marketing team can be judged by engagement numbers, inbound leads and other quantifiable results that are easy for an executive to understand. A product team's output is somewhat harder to quantify, but executives usually do take the time to understand their product and customers, so they can relate and have opinions on the work produced by the product team. Meanwhile, the engineers spend they day looking at text in another language, having conversations and arguments about bizarre made-up words like Hadoop, Riak and Mesos. They often have trouble communicating technical concerns to non-technical members of the team, including management. And seemingly simple changes in product direction are met with large time estimates and mutters of "redesigning the schema" or "scalability."
So executives decide to focus on optimizing and rewarding the departments that they can understand and engineering gets seen as a black box assigned to someone somewhat technical who's often only good at spin/messaging and not really a great technical leader. It's pretty undeniable that engineers create value. Even executives realize that. But the marginal value of one engineer over another is extremely difficult to know, even for people in engineering. So it's much easier to just assign them to tiers (SSE, Senior SSE, Staff SSE, Lead SSE, Architect, etc) and then treat them as fungible quantities.