[deepsun]

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

[tcbawo]

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.

[bluGill]

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)

[ashtar]

This is a great way to lose your best people. Or it's pure /s

[bluGill]

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.

[pmmck]

Maybe a better term would be "critical projects" instead of "important projects" in that case?

[ryandrake]

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?

[robertlagrant]

> Coasting can be fixed by firing or layoffs

Based on what? You've just invalidated all the tools one would use to evaluate performance.

[deepsun]

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.

[darkerside]

Probably based on an engaged managers evaluation of their work output

[robertlagrant]

See above - it's strange to discount management techniques for promotions and pay rises, but still use it for firing people.

[darkerside]

I think I missed the point where parent said not to use management techniques for promotion and comp. Can you highlight what you are seeing?

[closeparen]

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.

[closeparen]

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.

[0] https://oxide.computer/blog/compensation-as-a-reflection-of-...

[TheOtherHobbes]

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.

[closeparen]

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?