> 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.
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.