Strong disagree with basing salary on years of experience. I see almost no correlation between output, skill, and years of experience.
I actually consider this an anti-pattern that actively encourages coasting.
I actually consider this an anti-pattern that actively encourages coasting.
Coasting can be fixed by firing or layoffs (which I consider a healthy lifecycle for any company).
"Coasters" at least know that what they do today they might have to support for N years following, so design accordingly. (Although I've also heard horror stories when they make it intentionally hard to understand for job security reasons, fortunately never seen myself).
By making the best be on unimportant projects you get the following benefits:
Nobody worries about interrupting them if they have a problem - who cares if you make the unimportant project take more time.
Your second best people get to experience leading important projects and thus you grow them into the best people (sometimes the previous best people may need to take a turn leading, other times the third best get promoted). See above about asking questions - the best people can mentor them as needed - again nobody cares if it makes their project late.
Unimportant projects sometimes turn into next years most important project - and your best people have been creating a good base to throw lots of people at.
When sales/marketing discovers an sudden opportunity that needs people now - you have experienced engineers to take it over without killing progress on what was the most important project. (be careful about this one - if they only rarely have such requests it is fine, but if such requests take up too much time you probably should either have a dedicated department of engineers for this - with a real budget and management to ensure the requests are really valuable enough to be worth the time - or you need to tell sales not to make such promises)
Of course if this is only treated as unimportant projects they will leave.
Based on what? You've just invalidated all the tools one would use to evaluate performance.
One is Oxide [0], which has uniform compensation across the board, explicitly with reference to this problem about how performance processes influence work and culture.
Another might be to take LeetCode-style interviews more seriously. We have already concluded that the most important criteria for whether we want to work with someone is their ability to solve algorithmic programming tests under time pressure. Why stop at initial hire? Maybe they got lucky with familiar material. Maybe they crammed and didn't actually internalize it in a stable way. We should probably be giving coding interviews continuously to existing employees. Further, since we have concluded that shades of interview performance are a good way to determine seniority and responsibilities, we could also use these continuous tests in place of the promotion process. Knock it out of the park? Congrats, you're a staff engineer now. Barely squeak by? Back to intern. It sounds facetious but it also addresses the "promo criteria distort architecture" problem and the "YOE isn't ability problem." The civil service is not too different. Officials get to the next level by passing written and oral exams.
Another might be to have stakeholders bid on talent per project. This would match e.g. the creative industry where teams are constantly created and disbanded, and your next gig is based on the department head or director’s assessment of the quality of your work or the experience of working with you in a previous project.
[0] https://oxide.computer/blog/compensation-as-a-reflection-of-...
The leetcode stuff doesn't necessarily correlate to actual productive capacity. Good teams tend to be a mix of complementary talents, and if you put a group of algo hackers together you'll get a lot of algo hacking. You won't necessarily get a lot of maintenance or debugging.
All of which highlights that the industry has no clue how to quantify talent either during hiring or after. And even less clue how to quantify the business value of talent. It has even less clue how to quantify needed talent - in the sense of creating teams with a productive mix of interlocking skills.
Abstract discussions about comp are meaningless from a business POV without that information.
This applies particularly to management. Some managers are clearly better than others, but in spite of all of the books, lectures, and general opportunism around management theory, many corps struggle with creating a sane productive culture.
Now in tech we are shy about subjectivity. One way to get a measurable quantity related to virtue is to construct a game. Within the framework of the game we can all agree on what is a win or a loss. We can also rank players according to their track record of wins and losses. Someone who wins when most others would lose is a good player. Someone who loses when most others would win is a bad player. We can have neat quantitative encodings of this, like Elo. And we can agree that winning or losing the game we have constructed has something to do with the virtues we care about. But unless we're talking about professional sports, the game is only a proxy. The subjective judgement now lives in the choice of this game, and not some other game, or this rule, and not some other rule, as our proxy.
This is obviously what we have done with LeetCode. LeetCode's fidelity as a proxy for working-programmer virtue is of course doubtful. The promo packet's fidelity seems like it should be higher. But the promo packet is also a constructed game and an imperfect proxy. When programmers play to win the LeetCode game they engage in not-very-constructive studying and practice in their free time, and perform the weird ritual for a few hours in a conference room. It is mostly the programmer's loss. When programmers play to win the promo packet game they do things contrary to working-programmer virtue in their capacity as working programmers. They design overcomplicated solutions, involve too many stakeholders in their execution, deprecate and replace things instead of maintain them, leave obvious defects in their products because there is no causal inference proving their dollar value, etc. The company loses. It loses big. Given that we have already accepted the tradeoffs of LeetCode interviews with respect to hiring, are you sure it's so ludicrous that they're a better set of tradeoffs than the ones we currently use for leveling?
Its hard though when people see my work history they only let me interview for very senior roles which I usually aren't good enough to do.
Over 20 years, you've not demonstrated that growth, and so it makes more sense for a prospective employer to assume that lack of growth will continue. Compare to a junior dev who can bring the same productivity today, but could rise to the level of principal or staff over the long term.
For the record, I would bet that this picture doesn't match reality. My guess is that you've developed knowledge and skills that would make you much more valuable than you might think. But, you are expected to demonstrate them and use them on the job. Good luck!
Growth, especially if you have a decade of experience (and not one year ten times), is hard. I think especially at the upper end it takes dedicated effort.
I stopped learning programming skills on the job about 7 years ago.
Today, Im still learning new languages, frameworks and libraries.
I'm also still growing in regards to,
Management skills, project skill, leadership skills, self time management, effective habits, not to mention work life balance things as my life now requires it.
I'm in a standard tech area outside of Silicon Valley - plenty of standard enterprise Java jobs with a slightly smaller number of C# positions. My experience here has been that I seem to be able to make lateral moves into similar jobs that don't particularly offer more technical or career growth.
This relates back to your original comment about not seeing correlation to gains in output and skill versus experience in years 12-15 for working engineers. Most job roles in my area simply don't require more output or skill than a software developer gains in those first 3-5 years.
I would guess that for people who do observed a significant correlation in growth in output and skill over those longer years of experience are biased by seeing engineers who were in positions that required growth in output and skill.
Another weird effect (at least in my group - which tends to have long tenured employees - I've been here 12 years) is that I see engineers get stuck in specific responsibilities centered around institutional knowledge. For example, being the devops type for three legacy systems that will exist forever. If a new need comes up, my group seems to prefer hiring a totally new person to own that new project. We have actually lost a couple of employees who (rightly) were frustrated by not being able to get off of legacy support projects. These are the programmers with 20 years of experience but really have that initial 3-5 years plus the same year of experience * 15.
In my case, I had personal reasons for staying in the area and have had to manage my own tech growth. Typically by side study and programming. Some of this has led to new work in the day job but I realize I traded career growth that I would have very much enjoyed for stability. I have also have enjoyed a tremendous amount of flexibility, some autonomy in choosing dev stacks, and collaborating with medical researchers.
If you increase pay regularly on a semi-fixed schedule, you at least solve this problem and improve your employee retention.
If the company has some metrics they’re using to evaluate performance for the purposes of moving on from low performers… why not just use those metrics to move people up/down instead of years of tenure?
I find it funny that people in tech get squirrely over annual raises, but don’t have a problem with multi-year vesting schedules with massive payouts.