Hacker News new | past | comments | ask | show | jobs | submit login

I am thrilled to hear this. If you can't hold on to your employees, pay them more, or give them working conditions like WFH or an easier commute, then you don't deserve to have them!

That said, I sort of hate this headline. These people aren't quitters. They're ambitious, and they want more.




Companies aren't trying at all.

Just go look at the job ads and see what pathetic items they list as "benefits".

- natural sunlight - monthly social events - snacks - ping pong table

All either basic workplace expectations or intangible irrelevant gimmicks.

People are not that dumb. If you want to avoid paying people tangible benefits and what they are worth they will dump you and no amount of sunlight and social events and catered lunches is going to change it.


> natural sunlight

Is that a US thing? Never ever seen that in Germany, sounds like "free oxygen" too me.


US and many other countries. It's a sad brag that shows just how low the expectations have come down to.


There are regulations for that in Germany.


Seems there is, there must be direct line of sight to the outside world: https://www.komnet.nrw.de/_sitetools/dialog/5278

The more you know.


Wait, as in you can't be stuck in a cubicle farm without a view of a window?


To be fair, when I started in IT, around 2001, it was common for IT to be in the basement or sub-basement. It probably still is at larger companies or government contractors.


I have yet to see that listed in a job ad here. I ignore California openings, though, so maybe it's an SFBA thing.


To be fair, natural sunlight is actually a massive deal to me. I can’t focus without it and I get weirdly claustrophobic in rooms without it. I wouldn’t take a job in an office without windows, even if my salary was doubled.


Yeah I'm not saying it's not important but it's still sad and embarrassing to brag about it at the top of the list of your company benefits.

So the deal is "salary that isn't going up + a bunch of gimmicks".

In fact many of the "benefits" are designed to benefit the company such as social events outside work hours that is basically free team building activity for the company.

Or other gimmicks to trick employees into working longer hours.

Then they wonder why people hop.

Because there's nothing else other than that salary going and someone next door is offering 10-20% more.

Real and tangible benefits takes some guts to offer and they don't have it.

It could be things such as extra paid leave days, highly paid overtime or no overtime culture, shorter work days for usual market pay (say 9 to 4), private offices.

Employees will sure as hell miss a 9 to 4 job a lot more than your snack-packed kitchen and beer on tap.


It seems like these days people have to "move around to move up", or companies have a problem creating opportunities for advancement that don't involve promoting people to middle management, if one can even call that a promotion. Of course that's only one part of the bigger picture.


Is there a word or a phrase whereby the Peter Principle takes such a hold in the structure of management that it no longer becomes possible to even promote? The 'Peters' get to a position and create an artificial ceiling where potentially more capable would-be managers don't get promoted because their manager is a bit too dim to realize there are people languishing underneath them?


I think this would be territory covered by the dead sea effect: http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

IME this is in full swing at just about every company complaining about job hoppers.


I saw exactly that at the first shop I contracted at decades ago. They treated their engineers like dirt. During the interview they were told that travel would be a couple weeks a year. Then some were literally handed airplane tickets when they arrived their first day of work and left on (remote) site for months. To compound things, they would return expense reports unpaid if everything was not filled out exactly correctly.

One day a co-contractor commented at the lack of energy among the employees. He observed that none had any get-up-and-go. I thought about a moment and replied that anyone with get-up-and-go had got-up-and-gone.


I've seen this phenomenon almost everywhere. A lot of times it kicks into high gear when "the powers that be" start making big, dumb changes (though often times they don't seem quite so bad in the moment). The best talent with the most important experience evaporates.

The thing that is the most pernicious about this effect is that it can be difficult to notice objectively. People who are in the trenches, are clueful, and know first hand the qualities of individuals who leave will know immediately that this is a bad development and that the organization has lost something of significant value. Even so, it can often be difficult to back up that gut instinct with factual evidence. It often takes years for it to become fully evident unless there's utter incompetence on display, and that evidence is usually in the form of it being more difficult and taking longer to execute on challenging projects, while achieving less success as a result. The thing is, in almost every dev shop on Earth and especially in the "higher level" ones the projects from year to year or "release cycle to release cycle" are often not 1:1 comparable, each has their own unique difficulties and complexities and even without losing any talent it would take a different amount of time to tackle those projects and the results and "level of success" would still be different. Without a window into a parallel universe it's hard to say how much you've fallen behind the nominal "unevaporated" track.

And in the eyes of management it's even more difficult because they are even more resistant to the notion that something they've done has had a negative impact on the company. If the end result is anything other than abject failure, if the lower quality "dead sea" org is still able to achieve a decent measure of success, still operate a profitable and successful enterprise, and so on, then they will think everything is fine. Even if the difference might have ultimately been orders of magnitude difference in levels of success, because that alternate timeline is unknowable.

And if you wonder why so very much software is surprisingly mediocre despite many hundreds, thousands, or tens of thousands of dev-years of work being put into making it better, well, maybe there's a reason for that.


Thank you for this comment. It helped summarize my thoughts.

Do you know if there's any pattern to the big, dumb changes? Are specific changes more likely to signal shipjumping time for top talent? Or is it a growing dysfunction?


When you take stock of everything a lot of the changes are obviously bad when you think about them from the "big picture" perspective, but sometimes it's hard to have that perspective, especially as changes tend to creep in incrementally. The biggest red flag I'd highlight is just bureaucracy in all its forms. I don't mean things like code reviews or fixed processes for doing things (although in some cases those can be bad). The biggest red flag is when there's a switch from certain important decisions being made by individuals to decisions being made by some rule based on certain metrics.

Over reliance on metrics is often a huge red flag. If your continued employment, your bonus, or your promotion prospects rest on how many bugs or tickets you close, how many test cases you automated, etc. then that's problematic. Because metrics can always be gamed. And if people are being judged relative to one another based on gameable metrics then only the people who game the metrics will get ahead and everyone else will be left by the wayside. To the detriment of employee morale and actually getting the right work done that needs to get done. If you tell someone that they have to close lots of bugs to show they are doing their job well then they are incentivized to figure out how to wiggle out of responsibility for a bug or "fix" bugs using the most expedient hack possible. Instead of taking the time to investigate a bug thoroughly as far as their expertise and context allows, doing a root cause analysis, stepping back and analyzing the meta-context that made the introduction of the bug even possible, and maybe doing the work to design a very thorough fix for those problems, beyond just the limited scope of making the one bug go away in the short term.

Good development work can often defy all metrics that attempt to measure it. It can look like an average of a net negative number of lines of code written. It can look like spending a month on a seemingly inconsequential bug (which turned out to have a very interesting cause that revealed a fundamental flaw in the design of the system which required several months to fix but led to a huge increase in overall reliability). It can look like days, weeks, or months spent not writing code or fixing bugs at all. Maybe that time is spent doing documentation, maybe it's spent doing design work, maybe it's spent doing research, maybe it's spent picking apart an existing system to learn exactly how it's put together, all of which might end up being hugely valuable. The thing is, there's no metric for things like "prevented a thousand bugs from being filed over the next year". And that gets to how difficult it is to objectively measure the work of coders.

The other major red flag is when you see people treated as just interchangeable resources. Does the company seem to value people's time? Does it treat people like human beings? Does it seem like the company/employee relationship is a cooperative (vs. exploitative) one? Is the company flexible about working from home, working non-standard hours, etc? Or does it treat knowledge work like a factory job where it cares about hours worked, "butts in seats", mandatory "crunch time", etc.


Thanks. I think I agree with everything you wrote- it's good to know I'm not insane for thinking like this.


That may be the best description of the phenomenon I've described. I lived that. It was unbearable-stayed around way longer than I should have because I did genuinely and truly believe in the mission of the company. They gave us reason to and backed it up-but after a while, well yeah the water began to evaporate org wide, not just engineering.

It got to the point where engineering was down to three people-present company included-and a guy managing us who probably should have been let go long enough and neither myself or the other fellow could really stand to be around even socially-much less as a cohort and colleague (and to this day, the other guy and I strongly believe was the root cause of so many of our other engineers quitting once the former Director left, leaving jerk character as the most senior in the room by longevity alone).


> engineering douchebaggery is actually the biggest thing to hurt engineering since the dawn of time

Quote from Fetch Robotics CEO Melonee Wise on SXSW panel.

https://venturebeat.com/2018/03/13/fetch-robotics-ceo-douche...

Melonee kicks ass.


Thank you, this pretty much describes my current employer. The dead sea is so dead that the entrenched folks have established a number of policies that restrict access to various resources that are critical to performing work.

If you ever walk out of a technical meeting, summarize key details with one of the senior attendees and they tell you, "that's not what we discussed", then you probably work in a dead sea.


becoming maintenance experts on critical systems, assuming responsibilities that no one else wants

The problem is people who are not experts and do not take on responsibility, but stay anyway.

The responsibility-taking experts are the backbone of any organisation.


> ‘interchangeable code monkeys’ mindset

Which is pretty much the default mindset these days...


The market will sort it out. Those companies taking a 'doing you a favour' attitude will be competed out.


If it hasn't happened by now (this is not even remotely a new phenomenon), what makes you believe that it will happen ever?


I wish this was the case.




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

Search: