Comment by nine_zeros | Hacker News Reader

Comment by nine_zeros | Hacker News Reader

Parent Full thread

This is ridiculous. I would prefer being at my current job, leverage my tribal experience to build things (and I have specific things on my mind) better and faster.

If I pitch this to my CTO, he will agree that using my knowledge to build things better and faster aligns with business goals.

Only middle management rationalizes theories such as you proposed. Middle management sometimes just forgets what is the goal of their job and instead focuses only on their actions (self obsession), ego and the presentation of success. An example of middle management self-obsession is your use and throw mentality. Middle management does this because they don't actually listen to their reports. Managers think they are on another dimension and don't need to hear anything from anyone.

A really competent middle manager would know that senior engineers, especially ones with tribal knowledge are the real 10x engineers in practice. Not because they type fast, not because they are hungry and energetic but because they can process situations and circumstances faster in their head to yield results.

If I were a middle manager, I would do my utmost to retain trustworthy people around me. It's almost a no brainer productivity boost.

Agreed; someone who says "engineers produce their best work 2-3 years into a role" is a manager who has created an environment where an engineer's best work is produced 2-3 years into a role. This isn't a recognition of some universal truth; its an observation of the environment they had a hand in accidentally engineering.

It is similarly easy to envision an environment engineered to encourage engineers to produce their best work 3 months into a role; Give new engineers one really exciting, well defined, small greenfield project, after that move them into a legacy maintenance role, never give bonuses, raises, etc. I know I'd get burned out pretty quick; my best work would be very early on.

It is harder to envision a systemic change to encourage engineers to always have produced their best work yesterday. I'm not suggesting its easy; by far, the easiest and most common course of action is exactly the environment the parent commentator engineered, where engineers peak a couple years in. But, don't be fooled; the engineering division absolutely suffers in this environment, and it is possible to do better.

It's not necessarily "ridiculous".

AFAIK in US is typical to change SWE job every few years (those 2-3 years indeed). Those who succeed in doing this consistently (I'm not implying one should, or not) ganerally end up with a high salary, a higher position, and more satisfaction (assuming that change give them satisfaction).

Parent's observation may be a reasonable explanation when looked into context - the time to move on arrives after 2-3 years, and if there's no strong incentive, devs will start to feal uneasy, and move on.

You've got it the wrong way around: usually companies have decided for whatever classist reasons that they have some kind of maximum raise per year. This ensures that after a few years people who are actually getting better at their jobs are falling quickly far below market rate for their level of experience. So, those that feel like they can move on, since it is the only possibility for increasing their pay meaningfully.

This is not specific to engineering positions, it is a pretty common fixed policy in many industries.

Anecdotally, all the devs I personally know who hopped around like this did so because promotions/compensation were stalled out at their current job. Almost all of them would have stuck around if offered competitive titles and compensation, but they were often being paid 25-50% less than they would be as a newhire at the same company.

This has been the case for most orgs I've been at, I tend to tie it to poorly managed growth and planning.

it's shocking the number of developers I've seen left standed in their carrer progression (to quit eventully) due to overhiring and ending up siloed away somewhere

but I guess that's just kind of the way it goes working for other people though

> Parent's observation may be a reasonable explanation when looked into context - the time to move on arrives after 2-3 years, and if there's no strong incentive, devs will start to feal uneasy, and move on.

This is like saying, "Making people drive slower will reduce total number of accidents. So lets just reduce all speed limits to 25 miles an hour. It's only the obvious solution right?".

This kind of lazy thinking is called incompetence, because finding really good balanced solutions is actually work. This work involves observing problems, understanding root causes, piloting and experimenting, bringing other mangers, skips and CXOs into alignment, executing retention deftly while keeping reports happy. But this is too much work for managers (but of course too much work for engineers is never too much work).

What a joke! No wonder SWEs complain so much about management.

Just as an aside: one of the best one can do in terms of policy is to lower speed limits to reduce accidents; it's proven to be very effective in countries like Finland. Far from the only, but one that requires zero changes to existing infrastructure other than changing signs.

> For example, I genuinely don't know if software developers have more of an impact than the product designers

Explains why this mentality exists. Middle management cannot see the impact.

Truly, sometimes I wonder if ICs should be allowed to fire managers if managers can't see what brings value.

Software engineers are allowed to fire managers. It's called quitting and becoming a consultant. It often leads to a large pay bump, but also comes along with assuming all the bullshit that your manager does for you, so it's not for everyone.

No. Firing is not the same as becoming a consultant. ICs should be able to fire managers, along with their health benefits. Let managers take recourse as consultants.

Hi, Person currently in middle management here. While we'd love to pay our good people more, at a moderately sized company and up, we operate under an unbelievable number of constraints, from HR, finance, etc.

You might have constraints but you can still raise your voice EACH time attrition happens because of constraints. Only then will the system change and make lives easier for everyone.

If not, you are forever going to be stuck in the cycle of hiring and attrition.

Speaking from experience, most large tech companies view engineers as area under the curve, as fungible hours. Speaking out about attrition usually doesn’t have any impact at all above the Director level.

> Speaking from experience, most large tech companies view engineers as area under the curve, as fungible hours. Speaking out about attrition usually doesn’t have any impact at all above the Director level.

And blindly accepting things as it is, is the root cause of corporate decay.

If you want a high performance team that cares about management and the job, management will have to return the favor. If corporate structures prevent managers from doing this, managers need to band together and fight HR or whoever is far behind the curve.

Sorry, you are representing your company to the ICs. If you, a middle manager, can't talk to the powers-that-be to change the system, your reports will lose their trust towards you.

I never said I was a middle manager. You’re assuming that an experienced view is somehow an endorsement of the status quo. I specifically lead a very high performing senior team and this issue is the reality that we struggle with.

You need to have a realistic view of how things work to make progress, and managers banding together is comically unrealistic.

Each company has to decide which departments will run which parts of the company.

In a company where HR or Finance runs tech, you’ll get one set of outcomes. Those outcomes are likely different than if tech runs tech. It’s not shocking to me that Google and Netflix get the results that they do; in those companies, HR/Finance isn’t running tech.

the entire point is that companies spend far more money having to replace current employees because they don't give raises.

Recruiting and onboarding a new engineer takes months and the lost productivity is at least 100K when you factor in engineering hours spent interviewing, recruiter fees, months for new dev to learn code base, etc.

Reply on news.ycombinator.com