Hacker News new | past | comments | ask | show | jobs | submit login
Why don't tech companies pay their engineers to stay? (marker.medium.com)
506 points by mattydoincode 54 days ago | hide | past | favorite | 499 comments

To chime in with my own anecdotal opinion that is likely to anger some people... in my experience most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on.

After observing this I don't really mind hiring people to work for 2-3 years and then have them move on to another role, and most people I hire I do so with the expectation that I'll get a good two years of work and not much more.

A very small percentage of people continue to improve over the long term, and those people I am happy to continue increasing their pay, but I don't really go out of my way to retain employees and I don't think it's particularly worth it to do so.

This blog post mentions a kind of impact based compensation structure, and while I can respect the idea behind it, I am skeptical that they've managed to find a deterministic and impartial way of measuring "impact". I don't presume to have such a system so I pay based on what I observe in the market and let the market decide what the value is of software developers. For example, I genuinely don't know if software developers have more of an impact than the product designers, or the legal department even though I pay software developers much much more. What I do know is that it's much easier for me to hire a competent lawyer or UX designer than it is to hire a competent software developer and there are many more competent lawyers and designers out there... so I pay them less, regardless of whatever objective measure of impact may exist.

I would look at inverting the causality there. If your data is accurate, I think it's better to say, "Most companies create developer jobs that get boring for people after 24-36 months."

I was chatting with a Trader Joe's cashier Sunday. It turns out they change jobs every hour. That was a surprise to me; when I long ago worked in a grocery store, I was assigned to one position for 8 hours for every shift. Why does Trader Joe's do it? To keep things interesting: "She tells Money that the change in jobs during shifts helps to keep things interesting for employees. 'It's perfect because it breaks down your shift. You don't get tired doing one repetitive thing,' she told them." https://www.mashed.com/175743/workers-reveal-what-its-really...

If Trader Joe's can do it hour by hour, I think tech companies can do it at least every year or so.

I'm hiring right now and one of the major draws for the good people I'm talking to is the chance to do something interesting. If that's why their coming, it's unsurprising that I'll have to keep giving them that over time. For us, and for most places I've worked, I think that's doable.

I worked with an engineer. She told me that when working at her previous company they permitted you to switch teams every 2 years. Every 2 years she would take that opportunity and got to work on a huge variety of projects with lots of different people. Some of them good, some of them not.

It kept her there for 12 years or so.

I've worked at a (giant well known) company/bank in New York that basically mandated that people switch jobs internally every 18 to 24 months. It was part of the expectations. I was there for 4 years. I had 3 different roles in 3 different teams.

It helped a lot in fact in doing quality work. Thinking that you will inherit things you didn't do. That some other people will inherit your work / decisions. And always learning new things / keeping best practices in mind.

It's something I've kept in mind everywhere I've been.

Is there a trade off between depth and breadth here? While not the SV tech scene, I remember working for an aerospace company that had some people in the same positions for a couple decades. For the administrative positions it seemed to breed complacency, but for the technical positions it seemed to provide a very deep level of technical expertise that would be difficult to cultivate within a couple years

the other side from my experience at a previous engineering job is that it can also breed deep defensive layers around bad engineering work.

the same 3 core people stayed on the project for 11 years from the begging and hired and fired around weither you're a threat to their position. managers would come and go, they were helpless and held no real power in the project, until they settled for a puppet manager who would defer every decision up to them and act as a secretary.

the result was a huge pile of tech debt that only they could touch and they kept getting raises because the project couldn't afford to lose them, until the project died of it own weight.

same, i joined a place where it turned out a small group of people basically held all the power and had created a byzantine system only they could reason about. management was also trapped because the devs who knew the system held all the power.

For finance, the primary goal is to prevent corruption, the intent is not quite the same as tech.

This is smart. I left GS right around the time they were starting such an (similar?) initiative. It also makes employees more fungible, on average, which is nice.

This was GS indeed. I personally liked that a lot. I've learn a lot there.

I don't know of any such mandate in GS, was it for a specific division or group of teams? The company culture supports moving internally, but I never heard of anything like a mandate in my very recent stint there.

Circa 2014 they started a program where Analysts temporarily work on teams that did not hire them, following their three-month orientation. Based on the parent comment, it sounds as if it was taken even further. I was in the Tech Division before it was rebranded as Engineering and merged with SecDiv / Core Strats by Eli Wiesel et al.

Ah, good guess!

I suspect there is a correlation between companies that have a culture of letting engineers change roles/departments (and a clear process for doing so) and retention/average tenure.

As much as everyone hates on Amazon, no manager can block a internal transfer, maximum they can do is keep you for 4 weeks (with a very, very good reason).

The average tenure on many, many teams is 6 months.

Does help starve off the boredom.

As long as you don't talk to your manager ahead of time. I watched a colleague tell our manager that the job wasn't in line with what was explained (colleague was right, he wasn't a fit). Instead of the manager moving him into a new roll, my colleague was PIP'd. When my colleague did try to transfer, the PIP blocked it.

If you have a good manager, maybe its fine. But if your manager needs some headcount to cut.... don't trust them.


That's untrue, a manager can put their employee into a performance improvement program (without even needing to inform them) which would block them from any internal transfers.

How does a pip effect improved performance when the employee isn't even aware they're in one? Is trying to switch teams the only way to discover that, or are there other indirect ways?

But HR sees it as a way to prevent a subpar employee from escaping the natural HR process. The fact that you have not been informed yet is just a failure of current management to follow process, but does not obsolve you of your subpar performance. HR is there for the company, not for you.

But really, if the only goal is to not be able to shirk a PIP by repeated team-hopping, the PIP should just follow you as you move teams rather than blocking your progress, right?

"Here's Joe Candidate, he applied for your open position, and he has a 3 month old PIP on track to be resolved in 3 months. Accept or decline the transfer to your team?"

In theory that would be good. The issue is that a lot of managers don't like dealing with problems. If somebody is doing badly and maybe should be fired (which is what a PIP is supposed to indicate) you don't want a manager just passing the buck to some unsuspecting team.

Ultimately, I think you're right. It's impossible to build a bureaucratic pachinko machine that will make the correct personnel decisions. You really need line managers dedicated to coaching staff, and higher-level managers coaching line managers. One-size-fits-all rules are not the optimal solution. But bad management is endemic in so many organizations that I'm sure these abuses go on all the time.

Amazon employees attempt to rotate to Google every 2 years.

False. In many teams half of the engineers are randomly put on pip and cannot switch team.

Half?!? In most companies, a manager with half their people on PIPs would indicate the manager is really fucking things up somehow. Bad at hiring or bad at managing. That's not the case at Amazon?

People will believe everything (negative) they hear about amazon. And not bother to verify any of it.

It would take several weeks to get to grips with a new team / project - must be very hard to get much work out of a team member before they are off.

Changing projects is only half of it, though.

Let's say I want a new project. I can search for a new team internally, find a mutual match, sign on, start and.....keep my current salary.

Or I can search for a new team externally, find a mutual match, sign on, and get (in most cases) a significant raise and a new sign-on bonus.

Even at a company I like, there's a significant incentive to leave.

This is true in many cases but internal transfers can still make sense.

Searching costs are a lot lower internally (no leetcoding needed in most cases, hopefully) and you are more likely to be able to land something outside of your current skillset, increasing your long term compensation and job security.

Only difference would be, that in current company it is more easy to get an understanding if new project management sucks.

> People hire at companies, bbut leave their boss.

In my anecdata thus rings true.

Many large organizations do this for promising workers who are being groomed for managerial or leadership positions. The goal from the company's POV is to have people who are familiar with many aspects of the business and are comfortable with working with new teams/challenges, but I think it also appeals to people who like being challenged ... or are willing to do whatever it takes to reach the top levels of the organization.

Usually companies don't increase pay when you switch internally so the only reason to do that would be because you love the workplace so much that you don't care if you get payed much more somewhere else.

Where I work, switching teams basically requires a full reinterview (technical questions and all). At that point I’m going to have to interview prep again so I may as well interview around other companies for a pay bump. If there was less friction to a team change I’d be much more likely to stick around.

Interesting. Not for developers, but essentially the same thing happens in the UK civil service.

I would really appreciate that as a developer, I have definite gaps in my skillset that I haven't needed (been paid) to fill. But everyone would have to get out of the mindset that developer Joe 'knows everything' about X.

The perfect match would be pairing a developer that can explain some technology to a 12 year old with a developer that has the equivalent knowledge of a 12 year old (for that technology.) That would keep things interesting and build a very resilient organization.

I used to manage a team of mixed very-experimented / very-juniors and I'd make sure every senior worked on stuff I knew were not in their comfort zone, and assign tasks in their expertise domain to juniors. They'd act as consultants, while checking other parts of the codebase/docs (as noobs) for incoherencies, sand-in-gears, and improving them. Over time, the experts kept things getting better, up to their common standards, and the juniors would level up far more quickly than other parts of the org.

To keep things interesting/challenging for the experts I'd have them also reach across domains (to system eng, safety, quality assurance, bids, R&D) and sometimes even overreach (blur the boundaries) while protecting them from corporate-strife. Software is far more interesting in the context of the product, the customers, actors on every critical team. I'd also have them try new techs, or find some innovation/maturity budget for 'pet peeve hunts' and we'd often end up with new tools, large-scale improvements in code, perf, readability, robustness, observability, or testing. I'm going off topic here but I'm sad that 'Slack', the book, isn't more widely read.

I stayed at my previous company for five years, but worked in four different roles across that time:

- 1 year doing iOS frontend/product - 1 year doing low-level iOS systems - 2 years as a PM - 1 year doing backend

I was never bored. I think giving engineers the flexibility to move around (provided they stick with one thing for a year or so) is a great way to retain folks. I can also say my efficiency during year 5 was fairly absurd (I won't necessarily say overall productivity was higher at the very end, since my interest in the company was waning, but I saved a lot of time by knowing exactly who to talk to and how systems across the stack worked).

That's a great idea on TJ's part. I have also wondered how giving some amount of project ownership to low level employees would help with morale. In grocery stores you see every little thing optimized by a marketing team; from the way products are stacked, to what the cashier is allowed to say to you. But what if some of these jobs were given to the employees? I think we need to let workers be more creative. Give them a reason to feel invested in what they're doing and reward them for trying hard. You can find what they're good at over time, the hard part is making them feel like what they do matters.

It seems like modern management theory has gone out of its way to optimize out the impact that any one low level employee can have on the company. And that makes sense when the goal is to make money. But what you're left with is a society full of people in mind numbing dead end jobs developing psychological issues.

> But what if some of these jobs were given to the employees?

This seems like another thing Trader Joe's does—I've been to their stores in a few places I've lived, and while they always have a similar aesthetic, a lot of the specific decorations seemed to be unique per store with nice local details. Of course, this could still be done in a totally top-down way—hiring local consultants or something—but I wouldn't be surprised if a lot of that was done by the store employees.

> And that makes sense when the goal is to make money.

Abstractly, I expect that this isn't the best way to make money. Modern management practices seem to value legibility and control even at the expense of expected income and company resilience. This probably says something fundamental about our culture, philosophy and incentives, but I'm not sure exactly what!

>Trader Joe's

It's only been a year since they were in the news for not letting people wear things that say Black Lives Matter.

And there was also the employee fired for sending a letter to the CEO about working conditions.


I think there was a boycott, but people move on so quickly.

There's no need for employees to be able to run personal political campaigns directed at customers at work.

Would you also insist that TJ allow employees to wear "Meat/Abortion is Murder" buttons?

> employee fired for sending a letter to the CEO about working onditions.

Allegedly. The journalist made no attempt to investigate or disprove TJ's side of the story, not even to ask the employee about it.

>The journalist made no attempt to investigate or disprove TJ's side of the story, not even to ask the employee about it.

They did! The TJ response is right there, after the termination letter, and the way I read it, they confirmed the story beyond a reasonable doubt by producing a denial that only sounds like a defense without context.

It says, "store leadership terminated this Crew Member's employment because of the disrespect he showed towards our customers. We have never, and would never, terminate a Crew Member's employment for raising safety concerns".

Their excuse is that he was not respectful enough to the customers...by demanding management exclude people (after 3 strikes) who refuse to wear masks and are abusive. And this is not a health concern, nor did they have any problem with the other health concerns. Really??

This is how every professional defends the indefensible these days. They craft a "non-denial denial" that communicates a falsehood to people who don't have the context, and doesn't technically lie or deny anything to people who do have the context. It is truly having your cake and eating it too.

Exactly. And if you're curious what this says, I'd recommend reading Spender and Locke's "Confronting Managerialism". It's a great look at the dominant ideology of MBA-style management. And for me Rother's "Toyota Kata" was a good inspiration as to how to think of management not as control layer, but where teaching and support are the most important functions.

Absolutely this. Where I work, changing teams isn’t frowned upon. I was in one role for a few years, then moved to another. I know the systems that are used most widely, the data, the business, I know a particular side of the business inside and out, and I already have important relationships and lines of communication.

And now things are interesting again.

This approach reminds me of the DevOps practice of breaking down information silos: make everyone learn a little bit of everything so that no one becomes a risk.

The Japanese corporation I worked for had engineers and managers change jobs every two years.

One of the reasons was that they wanted to "cross-train" people. They liked to have a lot of process, and tended to think of employees as "Swiss army knives," that could adapt. They had style guides, and a whole infrastructure (HR and technical), to support this. Lots of training.

Not sure how effective it was. I feel that they weren't as productive as I'd like, but they were really good engineers. I had a lot of respect for them (which doesn't mean that I didn't want to strangle some of them; from time to time).

The Japanese university where I work is similar.

Much of the administrative work related to educational and research program management is handled by the tenured faculty, and we get rotated regularly through administrative positions. In the sixteen years I've been there, I have, like most of my colleagues, served on a dozen or more committees and have managed programs for periods of several years each. The result of this process is that faculty members tend to become, over time, reasonably competent administrators with a broad understanding of how the university functions, and that in turn helps the university—a large, necessarily complex bureaucracy—to function reasonably well.

We also have a small professional administrative staff, and they also get rotated through positions every few years. They must keep really good documentation of what they do, as staff members are usually able to get up to speed on their new jobs very quickly.

Yes, but this won't work because there's just not enough different things for an engineer to master. ;)

More seriously, your observation is brilliant (and almost makes me wish I hadn't just accepted a new role). Because the software field contains such a breadth of things to know and breadth of potential applications, it's hard to get very far without having the kind of mind that is motivated by some level of intrinsic interest, and that can be a currency in its own right.

This is something I love about Facebook, fwiw. Engineers have tremendous liquidity in movement.

True, but Facebook also reorgs every six months, moving team responsibilities across orgs and cities all the time.

Surprise! Your team is shutting down and being moved to New York! Go back to the dating pool!

FB is a company that is successful in spite of all its internal failures.

I worked for a company where devs would rebel because teams were partly re-shuffled at the beginning of a new year! I guess people are different.

Yeah, I don't think it really has to be mandatory, but it certainly should be allowed and encouraged.

In the case where people were objecting to being re-shuffled, did they get to pick where they went? Or were they just told? a little agency can help a lot.

In the first year we just told people, which was obviously very stupid in hindsight.

In the second year, we had a survey where devs could say what their preference was: (a) team/specific devs (b) topic (c) none

That worked pretty well.

Glad to hear it!

I am currently a SWE student, and non-traditional. I am a full time student with wife and kids. I work full time and prior to starting school and current job, was in the Navy. Now that I am close to graduating and looking at companies, I am trying to find tech companies that offer a breadth of areas to work in so precisely I hope I can find a place where perhaps I move around. Being in the Navy and working in chemical manufacturing, I know how dull and boring doing the same job over and over gets. On deployment (on a ship), we referred to it as ground hog day like the movie.

One more point of anecdata: I've been with my current employer for just over 14 years, and I've worked on probably about that many different projects--generally two or three at the same time--in a variety of roles and with a variety of technologies (often with some degree of leadership, both formal and informal). There are many aspects of my current situation that I appreciate, but the plethora of options available for me to work on certainly feels like one of the big reasons I've stayed for so long.

Didn’t know that about Trader Joe’s, it’s really smart. To your point: for many companies out there it may be easier to raise compensation a bit rather than to figure out interesting tasks for their engineering force. Business usually wants its employees to solve specific problems, most of them mundane.

This. Most companies pay lip service to internal mobility, but I still see managers trying to talk people out of it (presumably so they don't have to hire and ramp up a replacement).

And that ends up being self-defeating over the long term, because oftentimes the developer will quit the company entirely if their requests for internal transfers are stymied for too long.

Something that really helps me at my job is I have 2 primary roles that kind of wax and wane. When I get bored with one, there's always something to do in the other.

Did Henry Ford figure that out like 100 years ago? That people get bored on the job.

A software dev changes between a wide range of tasks pretty frequently, if "stock shelves, cashier, repeat" is your basis of comparison.

You're not really making an independent measurement here. You see developers "stagnating" and moving on; how do you know that's not caused by lack of pay increases and other things you're doing (letting people pick new projects, for example, to keep them interested)? Maybe if you did "go out of your way to retain employees" you'd have employees who end up making your business even more successful during their longer tenure.

Pretty much. Honestly if I can get a 20% pay raise by switching jobs, my job is to do the absolute minimum amount I can do to stay under the radar, why would I try? If I wanted to try I would go work somewhere else.

There's just a complete mismatch in how much the company I work for values the experience and skill I gain over time and how much everyone else values it. Over time recruiters come to me with opportunities to make more money, they try to convince me to leave. It's such an obvious disparity I can't help but stop caring about the job I'm doing when it's only real utility to me is that I don't have to put in any effort to keep having it.

>...I can't help but stop caring about the job I'm doing when it's only real utility to me is that I don't have to put in any effort to keep having it.

Yikes! That's my current situation in a nutshell. My biggest concern is that I don't want to risk jumping ship and landing at a toxic company/team, or landing in a bad work culture.

Don't get me wrong, I've got a nice vision about what I want to do where I am, but I can't get the money to carry it out, so I'm in that "no to low effort" stage.

If you land somewhere toxic, you can always move again.

In my experience there’s almost always something toxic about a workplace, it’s finding one you can live with for a few months or years that’s the trick.

It's all relative. I left an absolute clusterfuck of an engineering org (leads would scream at each other in meetings when things went wrong) a few years back. I landed somewhere much better, but now find myself complaining about much less severe problems.

"my job is to do the absolute minimum amount I can do to stay under the radar, why would I try?"

Because it's a form of systematic corruption, maybe the biggest kind of corruption in the White Collar world.

The objective is to 'do a good job' , not the minimum, in every endeavour.

Doing the 'bare minimum' to keep a job is actually generally far under-performing, as most companies won't generally let people go.

It's how entire industries stagnate and sink.

When internal participants spend most of their time fighting over the surpluses, it's over.

This applies to companies as whole as well of course, i.e. the $1B government contracts that should only be $500M etc. etc..

Do a good job. If there's a better fit elsewhere, that's fine too.

The problem is that "doing a good job" is rarely the objective at most organizations! People naturally want to do a good job; it's just more interesting and satisfying. But then we have layers of management and process and culture that push back on that in favor of control: follow directions, don't rock the boat, don't take any risks, always look like you're busy...

In a world like that, the people who just "do a good job" are characterized by some level of stubbornness coupled with an ability to navigate this kind of environment. Should that really be the key skill that matters? Is not being sufficiently stubborn "a form of systematic corruption"? That seems like a fundamentally uncharitable perspective that also provides no real solution. When that's how you see the situation, what can you do about it?

My experience has been that changing environment and process to actively trust people and, crucially, clearly signal that trust improves things far more than blaming people. If you expect people to phone it in, they probably will; if you can establish real trust instead, they'll go out of their way to make something work.

How come in your mind there's an onus on the employee to work as hard as they can but not on the company to pay that effort what it's actually worth? Unless there's a genuine emotional reason that transcends your salary (such as in community/nonprofit work) the relationship between an employer and company should be transactional in my opinion.

Sure that’s fair, but I’ve been very fortunate to have worked reasonably or very well paid jobs most of my career. Those jobs also enabled me to develop valuable skills. I think it’s only fair I put in a good effort in return.

Yes if business priorities change I could end up out the door, and that happened once, but no hard feelings. I quit all my other jobs anyway and there was nothing malicious either way.

The clothes on my back, and those if my children, the house we live in, the car we drive all were paid for by my employers. Yes it was a transaction, but a beneficial one on both sides. It’s all good.

What if my low effort is better then the other guys on my teams "good effort"?

You're also selling yourself short. You paid for all that stuff. Your employer paid for the work you did, and probably took more whenever they could; through on-call, off hours work, etc...

I try to comp my time, but I know I put in more then I'm compensated for, even when I was technically "hourly". I'm fine with that, but I expect to take back when I need it.

Putting in low effort during your billable hours is a personal character weakness that you are cultivating. You should avoid it because it's bad for you, not just being unfair to your employer. Regardless of your relative effectiveness.

> Putting in low effort during your billable hours is a personal character weakness that you are cultivating. You should avoid it because it's bad for you

Why is it a character weakness? Why is it bad for you?

By putting in low to average effort and switching jobs often, I doubled my salary in 5 years. All the while, I've had tons of time for vacations, hobbies, and having a life outside of work. And I've never gotten a single negative performance review. All my 1 on 1 feedback from managers has been glowing.

If a company could use half the labor to get twice the profit, they'd do it in a heartbeat. That's the purest essence of capitalism. Why should I behave differently? The guy on my team who works nights and weekends to get assignments done gets paid the same as I do. He's just more miserable for it.

I didn't say anything about working extra hours, I specifically said low effort during your billable hours.

Sounds like you're talking about the extra time that some places seem to expect. If that's what we're talking about - I totally agree that it's not worth it.

Ignore my last sentence then. All I mean is, I get paid the same whether I put in half effort or full effort. Full effort, which can lead to burnout and stress, is a cost to me. Why would I increase personal cost with no monetary compensation for doing so? They're already paying me for half effort and I keep being told that I'm doing a great job. So I'm not going to go out of my way to do more.

Edit: if I could double my output and know that my salary would double too, I'd do it in a heartbeat. But I've never found a company with a comp structure that can actually achieve that. It's far more effective to just go on autopilot for a year or two, then get a 30% raise at a new job. Rinse and repeat.

Burn out is a symptom that you are out of balance, if that's your path you need to make a change. Full effort should allow for a balanced life, there is stress, sure, but there is also reward and fulfillment.

I don't think the formula is particularly linear. Double value produced means double the salary is likely the wrong equation, but it is right in principle.

If you work hard you will be developing a lot more relevant skills than floating along. This makes you more valuable. Not everyone recognizes, or is willing to pay for that extra value in salary or promotions. But some people will, and some people are.

In the event you strike out on your own as a freelancer or your own business, working in that manner becomes your lifeblood that will make or break you.

> reward and fulfillment.

I get more reward and fulfillment from my hobbies and personal relationships than I'll ever get from creating another CRUD app for ${boring_business}. Half effort leaves me more energy for those things, and half effort still gives me more than enough experience and talking points to nail my next interview and demonstrate value to hiring managers.

> In the event you strike out on your own as a freelancer or your own business

I have no intentions to do this, but if I ever did, then as my own boss my performance would be directly tied to what I earn. So yes, I'd have a much different approach.

I disagree. What's fair is that they pay you for your work. Anything beyond that is just in your head. If they could still get your productive output and pay you half as much, they would. You should look at them through the same lens.

"How come in your mind there's an onus on the employee to work as hard as they can but not on the company to pay that effort what it's actually worth? "

I didn't say that.

I said they should 'do a good job'.

As should the other company staffers, execs and the company as a whole.

In an "at will" employment state - which I presume covers the vast majority of US based readers here - the final arbiter of whether someone is doing a "good job" or not is their employer. If they're still paying the employee, they must be doing a good job according to the employer's standards even if by the employee's standard they are doing nothing.

This doesn't quite work because employee productivity assessment is very grey, and there's a lot of goodwill assumed in the equation.

It's difficult to measure employee productivity. Sometimes, managers don't care. Sometimes employees make every effort to hide their lack of productivity.

Despite that we might think of companies as 'evil' - most of them are not. We're all human, none of us like laying people off or firing them. It also comes with negative political consequences i.e. the person you fired may never be a good reference in the future. The manager may have negative incentive to let people go, as their 'worth' is founded on headcount. And truly the vast majority of employers just don't want to layoff or fire if that don't have to.

What this means is that there is quite a lot of 'grey' in the system, and there's a lot of goodwill assumed by all parties.

Everybody is saying that they want to do 'remote work' and at the same time signalling that they may 'want to do the least, because technically, I'm getting paid for that?' - in a situation wherein there is quite a lot of 'trust' expected?

How do we expect employers to 'trust' workers in a 'very noisy productivity assessment channel' with this kind of approach?

It just won't work.

There isn't enough time in the world to be looking over each other's shoulders like that (I particularly don't like Amazon's approach for example).

So the onus is on us to 'do a good job'. It doesn't mean 'break your back' - it means try to do what is expected, keep your chin up, grind through it.

I feel that if people could see the big picture, and see that mountains are climbed one step at a time, that morale across the board would be higher. 'Passion and inspiration' are nice, but fleeting, whereas 'grinding' through the issues is how most things ultimately get done. In this way, they might be more personally incented to 'fix that bug' or 'get that build out'.

You don't have to think of companies as evil. They are not inherently immoral, but they certainly are amoral. They will let you go the moment it is no longer profitable to keep you. Have you been through a layoff before? The executives wring their hands, talk about what a tough decision it was, uproot dozens to thousands of lives - and then get a nice fat bonus when the cost savings reports come in, and the stock value goes up.

Things like that teach me that corporate "good will" is an elaborate show. You are an expense to them, a necessary expense to achieve a certain output. You are paid your market value, not penny more. If they can pay you half your salary to get the same output, they will. If they can lay your team off and get significant cost benefits, they will. You are disposable. That doesn't mean they're bad people, they're just doing what any self-serving profit-seeking bureaucracy would do.

Thus the relationship between an employer and an employee is always transactional, and any feeling otherwise is an illusion. It's not evil - it just is.

The only asterisk to all of this is if you're at a more community-focused organization like a non profit. But the vast majority of companies that employ HN readers are not that.

" They will let you go the moment it is no longer profitable to keep you. "

First - you're mixing streams here.

This is not 'amoral'.

This is just people trading services.

It's not 'amoral' of you to not keep the plumber on when he's done.

Second - companies actually do avoid layoffs. Most companies could layoff 10% right now and not skip a beat. Especially white collar. Google could dump 1/2 it's staff and be just fine.

Most companies have slack and generally avoid doing layoffs unless there's a special situation.

"the relationship between an employer and an employee is always transactional, and any feeling otherwise is an illusion."

Generally, this is the case, yes, why on earth would anyone think it's anything else?

Why on earth would a company employ people otherwise?

But again, once people are employed, they're not doing to drop them instantly.

It's all besides the point, in any case, one should be aspiring to 'Do A Good Job'.

"Amoral" means neither moral nor immoral. That's exactly how I would describe a transactional relationship, so yes, I'll stick with that word.

> Most companies have slack and generally avoid doing layoffs unless there's a special situation.

You're just making arbitrary claims here - the fact that companies can and do lay people off without notice and, sometimes, without severance, still confirms the nature of what I'm saying. It's all feel good until it isn't.

> why on earth would anyone think it's anything else?

I don't know; ask the others in this thread. There are plenty of people here claiming that they owe their company things (time, emotional investment) that go beyond the scope of their employment contract simply because it's "nice."

> once people are employed, they're not doing to drop them instantly.

This is simply not the case. Or, rather, it can be the case so easily and at any time that it's foolish to assume otherwise.

And truly the vast majority of employers just don't want to layoff or fire if that don't have to.

I've seen far too many corporate moves that were driven by executives looking to goose the stock price to believe that. You can argue that it's the executive's job to goose the stock price, and thus they "have to" lay off people in order to avoid taking as much of a financial hit in a recession or whatever, but that just gets us back to the original position: the company has a minimum amount of loyalty to me, and, in return, I have a minimum amount of loyalty to the company.

Layoffs to goose stock prices are not actually that common, it's also very short-sighted.

In the face of a major recession, execs are not laying off to 'goose the stock' they are adjusting to the situation.

Of course it does happen, but in the grand scheme of corporate development across all industries, it's not hugely common.

There is a difference between 'loyalty' and 'doing a good job'.

It's not expected that companies will keep contractors for the long term, but they still would be expected to 'do a good job'.

And of course companies do not lay off talented people unless they have to - that makes no sense.

Even the most darkly cynical and Machiavellian Execs will try to keep talent if they can, otherwise, they can't make money. So more appropriately, employees will at least be held onto to the extent that they materially create value.

But again, even in that context 'Do A Good Job'.

Honestly, if even it's a crap company, it still makes sense to 'Do A Good Job'. Even in the face of grind.

The only time I think it makes sense to 'not' do a good job, is where it would be truly utterly futile or illegal etc..

If someone is in a bad situation, they can eventually move on to where their 'good work' is more appreciated / better compensated.

Loyalty isn't a huge requirement, but doing good work is.

I'm not sure what you mean by "do a good job". I will, of course, meet the requirements of the role as they are set out before me. I will do that even if the job is crap. But if you want me to come in earlier than 08:59:59 or leave later than 17:00:00, you'd better be offering something in return.

My current employer, fortunately, does. Even before COVID, they were flexible w.r.t. work from home, and the management is more than willing to let you do your thing as long as you're delivering results. I will, and have, repaid that flexibility by going above and beyond in handling issues that weren't strictly my responsibility, working late on more than one occasion to ensure that deliverables got out the door in time.

However, I have had the misfortune for working for less understanding management. I've had management say, with a straight face in a team meeting, "If you're working from home, you ain't working." I've worked for management that openly ridiculed employees who had to take time off for family medical emergencies. You can be sure that, in those situations, I clocked out exactly when I considered my shift over.

> It's difficult to measure employee productivity. Sometimes, managers don't care. Sometimes employees make every effort to hide their lack of productivity.

The former is the employer's problem and as far as the latter, I assume in this discussion that the employee isn't committing borderline or outright fraud with respect to the job description laid out in the contract. Considering how many people get hired to do flex work like security guards or to deprive competitors of talent, plenty of employers are aware of this dynamic.

However, my goodwill only goes as far as "at will" employment protects me, which isn't very much.

> my goodwill only goes as far as "at will" employment protects me

Something tells me that the commenters in this thread who are defending the idea of working hard just for the good fuzzy feelings have never been through a bad layoff.

I bet they've never been illegally fired because HR has no idea how FMLA works, been through a workers' comp lawsuit because the amount of stress in the work environment triggered their bipolar disorder, or sexually harassed to the point where they had to quit to salvage their mental health.

If those sound like awfully specific examples, they are. Each one of them actually happened to someone I know.

> The objective is to 'do a good job'

Nobody has that objective except the very passionate. A company will happily do a shitty job if it will still get paid. See IBM. See Facebook and Google on customer support.

> Doing the 'bare minimum' to keep a job is actually generally far under-performing

My manager hasn’t seemed to notice that I work a 1/3 of what I used to now.

"Nobody has that objective except the very passionate."

This is very cynical and pretty much wrong.

I would put that attitude probably in the bottom 20%. I think most people want to do a good job.

It's also kind of toxic because unfortunately it spreads.

'Doing a good job' frankly, often does not even mean working harder, from a lower-performing perspective it usually just means actually paying more attention and being more conscientious.

And yes - in a large corporate situation, it's very often sometimes to feel the impact, be recognized etc. etc. - but that shouldn't dissuade from basic professionalism.

If you're truly only 1/3 as productive, your manager surely notices, but there's probably little they can do about it. It may not be to their benefit to even try to fix it.

This is what I mean by systematic decline - this is how bridges never get built, and they go 10x over budget.

This is why NASA spends $200 Billion on only a few launches.

It's why Ford/GM can't innovate.

What Space X and Tesla are doing is in some ways spectacular, but in other ways, they are just doing what they are supposed to, and they can, because people are just doing their jobs.

Life is a giant Prisoner's Dilemma. We can all spend our time trying to do the minimum, or even taking the cream off the top while nobody is looking, in which case, when everyone starts doing that it all comes down - or - we can try to be consistently conscientious.

> I would put that attitude probably in the bottom 20%. I think most people want to do a good job.

I'd buy that most people want to do a good job. I doubt very much that many care much about doing so, beyond what's necessary or what they expect to gain them greater compensation, at the job they do to earn money to pay the bills. Everyone I know with even a little of that "spark" has had it extinguished by experience. Usually before they're 30. Most reserve their good work for things that pay little or nothing. They care a lot more about that.

The big problems you raise are not because employees are not working 100% they are complex and have various causes. Employee productivity isn't in the top 10.

Won't somebody think about the poor bridges that never got built!?

For real, If there is any single problem with the world its people doing too much. The oceans didn't fill with plastic from people sleeping in. The air didn't fill with CO2 because people clocked out early on Fridays.

Take a step back and look at life. Why should it even be work? Do birds sow seeds? Are monkeys bad programmers? Or, are they just monkeys?

Oceans are filled with plastic because politicians, regulators and company leaders are 'not doing a good job'.

So many, especially systematic problems would be much better resolved when people did their jobs a little better.

Montreal just built a rail line for $500M that may likely become redundant. That's bad, it matters. It's mostly a leadership / management problem of course.

You probably know more now and get the same or more done.

Or perhaps they have and that is why your performance ratings are flat, you get a lousy annual raise/bonus (if any), and your career is stalled?

Performance ratings are meaningless if you’re jumping ship every 2-4 years and the difference is between working twice as hard is a 2% raise vs a 4% one. What companies forget is new employees see the legacy of how you treated old employees over time.

The basic structure of small consistent pay bumps was extremely effective when people stayed at companies for decades. Work twice as hard and make 2 percent more for the next 30 years, that’s a big bump. Pensions pushed that out so even people nearing retirement still had reason to care.

I am not recommending people do the minimum, just acknowledging how people respond to incentives.

The gap at big tech companies between okay and "doing well" (i.e. twice the effort) is not a 4% raise, it's a 40% raise.

That’s easy enough to check by actually talking with other employees. It’s really not a company wide question, often large raises early are fairly easy but get dramatically harder as compensation increases. Which of course change the effort:reward calculation over time.

Except they aren’t flat. I worked hard the first two quarters. Got a 5/6. Did very little this quarter and also got a 5/6.

So I’m basically just vegetating until I quit.

This is what all the cool-aid drinkers are missing in this thread. You can feel like you worked your ass off, or you can feel like you've been coasting, and still get the same performance review. I've seen genuinely valuable engineers get middling performance reviews because they didn't commit as many lines of code to Github that quarter as the other guy on their team.

That's an extreme example, but even in a "good" system, management is notoriously blind to the actual value of an engineer. In a perfect system, performance could be measured empirically and compensation would be based on that. But no one on earth has figured that out yet, and something tells me they never will.

It's not just about performance reviews.

Imagine a world in which it's very difficult to assess performance, because that's often the reality.

How does this system flourish if everyone is doing the minimum / least?

It doesn't. It fails.

'Do A Good Job'.

That the performance reviews say are a secondary factor.

If you all stop doing good work, it will fall apart quickly and you will all be poor.

> If you all stop doing good work, it will fall apart quickly and you will all be poor.

I'm replying late, but wow, this is a gem of an argument.

Really? The economic incentives that create this lucrative field in the first place are all gonna collapse if devs realize they don't need to bust ass at their job anymore? It's amazing that you think the individual work ethic of engineers is the only thing holding the tech economy together.

How would software get written if the people that write software don’t write software? Curious.

I personally want to do a good job, but some companies make that hard to employees, albeit sometimes inadvertently. Whether it's by tying people up in politics, having them do busywork, or just failing to reward them.

To give an example, at one of my previous jobs, for several years in a row I was noted by my managers as being a high performer and someone who would be ready for leadership. Despite this, I got an average (you did good but that's it) performance rating, because only a few people could get the higher rating. The first year I had just joined so I was excluded by default, the second/third year other people ranked higher and because that rating only went to about 2 people, I missed out. When after this my manager approached me about a lead role, which was extra responsibility but no extra pay, I was pretty much done.

When I was in my 20s-30s I hated people who seemed like they checked out, but I understand that a lot more now. Again, I'll do a good job regardless and if I don't get rewarded for that, I'll find the door and go elsewhere, but I completely understand why people who don't have that luxury or drive would rather keep their heads down and just go through the motions.

You may want to take some time to reflect on the issue you articulated in your second paragraph.

So you 'did a good job' and the company maybe indicated there was a future for you, but they couldn't fulfill it. That's not hugely nice.

But can you fathom for a minute that it seems your peers were doing 'An Even Better Job' and perhaps better suited for advancement? At least in the eyes of the company?

Put on your 'Management Hat' for a moment and understand that maybe it's unfortunate you thought there was an opportunity where there was not, but that those kinds of indications are fleeting anyhow.

Someone thought they were going to Lead the League in Scoring until it turns out they didn't.

At very least, despite the companies misrepresentation, a lack of professional maturity for young devs. to assume that 'hope' is a guarantee of anything. When you're a manager, you're a manager, before that, it's all talk.

This scenario isn't even a 2 out of 10 in terms of the mistreatment or misappropriation of employees - it's just a mostly normal thing that happens in noisy channels.

Maybe they were thinking of advancing you - someone else came along. That's life.

I'm glad you seem to want to 'Do A Good Job' regardless, but it should be noted that you're not comped for future prospects of advancement. So in this situation just 'Doing A Good Job' would be an expectation of the job. Not some thing you do on the condition of some future event.

If you are mistreated, obviously, that's not good, and it's the company leadership 'Not Doing a Good Job' but I don't see a strong indication of anything other than normal operations here.

in a world of at-will employment, why would anybody go the extra mile for an employer?

Trust and loyalty are 2 way streets, the social contract has been broken by corporations

I work, they pay me. As long as they hold up their end, I’ll hold up mine.

What’s the alternative, against their will employment? That sounds like it would suck all around.

The alternative is having formal employment contracts. I work for the employer for a fixed term. If I choose to leave before that term is up, I have to pay a penalty to the employer. If the employer chooses to fire me they have to pay me a penalty. The exact amount conditions of the penalty are specified in the buy-out clause of the contract.

This is universally how people with actual leverage (i.e. high performing athletes, Fortune 500 C-level execs, etc) get paid.

>Because it's a form of systematic corruption, maybe the biggest kind of corruption in the White Collar world.

There is generally surplus value in any exchange of goods or services that benefits both parties.

Some people insist that if the employer captures it, they have stolen it from the employee, and others think that if the employee captures it, they have stolen it from the employer.

The fact is, it's up for grabs, and what I think is salient morally, is that neither party created it alone.

I have a really hard time distinguishing between the idea that companies are entitled to some maximum of an employee's work-quality and effort and the notion that an employee is entitled to compensation amounting to most or all of the marginal value they add to a company through their labor, not just what they can convince the company to give them. Like, I don't get how one can argue for the former and reject the latter, not regarding it also as a form of "corruption", as you put it.

(I'm making an assumption here that you're not big on Marxism, I guess—maybe you do agree with both propositions)

This is the all-important point. It would be insane for me to try my best to make money for a company when the effort reward curve is so non linear. The only reason the idea of "doing the best job you can" is propagated is because it allows one to abuse workers. I could see myself working hard at a company with a flat-ish compensation structure tied directly to the revenue of the company.

"If I make a penny my boss makes a dime, that's why I shit on company time."

Right—I don't get how not putting in something resembling full effort can be corruption, but a company not paying you as much as they could, rather than what they must, isn't corruption.

What's going on here is that, in theory, both sides of the employer/employee relationship are supposed to have equal or approximately equal negotiating power when it comes to things like wages, hours, and working conditions. But, that's in theory. You know, theory: the place where markets are never supposed to be irrational and there aren't any information asymmetries to exploit.

And, pretty much all of those deviations from theory end up going against workers and in favor of employers. Labor markets aren't truly free because most people can't afford to just quit their job one day, then walk across the street to their former employer's competitor and negotiate a more suitable contract. Health insurance is so expensive that most people probably couldn't afford the amount of coverage they need without the subsidy their employer provides. Meanwhile, employers get away with stuff like union busting, just like Amazon is accused of doing, because "punishable by fine" really means "perfectly legal, as long as you have enough money," so that regulatory fines get treated like just another "cost of doing business."

Is it any wonder the only narrative about the employer/employee relationship we ever hear is the one that's favorable to the more powerful side?

First - 'Doing A Good Job' is not 'Maximal Effort'.

Second - professionals have incredible power and market wages are what they are. Most corporations do not profit in some exceptionally linear way beyond employees.

The 'Giant Lie' is that corporations are some magical entities that collect magic surpluses and shareholders and owners run off or private jets.

The vast majority of companies are not hugely profitable, and most small and mid-sized one's are not. Especially not in some disproportionately 'non linear' way.

Stock prices may be crazy - and those who trade stocks may or may not be making bank - but that's a very odd historical situation we have where shares are trading at absurd levesl relative to profits. That's a market 'dysfunction that may or may not be around for a while that some people managed to make money from, like Bitcoin, it's just a Ponzi-ish thing that has happened.

Corporations are not drowning in profits, and White Collar employees soak up the vast majority of corporate spending.

FYI everything I'm saying applies to mostly white collar professionals, for unskilled labour it's a different story.

And if the revenue tanked would you accept half your salary, say, or would you expect a floor to be applied?

If I burn out for a bit can I go down to working two days a week, or do they expect a floor to be applied?

Absolutely, I didn't mean "tied directly" to mean linearly, but even that caveat being made I would happily weather through months or even years of like 1/2 or even 1/4 salary. If I worked at a company where say the highest paid person did not earn more than say 20X the lowest paid and all salaries were tied to the revenue I feel like on compensation structure alone I would be more likely to work there than most places. I think "the compensation scheme NOT creating a heinous caste system" is actually really high on my list of things I would want in a workplace.

This is a good point.

First - side point - I didn't indicate that people should be outputting 'maximum work quality effort'. Just 'Doing A Good Job'.

Second - more salient - yes, comp is a big factor, I understand that, but it's a little bit of a marginal issue among professionals.

For workers who can reasonably negotiate a salary beyond the prevailing labour wage, it should be assumed they have market value commensurate on some level with their value.

Corporations are not some vast powerful entities that absorb all the surpluses for their shareholders. It's risky for them.

I would argue that White Collar professionals are in fact absorbing most of the surpluses.

Google could lay off 1/2 it's staff and still make just as much money.

Your point becomes much more relevant when the power asymmetry is stark, when employees have no differentiable skills or power like Amazon employees.

For them, yes, it's a different discussion around regulations, unions etc. and only when those basics are satisfied would it be fair to implore workers to consistently 'Do A Good Job'. But for processionals, it should be a matter of very basic integrity.

I think both of those ideas are wrong. A company is usually entitled to hire the most productive employees it can find for the remuneration it’s willing to offer, and an employee is usually entitled to somewhere between 50-90% of the money it can convince an employer to pay them.

Employees are never paid for the marginal value they provide, because for among other reasons, there’s no such thing. You could come up with an infinite number of different ways to calculate that, which could all produce a different value. An employee is either paid something close to the equilibrium price for the labour they’re offering, or something close to the average equilibrium price of all employed union members, if they’re a union member.

You have errors in you measurement, mostly in assuming employees only add a positive ROI when in fact their value can go negative. Thus doing the bare minimum is worth more than you think as long as the employee stays in the positive ROI (which I assume is the measure of bare minimum).

Actually working more than the bare minimum in an environment where hard work is not rewarded, is the second most sensible thing to do, after leaving. Should you work hard so some shareholders can buy a yacht? It is the job of management to reward and incentivise hard work, and not the job of individual contributors.

Fighting over surpluses is a very healthy dynamic, it’s a mechanism for individuals and organisations to understand the importance of each other’s contribution, produce price signals and improve the efficiency of the system. Instead pretending that a salary negotiated 10 years ago still matches the value of my contribution produces all sorts of distortions (eg productive employees being blocked in less productive organisations).

If a company can make twice the profit for half the effort, they will. Why should I behave differently?

> Doing the 'bare minimum' to keep a job is actually generally far under-performing, as most companies won't generally let people go.

Isn’t doing the minimum exactly the same as the company paying workers the least amount they can get away with?

Doing a good job, and doing the minimum job, are not mutually exclusive. You can do a good job with the minimum amount of work required to stay employed. There's no reason to do more, unless you're compensated for doing more.

The only honest and sincere answer gets downvoted to hell. The world is really burning.

I just hope it doesn't mean HN is transforming into Reddit, with all the zero sum game people scaring and demotivating each other.

This is a braindead opinion. Why would anyone work as hard as possible when there are 0 incentives to do so? When at any moment you could be fired without warning in a mass layoff and when even the highest performers only get 5-10% raises per year when jumping ship gives you 20%+ . You want good work then create the incentives for it, currently there are none.

It's a game where you can do the minimum or more and if you do more your boss can pay the minimum or more. If you do the minimumy your boss pays the minimum, it's a zero sum game, if you do more and your boss the minimum, again zero sum because you lost energy and he won more from you but if you both do more then it's a net positive. So the optimal strategy is to do more.

Then like the cops in the prisoners game you are tricking yourself at playing the zero sum game because of trust issues.

It seems like the optimal strategy would be to do the minimum and then job hop since the pay increase is greater and getting a raise for working hard is not certain.

I personally have not seen much correlation between pay working hard and getting pay raises, it seems about as likely as getting one for doing the minimum, and the effort to dollars ratio is usually not worth while. I don't want to put in 50% more effort only to get a 5-10% raise. Plus, as stated before, switching jobs results in much bigger pay increases making the raises irrelevant.

I'm still waiting to get a cut of those millions I keep saving the company with these projects lol

But in this scenario nothing stops the company to disclose the salary only themself.

Then they should pay me for results, not for showing up. Then I'd have an incentive to actually try to do the best job I can.

I don't think pay increase will help stagnation. Maybe picking projects will if the company has enough variety.

The best cure for stagnation I've found is to take long breaks and get into something else.

> I don't think pay increase will help stagnation.

No, but lack thereof can certainly cause it.

When there's no real reward, what's the point of putting in the extra work and taking risks? Two things that quickly break stagnation.

Agree. I've been at my place for 11 years now, and have had four very distinct roles over that time. Each change gave that revitalizing jolt of fresh challenges, technologies, etc, but with the benefit that I got to keep my seniority, influence, expertise with the in-house systems, and so on.

Have I given up potential pay bumps by not going external? Sure, probably. But I have enough to be comfortable and my company has treated me well, both monetarily and in facilitating these kinds of changes when I've wanted them.

My cure for stagnation is to play more. Amazing how playing at a pet project will get your juices flowing.

That is really good advice

I am in the same shoe of feeling stagnating this year and trying to figure out how to get out of it. The boringness and familiarness just drags along ...

Sure, and I don't really know either; my point was just that the parent is begging the question. :)

Output/performance shouldn't be determined by pay, ie pay is a lagging indicator of output/performance.

My experience has been that if it lags far enough, output starts dropping to realign with it.

Especially in cases where people are being underpaid by quite a bit, it can be a hugely demotivational factor. It's not even about the money as such, but rather about the signal how much all your hard work and effort is appreciated: apparently not all that much if you're not being paid what you know you're worth.

I really don't care all that much about how I'm being paid, I'm pretty easy about it. But it nonetheless played a direct factor in quitting two jobs because I felt I was being woefully underpaid (which I objectively was; although I guess you'll have to my word for it) and efforts to bring it up to a more standard level were being frustrated to such a degree I felt that a lot of "extra effort" I had put in to the job just wasn't being appreciated at all.

But pay determines whether I have a future at a company and if I have no future, my objective goes from getting a good performance review to avoiding termination.

By retaining a person who has "stagnated" after 3 years (setting aside the ambiguity of what you mean by "stagnate"), you avoid:

1) Three years of lesser performance from the new employee as they climb that curve

2) The very real risk that your new hire will not be successful, or if they are successful, will not achieve the same level of performance.

Also, I invite you to challenge what you consider "stagnation". It is not possible to continue linear improvement in a given role: good employees achieve mastery, and while they will still be improving that might not be evident to their managers who are looking only at work outputs. If a company does not want employees who are masters at their task, but rather want people to move up or move out (counter-productive as that might be), then it is literally middle management's job to find new roles for successful engineers, and I suppose fire the previously successful engineer if they're not up to the task. Complaining about an engineer "stagnating" in the same role after they've mastered it is just lazy thinking and lazy management.

Yes, it takes about 6m in a medium to big organizations to figure out what to do and with whom you have to speek to get stuff done. And for 2 years everything is rosy. Then you speak with you colleagues that changed jobs and find out that their income is 30% to 40% higher. That will, of course, put a downer on your day/week/quarter/year. You have 2 options, speak with your current company about compensation or leave. I tried the first option (admittently a bit late, but I did mention the problem in our review talks and other talks) after I found out that my income was 40% lower than colleagues that left 1 year before (was 3 years and a half at this company and had top marks every year, big company, a lot of cash to throw around). I was offered a measly 5% after being dragged in 4 meetings about how great I am. Left and almost doubled my income in 2 years. This is all anecdotal, but I hear it from everyone around me, you HAVE TO SWITCH jobs every 2 years, you can stretch to 3, maybe. Of course, during the last years you won't deliver as much, you have to prepare for intervews and such. This was of no benefit for the previous company. Over my 4 years there I've seen how we were bleeding knowledge that we never got back. The company didn't do so well, the thing I worked on just died after everyone left 6m after me. It's a shame, it could've been a nice thing compared with what I see offered by the competition.

> I was offered a measly 5% after being dragged in 4 meetings about how great I am.

The way you do this is interview elsewhere, get an offer for 40% more, and _then_ tell your manager that you have an offer for 40% more and that you'd really like to stay but they'd really have to do something about compensation. You'll get more than 5% then (but likely less than 40%). It's annoying that you have to invest the time for this, but it does provide data to your current company that your market rate is in fact what you think it is.

I have trouble with this for two reasons:

- If am a resource critical enough for the company to match an external offer and keep me because of the work I do and not because I'm threatening to leave, why don't they act on it diligently and offer benefits accordinly (relevant pay raises, shares and etc.)?

- The moment the company becomes aware that I'm considering to leave for some place else, I'm a potential replacement, if a good candidate or a layoff comes along.

If I'm interviewing some place else, when I put my notice, I've made up my mind, I won't stay around long term.

> - If am a resource critical enough for the company to match an external offer and keep me because of the work I do and not because I'm threatening to leave, why don't they act on it diligently and offer benefits accordinly (relevant pay raises, shares and etc.)?

It's not about being critical. Even as a more or less interchangeable programmer, if you've shown that you're actually any good then you're worth keeping.

> - The moment the company becomes aware that I'm considering to leave for some place else, I'm a potential replacement, if a good candidate or a layoff comes along.

If the company/team/project is growing then there's no reason to drop someone, and if it starts shrinking then you're better off being the first out.

Because your were staying for the pay they offered. While they will give you a raise every one in a while, they don't really have an incentive to give you a big raise.

Worth noting that this tactic is risky, especially at smaller companies. A lot of managers might get you the raise to avoid immediate disruption, while assuming you're out the door in a few months and acting accordingly. You might suddenly find yourself frozen out of desirable projects.

Yes, it assumes a dysfunctional company that values profitability over keeping engs comfy. But every larger company I know of works like this, due to market forces I suppose.

The company knew the problem. I had a discussion with the manager of another team, and she was well aware that I/we were payed well under market prices. They just banked on the fact that to leave it is a lot of work, and some people will avoid that. New hires had market lvl salaries. I could leave and come back, but why would I do that in a company that clearly didn't value me.

Or take the 40% boost and come back two years later for even more.

This is kind of the strategy, every 2 years. It's a new company because I/most ppl kind of feel slighted by the previous employer, especially if we know a bit more about the compensation of their direct manager/other colleagues. It's a churn and I hate it. I have ideas about how to improve the things I work on, medium to long term plans for different components/features to make things better. But now, after about 2y I have to drop everything and start interview practice. I literally have to discard all thoughts of improvements and switch to interview mode.

I think there's also an issue that a software engineer's job changes as they're more tenured at an organization. When you're newer, no one expects anything of you other than to come up to speed and build new stuff. If you have a project that doesn't require deep knowledge of the existing systems, push it to the newer guy.

Only once you have deep knowledge of the systems you work with does it really make sense to give you work like a complex redesign of a group of components in an online system. And you then have a responsibility to help new team members learn. You do more code reviews, and more consulting on projects for which you are not a primary contributor. And you get ugly projects that are related to your area of demonstrated "expertise". Is that "slowing down"? Or are you just doing different kinds of stuff? And is it because the engineer stagnated, or that the organization created a morass around them?

Well said. Typically in year two your job has more than doubled in the workload and responsibility that you're asked to carry.

Which makes the line chart even worse. Pay is flat but the demands of the job are not.

This ignores something very important: tribal knowledge.

Truth is, losing a tenured engineer carries a MUCH larger cost than HR and some managers seem to understand-- these engineers understand the nuances behind why certain decisions were made, what kinds of things tend to work and don't, minutiae of various systems that simply will never get documented, etc. Not to mention the influence they can carry in the org.

You're not wrong that a lot of engineers stagnate after a few years... but it's a big logical jump to put that blame on them rather than the org they're joining.

That said, I like to always call out that there are "developers" and there are "engineers". The majority of software roles call for the former and these tend to be more "replaceable". It's harder to say that for the latter where they are involved in more strategic technical decisions.

The value of tribal knowledge is even more apparent when 'engineers' describes a) traditional engineers (EE, mechE, chemE, civilE, etc), or b) software types with deep specialized skills that grow with domain experience (e.g. image analysis in medical/pharmaceutical, signal processing in audio/radar/telecom, or finite element analysts in weather/mixture modeling).

The experience gained with years in roles like these isn't just in the use of computer tools, but in how to approach and solve proprietary domain problems with constraints that often aren't obvious. Knowing the pitfalls or conventions inherent in complex or regulated domains like automobile or pharmaceutical safety takes time to learn, making those with such experience more valuable to retain.

> a lot of engineers stagnate after a few years

Stagnate is also a way of saying got good at the job.

I mean after a couple of years at a place an engineer might be the person that know the systems best in the whole world if they are no commodity. It takes year to gain the experience and inside out knowledge of a complex system.

To me it feels like I get a mental picture over a system after some time where I can smell where bugs comes from and very fast decide were functionality should be inserted. Up to that point things are just a hassle and then it clicks and becomes a breeze.

Then I switch jobs to get a pay raise and the grind begins again ...

I'm not fully convinced that this is just about the devs. 2-3 years is also about how long it takes for a nascent project to transition into a mature one, and when that happens the culture and energy of the team tends to shift. The same dev that thrives in one setting might end up out of place in the other.

I think in tech 2-3 years is also about how long it takes for one's mental model of how the world works to become stale and outdated, usually coinciding with other projects (that had been too nascent to use) maturing.

I remember that in my peak webdev years in 2008, you built webapps by designing the HTML, converting it to templates, filling in data with Django or Rails, and then adding judicious interactivity with JQuery. By 2011 the world had moved on to Angular and SPAs, and you built webapps as a single HTML page and large JS bundle with a bunch of components that you'd fetch data for over AJAX. By 2013 the world moved on to React, and you had all these tools (Gulp, Grunt, Bower, NPM, etc.) to automate packaging and code-reuse. In 2015 people were still using React and more mature versions of these tools, but what changed was the economic reality that you could make lots of money as a webdev, and the industry itself was maturing with demand for new apps dying out.

I'm witnessing this with my team at work too. We have an "old guard" of leadership that joined the team in its peak years in 2018/2019, and learned (and often wrote) the tech stack as it existed then. Now our team is colliding with infrastructure efforts that started elsewhere in the company and were too immature to use last year, but are now starting to bear fruition and get widespread adoption throughout the org. People who were experts in the old way of doing things find that their skills and projects are now largely irrelevant.

I think it's specifically a disease of the frontend community to believe that nothing you knew about programming 3 years ago is relevant anymore.

> I think it's specifically a disease of the frontend community to believe that nothing you knew about programming 3 years ago is relevant anymore.

Exactly, and it is a shame. Stability and building on the shoulders of giants is how progress is made. Not by rewriting everything all the time.

Luckily I don't work on frontend UI stuff. I learned UNIX, kernels, cryptography, TCP/IP, SQL and similar technologies in the late 80s to early 90s. While all of these areas have evolved and progressed, it's been a gradual incremental change year to year. A textbook on any of these topics from 1990 is still recognizably relevant, even where details have changed over the decades.

Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it).

I've observed similar technology shifts with backend code (where MySQL was hot in 2003, PostGres in 2006, MongoDB in 2009, Cassandra in 2011, PostGres again in 2015, and now there's this huge explosion of storage solutions) and in platforms (where we were all about the web in 2007, all about mobile in 2010, all about blockchain in 2013, all about smartwatches & VR in 2015, and all about Ethereum & smart contracts in 2018).

> Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it).

That's exactly the same web-dev mindset, only applied to backend code. I find it remarkable that you take a half-life of 12 months to be a given, rather than a screaming red flag.

Yes, the world changes, and code needs to change along with it, but it doesn't change that much. Replacing 50% of your codebase every 12 months, year after year, indicates to me that the organization is just replacing poorly architected code with different poorly architected code, not better code. The codebase is on a random walk, and any forward progress it makes is due to chance and evolutionary pressure, rather than reason and design.

Remember that the architecture competency in FAANG exists in the context of a 2-3 year average tenure. And this elides a tendency to change teams internally even more frequently than that. It is unlikely that a senior engineer rated "Exceeds" at design and architecture in Silicon Valley has ever learned from or been evaluated on the consequences of their own decisions at more than 4 years out. Median probably one year.

An average tenure hides a good number of people with longer tenure than that. I'm personally a counterexample to your point, for instance, and I know quite a number of others on other teams at my company (one of the FAANGs).

Turnover is definitely not uniform and a 12 month architecture lifespan is not, in my experience, either normal or healthy.

My experience is that architectures usually last 2-3 employee tenures, the point is the original architect usually doesn't see the outcome of their work.

I don't think workers' entire skillsets are obsoleted by any of those changes, unless you specialized in trend-chasing (obvious risk) and maybe if you refused to board the NoSQL train. But even now those 2003 RDBMS skills have a place again! High scalability companies are back to using traditional DBs where it makes sense.

I agree with this. While the flavor of the year frontend stack might change, since 2008 when I started dabbling in frontend, the fundamentals really haven't changed: understanding DOM, understanding the JavaScript execution model, understanding the layout models, understanding the complexities of dealing with data binding over asynchronous events and simultaneous users, and so on. jQuery didn't change any of that (although it drastically improved ergonomics). Angular didn't. React didn't either.

My experience has been that paradigms and tools can move fast and are relatively straightforward to pick up. Deep understanding of the underlying problem domain and the systems underneath the abstractions is harder to pick up, but the concepts move more slowly.

Depends on what you work on. If you are not on pure tech (a minority of people are), as you get closer to the business you will get insights on how things work, how you can change them, make them better etc. Only part of our job is technical, and without the business knowledge you can't push the world in which you work further. There will be pushback from the "old guard" always, everywhere, as there will be push for the "new thing" always, everywhere. Neither is healthy, and both should be evaluated with a cool head.

2008 was probably the pinnacle of web development. Everything else coming after that was a continuous line of decisions sacrificing usability and user friendliness for developer convenience.

New devs are also unburdened by maintenance work.

randsinrepose has a great article on that concept, called the old guard. Definitely worth a read. How an engineer goes from an exciting new project to maintenance mode over time. It's the natural state of things.


My personality is that, in the product lifecycle, I prefer the prototype to initial release phases. Initial conception has too much uncertainty - everything is possible but nothing is decided - and maintenance is boring.

I actually had a personality test where this was one of the things it measured. In my case, I think it did so accurately.

I agree with you that most developers do their best work after 6-8 months and that developers get less productive after 24-36 months but for totally different reasons. Developers don't get 'lazy', 'bored' or 'comfortable', they get overburdened by the company.

It is common knowledge that the average developer leaves after the 2 year mark. When that happens, everyone else is left holding the bag and they become the new experts.

Companies are full of self created abandonware.

Another person leaves and it is now two extra things that the vet has to become the expert on. Then three, then four and on and on. Next thing you know, your vet isn't getting any work done because they are holding too many bags. As the expert, they are in too many meetings trying to keep other people productive. They are pulled into too many critical issues and they are trying to mentor new developers in your ever revolving door of new people.

But they are unproductive

No. They are keeping your company afloat and you aren't compensating them for it.

I think it's worse than that, as some of the bags they are holding are full of junk.

Yet they can't just throw them away, because their peers are not confident enough to support the conclusion that there's nothing of value in there. A litany of "How can we be sure that XXXX" are thrown at the expert to clear, creating continuous inertia.

The choice becomes to keep holding the bags eternally, or go elsewhere they can start fresh.

Sometimes yes, sometimes no.

Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works?

I like to think that I am a Very Good Engineer™ but I am sure that I would produce a similar piece of "junk" if I was under the same lack of requirements, training and time.

  who wrote this garbage??? 
  > git blame
  oh crap, it was me 2 years ago!

To me it is part of the problem.

> are we lacking time/money/tribal knowledge to understand how it deeply works?

This is a serious issue when a system becomes complex enough.

For instance you work there for 4 years, became the most versed into the system, and have a hunch that the manual process to validate all submissions to some system could be wildly simplified.

But then random managers come to ask “are you 100% sure there won’t be hidden issues ?”, and by definition the answer is “no”. And since you’re the only one on the proposition, you have to bear the risk alone if you push it through. You could, but it is hardly worth it (diminishing rewards at your level, heavy bashing in case of troubles).

And there’s ton of other subtle and not so subtle situations where you have some knowledge, you could do something, but you don’t have any backing to make it worth it because others just don’t know. So stuff keeps piling in.

TBF not all companies work like that, but you also don’t end up a lone expert in places where these kind of issues are solved early and organically.

I definitely agree and I have seen this. I can understand being risk averse to change and unknowns but debt and cognitive load should be a consideration too.

This is why teams creating a billion microservices because it is the pattern of the day gets me a little angry. It is just another unused thing to watch out for.

> Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works?

I think OP was talking not about code quality but code value. A lot of legacy systems are maintained simply because we don't know for sure that there's not something that relies on them, or that they won't be needed later. The expert wants to discard them, but everyone else insists on keeping them around just in case. That adds burden on the expert.

While I think it's an organizational failure, even if folks aren't "growing" after 36 months, I definitely think there's institutional knowledge they have that helps them be more effective... the more time that elapses, the more of that institutional knowledge is lost and not documented.

Obviously it's not great to have companies hanging on by the thread of a single person's knowledge over 10 years, but I feel like at a lot of companies (especially smaller companies), this is the reality.

> but I feel like at a lot of companies (especially smaller companies), this is the reality.


There are many small companies that will be far more impacted be one of their 2 developers leaving than they would be by the owner being hit by a bus, but they'll still balk at raising salaries.

Well market dynamics over the long term should take care of companies that short sighted. They will be outcompeted by others that are better at building organizational capacity.

Yeah, that long term is not useful for the engineer whose skills should be valued right. He will be older by that time

Well that’s sorta how life works? It’s like any other market dynamic that organizes society. No guarantees that anyone will be utilized to their highest and best purpose.

> “most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company”

From what I’ve observed, the reason for this is not that people intrinsically lose the motivation to do great work.

Rather, often they realize that the company’s ability to reward their performance doesn’t scale with their effort.

Company’s have to delicately balance incentivizing performance of newer employees vs. risking alienating older employees who probably have a lower base rate but are key to the company’s daily operation.

The schelling point eventually settles to an environment where people surge for a few months and coast while doing the minimum amount of work.

This is especially true in a smaller company where cash flow may be constrained. Though the smaller companies often have more flexibility to offer non-monetary rewards like an overblown title or growth opportunities.

The “optimal” strategy for the company is to overpromise rewards to new hires to get them to do most of the challenging work while doling out minor incentives when needed once employees are indoctrinated and somewhat burnt out.

Another thing that happens is people get dragged into more and more meetings and also become the “go to person” for stuff.

I’ve seen it time and time again, start somewhere new and start with very few meetings and you can really deliver.

I’m living this currently. Fortunately, my manager understands and appreciates the value of being a domain expert and mentor and the time commitments that come with it.

> What I do know is that it's much easier for me to hire a competent lawyer or UX designer than it is to hire a competent software developer

I'm curious if you grill the lawyer on some abstract topic from their undergrad courses (possibly 20 years ago) and make them write it perfectly on a whiteboard? Meaning, the same way software developers get interviewed?

Or do you look at the lawyer's professional experience and hire based on that?

It's easy to hire people when you make it easy, it's difficult when you put up artificial barriers to prevent the hiring.

Here's a post I made yesterday, in another thread, that sort of speaks to that: https://news.ycombinator.com/item?id=28034629

I have the opposite observation. The first few years are needed just to learn a domain. Productivity doesn’t begin to take off until after a few years. If no one had worked 10 or 20 years in my team we’d struggle to get anywhere.

The impact of new hires can still be great when it comes from bringing fresh ideas and perspective (e.g processes, tech knowledge) and that obviously fades as everyone with a long tenure at the company has used the same tech.

Companies have basically said “don’t bother learn about the business except for the interview” with their compensation approaches.

Why bother spend time learning anything not applicable at your next role?

Same here. Took me over a year before I got somewhat confident with the domain, and after two years before I became fully productive. My boss takes this into account and doesn't hire people he's confident will move on in less than 3 years.

> (...) that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on.

Or, another explanation, you are mistaking cause and effect.

Maybe the people figure out they could be earning so much more somewhere else but they are unlikely to get the kind of raise at their current place, so they get disillusioned and demotivated?

And then they change the job getting the significant raise, further reinforcing the behavior. Now they join another company fully expecting the same thing to happen in 2 years.

I'm going to make a suggestion for the cause of your observation.

I think many people come into a job for a specific project(s) during which there is a ramp up period of understanding the requirements, limitations, team, how the company works, getting to know people (6-8 months).

Then after working on that project, delivering it, iterating on it, tuning it, working through potential production support issues and some scaling items...in many cases the vast majority of the work is done (2-3 years).

At that point, a few things happen because this developer is ready for a new project or new challenge, as are most of the people who were involved with that project.

Their options are:

- Find a new project at the company and restart the learning period as they transition in a potentially lateral move. If this happens, it's unlikely the company is going to give them a sudden compensation boost when in the eyes of management they're continuing to do their existing job.

- Seek training related to some advanced problem that they solved to become the company's expert on the subject, in which case the company will likely pay for the training but not a subsequent boost in compensation (because in their eyes...they just paid for the training)

- See how well they have marketed themselves to find out if the company has recognized their talent to promote them into a higher level position with an equivalent pay bump or potentially managing a team. The only problems is that you can only promote so many people, so this person will be the exception and not the rule.

- Update their resume with the newly acquired skills and have somebody else pay them market rates to start a new project at a different company, using their current job as leverage to get a significant bump in compensation. Meanwhile, you'll be paying new market rates to hire the replacement.

It's no secret why people often just jump jobs. You've finished one project and you're going to transition to a new one anyway, getting a fresh start can be a good choice. Additionally, no matter how much people like their situation in one job they will end up building up frustrations with certain people and/or management over time. As long as those people are still around, it will increase their likelyhood of leaving.

But ultimately, you're looking at the likely timing of concluding one project and then exploring options for what's next. IMO, that coincides with your timeline.

Totally agree, that's exactly how it works for me.

I join a company, work hard the first year to get a promotion and do the fun stuff, after that, I relax and stick around to vest most of the stocks and leave around the 2nd/3rd year.

I have seen so called "architects" at big co that had been there for decades bringing absolutely no value to the table. And always asked myself why would the the company retain, promote and pay these guys big bucks. Nonsense.

I call them : the legacy guys.

The only thing I can think of is that the "legacy guys" retain the memory of all the legacy stuff, and the ability for them to maintain that piece of legacy/core/monolith piece of software that no one dares to touch.

I guess that's valuable for the company, but not certainly for the employee.

They stagnate exactly because by working on that legacy stuff they can rarely learn new tech, thus they wont be able to find a job at that level anywhere outside their current company.

They are stuck.

There are jobs for architects out there.

Do you have kids?

I do. I know it is impossible to getting prep for interviews when having kids. What I do is to leave my current job, give myself a month to prep, interview get a new job. So far it has worked fine with me.

What came first, the chicken or the egg in your scenario? Did they stop doing great work because the rewards didn't match? Or did you stop matching because they stopped doing great work?

Always hard to tell.

It's not hard to tell at all. You could just, wait for it, make the rewards match the expected great work and test that way.

I definitely agree. Pay what you expect (great for great work), and if someone isn't cutting it let them know (chance for improvement). Worse case, let them go.

Instead, most companies reward no one and wonder why the good ones leave or burn out ("weird, they don't contribute at the same level anymore").

> the vast majority of people just stagnate, get complacent

Even if you're right - 100% of the time, about 100% of people - the value of having the one guy who remembers why it was done this way and how it was fixed last time it broke available to look at it when it needs looked at is priceless.

I think there's more variables at play though. A person who has been at a company 3+ years has figured out how to be effective in certain areas, but is also now asked to be effective in a much wider range of areas. They are asked to maintain something they wrote in their first year, they are asked to attend meetings or respond to emails because they have the knowledge and influence, they can't start anything new because they are so pivotal to the thing they're currently doing. And yeah, these things are important to the company, but they make the worker feel like they're stagnating. The company starts to get in their way and they feel like the only way to do something they find interesting is to leave.

Companies need to give engineers the opportunity at a clean slate. Let them shed responsibilities and pretend they're just a very competent new hire with the freedom to start working on whatever they want to. If it's a larger company, you can usually transfer to another team somewhere, but you still get pinged about stuff you never want to spend time on again.

3 years is also the amount of time it takes to become the resident expert in one of the company's Scary Basements, and then both your productivity and morale hits the crapper while this tired old beast that nobody wants to support you in modernizing needs fixes and tweaks.

You may enjoy the concept of the "tour of duty": https://hbr.org/2013/06/tours-of-duty-the-new-employer-emplo...


Thinking about my career (and others) this way has helped me remove a fair bit of stress when making job, role or project changes.

> that comes to an end after about 24-36 months of working at the same company

Have you looked into why?

The one job where I stayed over 10 years was the one where my expertise was highly respected (large degree of decision-making autonomy, no micromanagement via agile) and I was able to fluidly change projects every 2-4 years. The pay wasn't that great but it never mattered because the job was so rewarding.

Most other jobs just micromanage one to death and stagnate career, so a couple years of that kind of abuse is all one can take before moving on to the next deathmarch.

I find the biggest problem I have is that as time goes on too many people come to recognize me as a person who can likely solve their problem. Somewhat ironically this makes it more difficult to accomplish things over time because I'm constantly getting pulled into things to give my $0.02.

I fully recognize that some of this is my fault and possibly poor boundaries and time management. But it's easier to just leave every few years and also more lucrative. So there's zero incentive for me to stop this from happening.

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.

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.

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.

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.

> in my experience most developers do their best work after about 6-8 months of starting a job at a new company

Fair. That's about as long as it takes me to realise "nothing fundamental is going to change", so I tend to start losing motivation at this point.

Thankfully I'm a contractor so that's about when I exit anyway. Everybody wins!

My anecdotal opinion is that the first year it's important to show that you are productive. You cut the Jira tasks into extremely small ones and seem very productive to management because tickets get moved, but it's all smoke and mirrors (hell, you haven't seen half of the tech stack, and there is little documentation on the architecture most of the time).

A senior developer on the other hand might say they didn't do much because they think "it was just small things that I've done before". You really have to look at the commits.

Companies have been bankrupted because of the "let's just get two new ones"-mentality, not seeing that the lead time for developers to become relatively productive by knowing the ins and outs of large codebases is very, very long (for backend development, frontend is more cookie cutter).

IMO I think your hiring is broken. You should look for things like willingness to learn and ask about previous jobs to see if the candidate experience stagnation. Is your company really getting a decent ROI after only 2-3 years of an employee in a specific role??

>there are many more competent lawyers and designers out there

Curious if you could elaborate on how you came to this conclusion? According to ONET [1] there are 819k lawyers in the U.S. but 1.469MM software programmers.

If you come from a software background I wonder if it’s easier to spot an incompetent programmer than an incompetent attorney which could bias the heuristic. Or do you think there’s something else at play that makes the proportion of competent software developers inherently much lower? E.g., there’s no “bar exam” for programmers to ensure a basic level of competence

[1] https://www.onetonline.org/

A year to learn, a year to earn, a year to yearn is how I’ve heard the cycle explained.

"in my experience most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on."

Thanks for sharing this, I think you are probably "right" even though what you said is not an easy/popular thing to say.

What is your observed sample size on this? Could you elaborate on how you see people stagnate, and why you think this might be?

I'm not convinced this isn't explained entirely by compensation. There are perhaps a dozen large tech companies at which an only moderately remarkable engineer can make $500k a year right now. That number has gotten bigger every year for the last decade at least, and the much larger pool of "every other software company" is increasingly falling behind. You should follow up with your exits a few years down the line and see where they end up long term. I bet a few of them will have retired - how often do your engineers retire at 35?

This absolutely happens. A lot depends on the company and role, but in my experience after 24-36 months you tend to become known more broadly in the company and are passed around as “person who knows about x” and these type of interactions characterize most of your days. It’s not a bad spot to be, but definitely not the most productive arrangement.

It may well be true, but I doubt it for companies like AWS, which has enormous infrastructure, many implicit and explicit processes, and a peculiar culture to run such processes and leverage such infrastructure effectively. Losing good people means losing guardian of such culture, mavens of the infrastructure, and custodians of the processes.

> After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on.

> so I pay them less, regardless of whatever objective measure of impact may exist.

Ah, the classic "blame the person you hired for being bored with a low paid, dead end, high churn rate job", most excellent.

Developer stagnant?

I was in Amazon and Google, I never saw a case where the developer stagnant before the product/management went into stagnant.

Developers just write code, and they just accumulate more knowledgeable and skills with the stuff they work on. How can they stagnant is something not obvious to me at all...

That didn't piss me off at all. But agree that might offend others. I do see myself getting stale in different shops. I kinda stopped jumping around every 3 years at this point though. I might just sit for a while to make sure there is stability going forward.

My 2 cents - if some stagnate, it’s still worth working hard to retain the ones with upwards trajectory. And he kind on the way out for the others. There is a benefit to institutional knowledge.

By your reasoning do you agree with Amazon’s explicit 4 years and out model?

Sorry but I really cannot understand how this is the case. In my short experience one can't make a significant impact to a mature large scale software product in 2 years. What kind of impact I'm talking, the kind of impact that can affect the business bottomline, that can actually transform the company. Without anyone having more than 2 to 3 years of experience the level of insight into the product would be quite shallow. Not to mention people that only stay for 2 to 3 years at a job never get to experience the long term implications of their code and decisions. They never get to learn from their mistakes since they keep making new ones and moving on

This is probably very dependent on the exact role and field, but o see your point.

You seem to attract people with short attention spans.

Imagine if academia tried this.

This all just screams of issues with poor tech leadership.

Self-fulfilling prophecy?

This isn’t surprising. 3 years is about the length of time it takes most humans to become bored with monogamous relationships. There is a very high rate of breakups and divorces in non arranged relationships by the 4th year.

The divorce rate for the first 5 years is less than 20% in the the US. The US has a higher divorce rate than many countries so, in general, this is untrue.

I'm not sure you've shown that. I would be surprised if any meaningful number of (non-arranged) marriages are established in year zero of the relationship. A quick Google search suggests to me that the average relationship is established five years before getting married.

The original assertion was that relationships tend to break down in year four, meaning that they aren't likely to make it to marriage in the typical case. Marriage data is only relevant to the outliers who married early, and as far as that goes they could all be found in that 20% quite easily, I'm sure. The data provided is not sufficient to know.

No. The original assertion is that monogamous relationships AND marriages breakdown in the first five years at “very high rates”. Marriages do not. And, as you say, if you got married you were probably monogamous for some time before that.

I’m not disputing that humans get together and break up all the time.

It’s unclear that monogamous relationships breakup “at very high rates” due to boredom either. There are many reasons relationships falter, boredom being but one of them.

No. There is no mention of marriage at all. The assertion was specific to monogamous relationships.

A monogamous relationship is usually, especially when not arranged, established well before marriage. Divorce rates that hinge on years of marriage and not years of relationship does not provide us with any useful information here.

How do you have "divorces" without marriage?

And why this strange obsession with arranged relationships?

It is rather straightforward. Some monogamous relationships will establish marriage. Sometimes before the four year mark of the relationship. This means that some relationships that fail in the fourth year will also end up in divorce. The date of marriage does not usually coincide with the date of establishing the relationship, however, and thus marriage data is not useful here.

I'm not sure where you find obsession with arranged marriages? The original comment excluded arranged relationships, presumably because people in arranged relationships maintain a relationship for different reasons than those in voluntary relationships. But if you really want to understand his intent, I'm not sure why you're asking me?

Because you said "especially when not arranged" ... I thought you are part of the obsession.

Arranged marriages have a lower divorce rate but a higher separation rate; suggesting cultural prohibitions against divorce and not a higher success rate. It's odd to keep culling those types of relationships out.

I was protecting against silly nitpickers coming back with "Oh, but in my arranged marriage, my relationship began on the day we were married!" But I guess the nitpickers will find something to nitpick about no matter what.

> But I guess the nitpickers will find something to nitpick about no matter what.

Ok, that was awesome. Guilty as charged.

Marriage != monogamous relationships

True. But they said “divorces”, I’m disputing that part. They have no support for the rest either.

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