Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While I broadly agree with your point, rewarding seniority is at odds with rewarding people based on how good they are at their jobs, from the perspective of incentives. The two are not always correlated and this is often why some companies hire externally instead of promoting from within.

That said, companies are often wrong to hire externally as they misattribute their problems to their employees instead of to their own leadership. It is easier for them to blame others instead of themselves.



Paying for equal performance on the measurable aspects of the job is easier to do than putting a value on institutional knowledge. As an old bird that has had time to internalize the tech stack, I can make one comment along the line of “Don’t do that, and here is why...” — getting that kind of contribution noticed and valued is harder.

Parent comment is really saying to find a way to put a value on institutional knowledge.


From my experience, I see institutional knowledge as a double edged sword - it can save you from some mistakes but, very often, it's also the thing standing in the way of progress.

I don't think I can count how many times I've seen a really poorly designed solution causing real pain, and everyone even knows it's bad, but it will never change until X leaves the org, which they have no intent of doing until they're rolling out on a stretcher. Usually X has been there a long time and knows everyone - often they've created enough messes that only they understand to avoid getting laid off. Heck, if the messes are big enough, they can even look like an above average performer to people who aren't overly familiar - generally never top of the stack though, as that might get them asked to take on more work.


> it's also the thing standing in the way of progress.

The luddite attitude is orthogonal. Does it happen? Sure. But I also have the expectation that senior staff should be identifying the New, Better Way all the time. And are well-positioned to measure “better”. It is part of providing engineering leadership. An old bird that isn’t keeping up needs a job performance message.


> From my experience, I see institutional knowledge as a double edged sword - it can save you from some mistakes but, very often, it's also the thing standing in the way of progress.

I can’t agree with you more. Having a combination of individuals with historical knowledge and new individuals with fresh perspectives can be so refreshing. We recently hired an external architect on the team. She’s great technically. However, I would argue her greatest contribution is fresh perspectives. She suggests ideas others (include me) hadn’t considered due to past negative experiences with team X or Y. By not being as aware of past histories or projects gone bad, she can encourage us to rethink things.


Usually in such cases institutional knowledge has a better chance of answering the question what causes the pain and how to fix it and what are tradeoffs.


Person A didn't do the unwise thing because they knew the system inside out.

Person B did an unwise thing and spent the weekend working to fix the consequence.

If the problem was subtle and management didn't immediate corelate the action of Person B with the problem, they are likely to profusely praise Person B's working their asses off to save the company during the weekend.

On the flipside, if the company only contains A kind of people or if A people are too influential, it's likely that you'll stick in a local optimum where people are not incentivized to try out new things that may fail but may also succeed.


I mean isn’t that why vesting cliffs exist? I’d extend them to be for far more money but over far longer if I was the employer, but the job market won’t bare it.


That's actually a really good idea. Reuse an already common tool to reinforce what you want. If you stay here longer than your 4 year cliff we'll refresh you at 1.5x the last schedule. That's about what a company would end up dumping into a person's salary who is tenured anyway.


There's also the military approach where there's a clock and you either get promoted or you are out. And then it repeats. Languishing isn't really allowed as an option.

If a job/task only requires entry level skills, why are senior employees doing them?


This is often called up or out, too. Many/ most consulting companies do it.


Isn't that what Netflix does - or at least doesn't really permit for having an off-year?


Not at all. In fact, Netflix didn't even have levels until very recently. When I worked as a management consultant, about half of people left the company every two years at each promotion gate. Netflix's turnover was far, far lower.


Yes and the parent to yours is saying that leadership are the ones not capable or willfully opposite to > noticing and valuing


Seniority has a very real value in tech, though. It probably doesn't have much value if you're say, a doctor, working with different systems each time that look similar.

But in programming, you deal with systems, you know the undocumented gotchas of the system, and understand the flow of it better than someone who's completely new to it. You know when Chesterton's fence applies and when it doesn't. I often tell startups to promote the juniors instead of replacing them with seniors, because the junior who built the system would be able to modify it better.

Even in sales and product, there's some value to understanding what the customer wants and aligning that to the features or a specific pitch and such.


> It probably doesn't have much value if you're say, a doctor, working with different systems each time that look similar.

You either don’t know what a doctor does or I don’t understand the point you were trying to drive. Doctors spend decades refining their ability to recognize all kinds of issues that have vastly different conditional probabilities of occurring. Internalizing that is the entire value of a doctor over webmd.

Being a doctor isn’t as simple as absorbing a mechanic’s guide to the human body and just doing the same procedures over and over.


I think he means that a doctor with 15 years experience after school can change hospitals they work at with minimal impact.

A hiring a senior engineer with 15 years experience, but not at your company, might not compare as favorably to an intermediate engineer with 8 years total experience, but 3 years at your company.


I think it would have been clearer if they had said "Tenure" instead of "Seniority"


Yeah, they're synonymous in many cultures (the amount of time someone holds their current post, and not experience skill). But it seems they mean different things in this context.


I agree with your general point, but medical doctors are the very last example I would have ever picked.


I think the point is that doctors are mostly interchangeable.

A reasonably experienced surgeon in one hospital in NYC is likely to be almost exactly as great on day one if he moves to the hospital across town.


Tenure, domain knowledge, and skill are all pretty different underlying things.

Promoting someone with tenure just because of their domain knowledge is an extremely good way to hit the Peter Principle. You can get people who know the system very well but don't know how to take a step back and look around and evaluate the broader context vs just plugging along the same way as yesterday. Especially if you've never hired someone with those skills to teach them. You also run into bus-factor issues and robbing-Peter-to-pay-Paul limitations around "this person's domain knowledge would be useful for this new project, but we've never ramped someone up to take over what they're doing now."

Then there are the people who manage to get tenure without actually absorbing too much of that domain knowledge... so you need to be able to evaluate that, plus skills/aptitude/potential, not just years-in-seat, when deciding who to promote, when to hire, etc.


I think you imply it, but the important part is whether someone can learn a new position.

People quoting the "Peter Principle" usually ignore that it is normal to promote beyond current skill level, since it is common to learn a position when in that position.

The Peter Principle is that eventually an employee hits a roadblock where they are failing to learn the new position. That failure is usually attributed to the person, but I would guess the root cause is usually a lack of training ability within the organisation (not commonly recognised as the problem).

I am not a manager, but I see these stereotypical misconceptions all the time... I'm not accusing you of ignorance at all: I'm just pointing out you could be clearer to help us all!


Aren't these reasons why management is supposed to exist? If they can't figure out how to manage these situations, the issue is with the managers, and the new hiring should begin there.


> you know the undocumented gotchas of the system ... when Chesterton's fence applies and when it doesn't.

All too real. Unfortunately, i do think that relying on such expertise is fraught with danger - because both your bus-factor is 1, and it makes it hard to bring up new people.

In practise, this is hard to avoid, but i think a real senior developer should know to document the undocumented, and to communicate (using various mediums) to ensure that nobody needs tribal knowledge to work on a system.


Rewarding seniority works if you have a fair system of performance management in place. Assuming your tenure at a single company is directly correlated with your ability to perform well, and grow and improve your value to the company over time, it would make sense.

That being said, when somebody finds that fair system sustainably in place at a company, let me know. Fair and accurate measurement of an employees performance, free from bias and favoritism ... I'm just not sure that's how people work.


False dichotomy. It doesn't need to be free of bias, just bias shouldn't be completely insane like "you must change job every month". In fact there should be bias for merit, but instead employees are uniformly undervalued.


> they misattribute their problems to their employees instead of to their own leadership

It seems to be the case that effective and competent leadership is the exception. Even in the military, where enormous amounts of money are spent on attracting, training and retaining leadership; they're simply aren't very many that are very effective. Mediocre leaders get promoted and that's just what everyone else gets to deal with. Other examples include professional sports, academia and politics. The tech industry is hardly an exception here.


> The two are not always correlated

Not always, but still I would assume that people with complex tasks generally become more experienced and accumulate specific knowledge over time that makes them better at what they do. Therefore, it should be the default for employees to get a raise every now and then, unless there are clear signs that someone is not performing and the employer is not interested in keeping the person.


>as they misattribute their problems to their employees instead of to their own leadership

In my own very limited experience of mid-size companies, it seems like senior leadership is first on the chopping block when dissatisfaction becomes real. However, the expected value of those positions is much larger due to compensation (i.e. $2e6 x 1 year = $2e5 x 10 years, better assuming execs can find jobs within a few years)


“ That said, companies are often wrong to hire externally as they misattribute their problems to their employees instead of to their own leadership. It is easier for them to blame others instead of themselves.”

After talking to a lot of managers it really seems that a lot of them are deeply skeptical of the people they themselves have hired.


Leadership are mostly also employees by the way.


"Leadership" usually means executives and those folks live in a different world of comp than Engineers and Project Managers, maybe even Product - but I know that bit isn't always truthy.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: