There is a difference being doing the same job for 20 years and being at the same place for 20 years.
If you're doing different things within the same company every few years, and taking increasingly more challenging and essential roles, then employers will likely look very favourably upon that because having that progression shows that you will likely produce a lot of value for them.
Why? With the exception of a few niche domains (scientific research, pharma, etc), it doesn't take very many years to master a domain. The problem set can only get so varied and complex. In fact, it's quite the opposite; problems tend to get less complicated over time as they get more automated/well known. Easier to solve == cheaper to hire for.
Most people that have been with a "young" company for 20 years that hasn't turned itself over and are high value will likely have large networks and will be somewhat well known by dint of having closer ties with the founding/senior leadership.
So if you're doing the same rote job for n years, and the costs of hiring someone to replace you and train them are greater than the costs of keeping you, then you are vulnerable to "redundancy." While there is NOTHING WRONG with wanting to do the same thing forever and prioritize other things, this is the risk that comes with that. (I personally have no idea how people achieve that; there is so much opportunity in the world to make money, and being restricted by money sucks).
This was true of cotton millers, milkmen, switchboard operators, and is still true for developers and operators.
I completely agree with what you've said here, however I'm not sure that the last part applies to the author of the article:
> I was a Director of Product Management, working on Creative Cloud, and also a member of the Adobe Seattle Site Council.
I don't think this sounds like a rote job. Once you get to a certain organisational level, it's no longer possible to be 'promoted' further without changing to a completely different job role.
I think the idea that to progress your career past that point, you must abandon the profession that got you there, is harmful and wasteful. A rockstar tech lead won't necessarily be a rockstar head of department. Forcing your best people to choose between ditching their core competency or being regarded as 'past it' is, I believe, a large source of the apparent incompetence that befuddles many large organisations.
> taking increasingly more challenging and essential roles
What is a "more essential" role? Higher in the company hierarchy? I would bet that a guy who knows how to fix 20 year old system, behind the scenes and without fanfares, is probably more essential for your business, than just another suit talking bullshit like he did in his last gig.
The problem is right here - there is no "essential". There is only work that needs to be done. It's always better to have somebody who has deep knowledge of the problem to do the job. And it takes time to get that knowledge.
There are no shortcuts, like, doing "high-level" things. No, you actually suck at your job, because you have superficial understanding, you just reframed so it wouldn't be obvious.
I am not against people doing high-level things. What I am saying is that being tricked into thinking that this is somewhat more important, though, is at the core of this stupidity. It isn't more important, it's a trade-off.
In a company I work for the more essential role would be someone responsible for either larger chunk of work or more important chunk of work.
Think analyst solely responsible for communication with customer and giving tasks to multiple programmers. Think programmer being told "we need this new module" along with phone call to contact person in customer company being trusted that new module happen and questions will be asked and no customer will be offended in the process. It might mean being assigned to tasks that are really important as opposed to tasks that are less important.
There is more critical and less critical (essential) work. Who gets which one depends on trust a lot. It is not so much about deep knowledge of some tech, although that one play the role. Tech is easily learnable. Whether you are able to makes sense of vague customer, whether you can work without having hand holded is more of factor.
That's not a very realistic example. In the real world, the communication with analyst goes both ways - the programmers also have to tell him what is feasible and what is not.
The problem with your argument is that you see a person "making" the decisions, and somehow you decided that he is the important guy. But if he is not a complete idiot, he is not making the decisions alone in the dark, but always goes to the more experienced (with the technology) people to get their opinion.
Of course there is important and less important work. But this has nothing to do with an importance of a job or profession, which is an ill-posed question to begin with.
And regarding responsibility.. I believe it's mostly status game again. If you don't have anything to lose, you don't have "more responsibility". A doctor or nurse, who can kill a patient and go to prison for that, has responsibility. A manager who will at worst lose the extra money and social status he gained for "having more responsibility" doesn't actually have any more responsibility - because he has in fact nothing to lose compared to what he had before.
It was real world example and had nothing to do with making decisions.
> That's not a very realistic example. In the real world, the communication with analyst goes both ways - the programmers also have to tell him what is feasible and what is not.
Yes and many people have problem to handle that. Also, programmers sometimes lie. But mostly, you go visit customer and three people there tell you completely contradictory requirements. And they hate each other and occasionally lie. Or more likely, give you requirements that make no sense, you have to ask right questions and push them right directions. The technology is not the issue there, making sense of vague requirements and creating consistent goal is. It is harder to replace such person then css guy. Of course it is immensely important how software looks like, but that skill is easier to measure during interview.
But as I told, the real difference is how much supervision you need, how likely you are to create organizational mess and so on.
A single programmer can not do all that much damage and there are processes to mitigate that risk. The point of contact can make a lot of damage. That is why it is more essential - your failure has bigger consequences for the whole project/company.
> And regarding responsibility.. I believe it's mostly status game again.
It is not. Responsibility is not about being punished nor height of that punishment. It is about being reliable without there being the need for threat of punishment over your head. If you don't work unless there is daily standup to report progress at, then you can not be trusted with larger more important tasks - no matter how genius you are.
If I am manager and tell you "this is half written requirements and the phone number" can she or he just go back to the office expecting you to communicate/do the rest? Or does he/she needs to visit you every week and ask you right questions and remind you to send important mails? That is the responsibility and that is what many people fail at.
All your arguments are also true in the reverse. It's not like analysts give programmers a proof that the work they should do is without contradictions. There are also many decisions that programmers make which actually do have big impact, although nobody really notices because there is no one to understand.
> But as I told, the real difference is how much supervision you need, how likely you are to create organizational mess and so on.
Yeah, but this is true for any skill. Anybody who has skill doesn't need supervision. It does not by itself prove that some role has "bigger impact".
> Responsibility is not about being punished nor height of that punishment.
I am talking about "having responsibility", you're talking about "being responsible". Those are two different things.
I'm at the same company for 10 year and my actual job description had evolved somewhat like this way:
Cartographer > Database admin > Data scientist > Develloper > ...
Because I felt like moving I talked to my boss and he agreed I start a part-time phd in the company. So chances are high that I'll stick around a few more years to achieve that. If after that a company is dumb enough to reject my CV based on a "to long in same company metric" that will be their problem, not mine...
PS: In the long run I think we agree. The problem is that there is no absolute metric or Machine learning trickery to evaluate experience and value of an employee. Company that believe in or sell such metrics are the main problem IMHO.
> With the exception of a few niche domains (scientific research, pharma, etc), it doesn't take very many years to master a domain.
I'd argue many areas of tech are an exception as well, at least if you're doing some of the more complex foundational work (which admittedly many tech employees are not). For example, the people who have been working on Postgres for 10+ years understand both databases and that specific database extremely well, in a way someone who's been working on databases for 3 years doesn't.
The trouble is the demand for deep technical knowledge tends to be quite fickle, you only need the market to move slightly and your narrow specialism is completely redundant. Domain knowledge seems to be longer lived.
> The trouble is the demand for deep technical knowledge tends to be quite fickle, you only need the market to move slightly and your narrow specialism is completely redundant. Domain knowledge seems to be longer lived.
I don't think the specialization _delirium was talking about is usually that narrow. I happen to be a long-time contributor to postgres, _delirium's example. While I obviously don't need ramp up time while changing jobs where I only work on postgres, it's not hard to find other jobs that share significant amount of knowledge. Even if postgres were to die, I sure hope not, there's plenty of other data stores which share a good chunk of the techniques. I know other people that were deep into one OS kernel, and changed into another one, and the technical background isn't the big issue, it's the difference in social processes.
> problems tend to get less complicated over time as they get more automated/well known. Easier to solve == cheaper to hire for.
To the extent that better tools and more capable junior developers are complements to senior developers, problems getting easier to solve should mean higher compensation at the high end:
The number of Internet users is only increasing, so the value of being the winner in winner-take-all markets keeps going up. And especially as the amount of money you need to raise goes down, that means more of the pie going to labor and less to capital.
If you're doing different things within the same company every few years, and taking increasingly more challenging and essential roles, then employers will likely look very favourably upon that because having that progression shows that you will likely produce a lot of value for them.
Why? With the exception of a few niche domains (scientific research, pharma, etc), it doesn't take very many years to master a domain. The problem set can only get so varied and complex. In fact, it's quite the opposite; problems tend to get less complicated over time as they get more automated/well known. Easier to solve == cheaper to hire for.
Most people that have been with a "young" company for 20 years that hasn't turned itself over and are high value will likely have large networks and will be somewhat well known by dint of having closer ties with the founding/senior leadership.
So if you're doing the same rote job for n years, and the costs of hiring someone to replace you and train them are greater than the costs of keeping you, then you are vulnerable to "redundancy." While there is NOTHING WRONG with wanting to do the same thing forever and prioritize other things, this is the risk that comes with that. (I personally have no idea how people achieve that; there is so much opportunity in the world to make money, and being restricted by money sucks).
This was true of cotton millers, milkmen, switchboard operators, and is still true for developers and operators.