[michaelochurch]

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.

[guj11]

Totally agree with your second paragraph.

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

[lgieron]

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

[dropit_sphere]

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.

[bkeroack]

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.

[eastbayjake]

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