I've yet to see anything better than years-of-experience (or years-in-company). I've worked in both FAANG and startups plenty, and personally I've seen worse outcomes from "impact-driven" OKRs, nepotism, team-surfing, than from 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).
A part of me wonders whether certain organizations tolerate "coasters" as a talent reserve of sorts, expected to engage when things get busy or new/interesting challenges emerge. For whatever reason, many businesses fire underperformers, promote overachievers but treat the 80% in the middle very generically. Why work to be a top 20% performer when you are treated the same as the bottom 20% performer? Coasting seems like a natural outcome.
Your best employees should always be working on the least important projects. Thus they will seem like coasters.
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)
Not if handled right. Remember those unimportant projects are often self-assigned as try the latest thing to see if it is useful to us, and they often get high visibility to management as cool things we want to do next.
Of course if this is only treated as unimportant projects they will leave.
I think "coasting" is a really uncharitable word to use, too. For some people, yea they really are just throwing the gear into neutral and drawing a paycheck while they play Minesweeper. But for a lot of people, they reach the point in their careers where the next step is "up" but there are very few "up" roles available. So they end up in this slugfest, competing with a lot of people for that one rare "Director" slot that opened up. And for every 1 person that rolled snake-eyes and got promoted, there are 10-30 that are thrown back to Thunderdome to compete again the next time an opportunity arises. I don't think it's fair to label these people who keep fighting for those rare promotions "coasters" just because they've been doing the same thing for the last 15 years. I've been in the Thunderdome for even longer, and I'm still "Senior Individual Contributor number 32291." Am I coasting?
You can still use self-assessments, manager and peer reports on the work done, e.g. each quarter. Just explicitly don't use them for promotion. If they are used only for "whether this person brings more to the company than company spends on them", then it unlikely to become a metric to game around.
We're talking about leveling and compensation based mostly or entirely on years of experience; this implies they are based only a little or not at all on performance reviews.
Recently I have been musing about a SlateStarCodex-ish "compensation systems very different from ours."
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.
Assuming you're being serious - all of that sounds nightmarish and extremely subjective and failure-prone. Subjective assessments can easily skew towards politics and patronage. Your dept head is very likely indeed to confuse likability with technical ability.
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.
The relative virtue of workers and work products is in fact subjective and not a measurable quantity. Creative fields embrace this openly. Success in a creative project is highly related to the reactions it inspires in people (public, funders, critics, etc). A good creative leader has access to the same subjective reactions that the audience does. She also has them at a higher level of detail. That way she can give actionable feedback on specific elements, emphasize what works and cut what doesn't, to optimize the overall subjective experience. I came to know this process through the performing arts but I'm also pretty confident that it describes Steve Jobs. Personally I don't think we have nearly enough respect for practitioner judgement in the tech world. Software also succeeds and fails in many cases based on its subjective resonance with users and maintainers. (Though not all, contractor-maintained enterprise software exists). Good taste is also part of the virtue of a senior engineer.
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?
As someone with 20+ yoe this is true, I'm probably as good as a guy with 5 yoe and honestly I want to apply for jobs like that. Honestly tech has changed so much I'm skeptical anyone really has 20 years experience now.
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.
I'm gonna be real with you here. You're not as good as a 5yoe employee, because people are expected to grow. Nobody hires a junior dev because they want a junior dev for 20 years. They hire a junior because they think the person has potential to grow into a senior dev over time.
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!
Do you need to divulge your whole work experience? You can just share the last 5-10 years ( most relevant), and then you wouldn't be put up for jobs you don't feel up to.
I tend toward your side of things. In your first 0-n years of experience, you're growing extremely quickly (hopefully). You're working with a lot of new tech, new people, if n is greater than 4 or 5, hopefully at least two companies if not three. But by the time you have n-teen years of experience, it's much more like you've been repeating the same year of experience over and over again.
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.
One thing I have noticed is that (prior to the pandemic) new positions in my geographic area were almost always limited to the kind of roles that could be successfully handled by programmers with 3-5 years of experience. There simply weren't many higher-level roles available.
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.
On the other hand, significant merit raises (over 3%) are mostly a thing of the past. Workers that gradually improve at their job are paid less and less each year.
If you increase pay regularly on a semi-fixed schedule, you at least solve this problem and improve your employee retention.
They address this in the article by saying it is "relevant" experience. They've given themselves some wiggle room there and I'm assuming they will trust their hiring practices to make sure they don't hire someone with 10 1 year experiences.
I’m more referring to the culture this would create. If I’m at L3 the only thing I can do to get to L4 is… wait two years. Why would I do anything but the bare minimum to hit that tenure benchmark? More importantly, why would I stick around and wait?
Coasting can be compensated for by a "we're expecting you to be productive or we'll help you move on with our thanks & good will" policy. Make it easy for managers to fire and replace at market levels.
What metrics would you use to evaluate performance? I know what I would do, but I don’t use tenure to determine pay.
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?
For "individual contributors" that breaks in a way that seems obvious, but managers deal in unmeasurable fuzziness almost by definition (since humans are complicated and they're in the business of humans), and there's significant pressure to become a manager after a few years.
The OP did not say that they were basing salary on years of experience, but that they were using "years of relevant experience". That is a big difference, and relevant experience is a pretty arbitrary measure.
Experience is relative here. While I agree, there should be an adjustment that captures something like "years of performance", but its harder to quantify.
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).