Worth noting is that it's not just about titles. Titles matter, but they can also become a joke. It's easy to imagine a company, realizing that its best seniors are underpaid, inventing a new title to justify paying them only 10% more instead of the 30% they should get.
The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business". Hence, all that Agile/Scrum bullshit in which engineers just churn tickets, rather than making meaningful technical decisions and building projects of increasing scope. No one who has any leverage and talent wants to work in that way. This becomes self-perpetuating, because even though there are good people who stick around (usually, with kids in expensive private schools, or uninsured sick relatives) the assumption becomes that good engineers leave after a certain point and, thus, that anyone left isn't any good.
For me, I only enjoy coding if it's part of a bigger whole, and if I am proving something in doing so. If I'm stuck in a ticket shop and can't leave for 2 years for some reason, I'm going to manage (preferably officially; unofficially via aggressive delegation if necessary) because I was done with that junior-level business-story coding several years ago. I graduated out of it long ago, and I won't be put back there like Billy Madison.
Good technical people at large companies (ran by non-Technical management) are often undervalued. I see over and over again how an engineering team gets a non-technical PO/Manager - who is just a very bad proxy. They can't bring any important insights into technical products and can't easily fix inter-team dependency. That's why all Google's APMs are technical (most with CS degrees).
This gets worse when top level management is not technical for a technical company. Since they are not technical, they don't have good vision about where the industry will go in 10 years and what are the limitations. Ex. Microsoft under Steve vs Satya. One only had a vision for next quarter and the other seems to think longer term (and knows where the technology is going).
> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business".
Isn't that the inherent nature of a lot of the programming jobs, though? For example, I'm currently contracting at a e-commerce company. My day to day work is as you described - closing tickets that get assigned to me in the Sprint. I also suggest new tickets, but they're solely limited to technical issues (mostly addressing technical debt, trying out new technologies etc.).
Honestly, I wouldn't know how to suggest anything on the business side - I don't know a first thing about how the market we're in operates (except that it's very competitive), and we have a separate person (Product Manager) whose only job is to think of new features for our team to implement. I think that's the only arrangement that works for non-technical products, which is what vast majority of programmers work on.
I was thinking about the same sentence you highlighted, and I think you're right.
The problem is that it's often bundled with a similar but patently false and demonic idea---that the business and technical sides can be siloed without ill effect. They can't.
Someday someone will write a best-selling business book about how it's valuable for management to have technical expertise, and it'll have some catchy term like the "mangineer" or something.
Some of the better VC firms (eg. a16z, YCombinator) are already putting this in play with their investment decisions, but they would rather profit off it than write a best-selling book. There's a reason why the conventional wisdom in the Valley - at least among firms in the know - is that you need a technical founder who also thoroughly understands the business.
Then empower yourself by learning how the business/market works, or if that sounds stupid and boring, leave for someplace where it wouldn't be.
I'm not the OP, but the point I think is that as long as you are content to be a "code monkey" (no disrespect meant at all, but that's what it sounds like) that just does what they're told for 40-50 hours per week, you can't expect to have any upward career growth.
In this kind of setting there is no career growth though. You're either a 'code monkey' or someone like a technical product manager, or you manage people. They are all different paths, with none of them being inherently better or worse than others. Money-wise, a lot of code monkeys are contractors, which means that they take home as much or more than senior management.
Honestly, I'm not even sure how "upward career growth" could look in a company structured like that. I don't think I saw a single programmer in here who empowered himself with business domain knowledge to a degree where he could make meaningful contributions. I guess we're all comfortable with where we stand.
Engineers, speaking generally, are more than happy to work with the business.
Where there's divergence is that engineers don't want to work for the business as a subordinate, or for compensation that justifies working on something less interesting or career-beneficial than what one would prefer.
> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business"
This is exactly what I tell people when they ask why I'm applying to business school instead of being a career software engineer. Engineers will almost always just be implementers of other people's strategy decisions -- and they will be largely fungible -- but the strategy decisions are where you can have a real lever effect on organizations as an individual.
The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business". Hence, all that Agile/Scrum bullshit in which engineers just churn tickets, rather than making meaningful technical decisions and building projects of increasing scope. No one who has any leverage and talent wants to work in that way. This becomes self-perpetuating, because even though there are good people who stick around (usually, with kids in expensive private schools, or uninsured sick relatives) the assumption becomes that good engineers leave after a certain point and, thus, that anyone left isn't any good.
For me, I only enjoy coding if it's part of a bigger whole, and if I am proving something in doing so. If I'm stuck in a ticket shop and can't leave for 2 years for some reason, I'm going to manage (preferably officially; unofficially via aggressive delegation if necessary) because I was done with that junior-level business-story coding several years ago. I graduated out of it long ago, and I won't be put back there like Billy Madison.