...I know that this concept exists, but I've only ever encountered it as a theoretical concept that certain HR departments will pay lip service to, but the reality, in my experience, is different.

For example I have worked in a top-tier investment bank. One year, they had a particularly bad year (because markets were just bad), so while traders in some cases still got bonuses, nobody in the entire Technology Division (since they were seen as being more replaceable) got a bonus. They made up for it by giving everybody a bump in their title (with no bump in pay). That kind of BS is my primary association of what it looks like in practice when people climb the "technical" ladder (rather than the "management" ladder).

In my mind, a carreer progression would have to imply that, as time goes by, your options of things you might do in the organization expand and, since you get to pick and choose from a wider pool, you make choices that are in your best interest meaning more money and more opportunity to influence the direction of the business and all that.

It works that way for management, as the relationships you build with people become an asset that starts paying dividends over time.

For engineering, it works in reverse: Your options become less with time, not more. The determinant of any move you might make within the organization is not so much the opporunity around you doing something new, but the risk around you no longer continuing with what you leave behind. (Or at least that's the way that organizations will mistakenly see it). Say you've built a database that underlies reporting infrastructure that underlies all decision-making in the entire company. Bringing in somebody else to look after the database is a risk that a company usually won't want to take. Ramping up somebody else to learn about the system is a cost they won't want to incur. Congratulations: You're stuck looking after that database for the rest of your time at that organization. That's the reward you get for having done a good job at building that database.

In addition, I would say that over the 10 years that I've been in industry I have seen a cultural change around non-engineering professions moving in on decision-making-territory that would have previously been an engineer's. I'm talking about business managers, designers, product managers, product designers, it infrastructure architects, what have you. 10 years ago, you would have been presented with a problem which, at the face of it, was technical in nature like "build a database and some reporting infrastructure around it". You would have picked a database management system, built the data ingestion infrastructure, created e-mail reports which you designed yourself, etc. etc. Nowadays, you go to person X enterprise IT architect to have them decide which database you can use. You go to a designer to tell you which font to use on the report. You go to a product manager to tell you how often to send the e-mail reports and what the signup-flow should look like, etc. etc. -- Congratulations you have just been reduced to a mere machine executing a business process, not making a single meaningful decision for yourself, and as a result your social standing is barely above that of a machine.

Much of this is due to the way that some very vocal engineers have said that they want to be treated.

Look at the growth of Agile (the reality of what it is, not the manifesto, confuse those two at your peril) and the growth of the Product Manager role in tech. As engineering groups have ceded their position and complained about having to be in meetings, only being responsible for the systems running and not much else, having others tell them exactly what they want done, those responsibilities and tasks have either been picked up by existing groups or had new groups created to handle them.

What we're seeing today is the natural growth of that. That's one of the reasons why we're seeing the huge interest in the no-code space. Engineering has managed to turn itself back into a cost center and is being viewed by the business side of the house as a necessary pain vs a beneficial resource.

That doesn’t make sense to me. Engineers have managed to cut down on useless meetings and focus on improving reliability of systems, and that is a bad thing? Come on. Engineering was always viewed as a cost center in most industries and nothing has changed that view. The only thing that has changed is that engineers have migrated to orgs where they are treated well, where they innovate and create the very No Code systems that you tout. Those systems weren’t created and are not kept operational by non engineers.

> One year, they had a particularly bad year (because markets were just bad), so while traders in some cases still got bonuses, nobody in the entire Technology Division (since they were seen as being more replaceable) got a bonus.

Not sure why you'd expect a bonus in a down year? That's the point of bonuses - they are not guaranteed, and you won't get them if the firm doesn't do well. Individual traders might still get them if their desk did well despite overall poor firm performance, but that cuts both ways - traders can get zeroed if their desk has a bad year even if the firm overall did well.

> For engineering, it works in reverse: Your options become less with time, not more. The determinant of any move you might make within the organization is not so much the opporunity around you doing something new, but the risk around you no longer continuing with what you leave behind.

This is an important lesson in any role: If you are indispensable in your current role, you can't move up. Don't make yourself indispensable. Cultivate a team, and help junior engineers on your team grow to take on tasks that you're currently responsible for. Don't take on solo projects that you're working on by yourself - they're a career dead-end for multiple reasons, and they're probably not even very valuable to the firm (otherwise they would have a team).

Much of this sounds like being in an organization where engineering is seen (or is) a cost center, not a profit engine.

There's definitely a tendency to stasis in organizations - if the benefit of new software doesn't outweigh the loss of older, working software, there's no way anyone would want to encourage new software to be made.

This has been my experience both in the case of a bank (where technology is an operating overhead) but, surprisingly, also in a tech startup at the stage where it was maturing beyond 50 employees. Even more surprisingly, we are speaking of a tech startup where the CEO, CTO and most senior product manager are all engineers. But they got into those positions when the company was just a handful of people and seem to have forgotten about their roots. What is going on now is that there is little to no real carreer mobility for newly hired engineers, and the company now has more non-technical than technical people, who have built up a caste system where they keep engineers out of the decisions that matter.

I'm curious where you're located. This was exactly my experience in "tech" startups in NYC, but not my experience at all working in SF. This is a big part of the reason why I have zero interest in leaving SF for some upcoming tech city, as in my experience you are correct there is a tendency to push engineers away from any business decisions, but much less so in SF which has a culture that ties engineering to entrepreneurship more closely. One explanation I've noticed is that the VCs in the Bay Area are far more likely to have technical backgrounds, whereas in NYC the VC firms almost always have finance backgrounds, and that culture bubbles down.

You're quite right: I have had no direct contact with the SF / Bay Area, nor any companies based there. I've mostly been based in major European cities, and in some cases working within the European operations of U.S.-corporates (that weren't Bay Area startups). In a few cases I've worked remotely directly for U.S.-East Coast startups.

I think this is the answer. At investment banks (I interned at one once) the tech people were a cost center, not a profit one, and the power structure reflected that, whereas with many Silicon Valley type companies, it's the opposite. I guess this is what people refer to as having an "engineering-driven" culture.

> For example I have worked in a top-tier investment bank. One year, they had a particularly bad year (because markets were just bad), so while traders in some cases still got bonuses, nobody in the entire Technology Division (since they were seen as being more replaceable) got a bonus. They made up for it by giving everybody a bump in their title (with no bump in pay).

This sounds exactly like my experience at Morgan Stanley. Your entire post sounds a lot like my cynicism after working at IBs for a few years.

Get out as soon as you can. Seriously- I went to a tech company and it literally changed my life. I was in a "prestigious" role but still felt absolutely like a second class citizen to anyone in the "business." I have never felt like that since I left, not even for a moment. DM me if you want more details/encouragement.

> Say you've built a database that underlies reporting infrastructure that underlies all decision-making in the entire company. Bringing in somebody else to look after the database is a risk that a company usually won't want to take. Ramping up somebody else to learn about the system is a cost they won't want to incur. Congratulations: You're stuck looking after that database for the rest of your time at that organization. That's the reward you get for having done a good job at building that database.

FWIW my experience at top tech company is very different. If an engineer did this and was unable to communicate, cross-train, and scale themselves beyond their direct ability to maintain, they would never make it to principal -- or any other coveted technical career path promotion.

>I have seen a cultural change around non-engineering professions moving in on decision-making-territory that would have previously been an engineer's.

The same thing happened where I work (as a developer), but a funny thing is, since most of the upper people are a bit clueless about the domain (it's formalized in the code, they don't read code, and their turnover is high), when my team asks questions about specifications, they can be redirected back to us, from people that know we know the details. We also often don't waste time with questions and just have meetings with specification people to explain them what they should actually have asked us to do.

That said, things don't always work out as nicely, and every few years we still have to brace ourselves to survive architectural tidal waves from astronaut architects who seduced credulous management, which we do by fighting to keep our module purely domain-oriented and independent from any particular stack (other than its language).