Maybe it's because I've always straddled the line between IC, EM and leadership roles, but in my mind engineers are managers. They are managers of software sys

Maybe it's because I've always straddled the line between IC, EM and leadership roles, but in my mind engineers are managers. They are managers of software systems. The software systems are producing some economic output just as human or animal labor does in other domains or historical contexts. When you write code and deploy it to a production system, you are responsible for the behavior, cost and other implications of doing so. Although I believe managing people is generally the harder of the two overall, managing software systems is uniquely demanding of being able to zoom into deep technical details and then back out to understand the big-picture implications and where different layers of abstraction may have failed. To call oneself a senior software engineer I believe you need both the technical understanding as well as the big picture view of what business value your code produces. Many software engineers don't want to think that way; they look to the Product Manager to tell them what to build, the QA Analyst to sign off on releases, the Ops Engineer to tell them what broke, and the Engineering Manager to prioritize their time. And of course those asks do align with the job descriptions and are not wrong per se. The problem is that the SWE is in a much better position to foresee the majority of problems, and can save the company as well as their team a tremendous amount of pain by trying on different hats and thinking at a higher level. Not all company cultures make this possible, but IMHO it is the key to the highest performing teams.