[HN Gopher] Why Your Best Engineers Are Interviewing Elsewhere, ...
       ___________________________________________________________________
        
       Why Your Best Engineers Are Interviewing Elsewhere, CodeGood
        
       Author : rbanffy
       Score  : 47 points
       Date   : 2025-11-05 13:33 UTC (9 hours ago)
        
 (HTM) web link (codegood.co)
 (TXT) w3m dump (codegood.co)
        
       | smcleod wrote:
       | Across the clients I've worked with over the years it's often
       | bureaucratic disempowerment that drives good engineers away.
       | 
       | When they cannot affect change or encumbered with toil - be that
       | from painful change management processes, restricted or privacy
       | invading operating system controls, or a work from office policy.
        
         | noir_lord wrote:
         | That and/or a single bad direct line manager.
         | 
         | One of the best managers I worked under when I was young used
         | to say "people don't leave companies, they leave managers" and
         | he was right.
        
           | whstl wrote:
           | This is the second best advice I ever got in my career.
           | 
           | The best one was still "Listen to reports when they come to
           | you, even if you're focused on your own task."
           | 
           | I wish there was this kind of advice for dealing with
           | unreasonable CTOs and VPEs. I got lucky in my last job, but
           | it took years.
        
       | esafak wrote:
       | That's what skip level connections and surveys are for. The tools
       | are there, for organizations that care to use them.
        
         | whstl wrote:
         | I don't know.
         | 
         | I have seen CEOs and CTOs tearing apart feedback from surveys
         | at all-hands meetings. To the point of mocking answers and
         | saying people are "tripping", or that "in other YC companies
         | people work 80 hours".
         | 
         | And I've seen leads/managers leaving due to micromanagement as
         | well.
         | 
         | As long as the expectation is for managers to hide concerns and
         | fall in line, the information will be hidden from C-levels.
         | 
         | For example:
         | 
         |  _> A fintech company decided to build their own authentication
         | system rather than use established solutions._
         | 
         | I lived this exact scenario. Fintech wanted custom
         | authentication! It was pushed into my team. I said no and put
         | my foot down, VPE disagreed with me and gave to another team.
         | That team failed to deliver after 6 months, and my team finally
         | ended up being the one implementing a third-party solution in a
         | couple weeks. That third-party solution costed less than $100
         | per month, because of how little users we had.
         | 
         | On my yearly feedback I still got knocked down a peg due to
         | this incident. It really hurt my career at that company, even
         | though I was in the right. That other team failed to deliver
         | other projects too, and we got the same feedback I did, same
         | salary increase. I got the yelling, I got the negative marks.
         | 
         | Of course people will rationalize this with "you should have
         | been more political".
         | 
         | Well, that's what the people being criticized in TFA are doing:
         | being political.
        
           | Viliam1234 wrote:
           | > tearing apart feedback from surveys
           | 
           | That's amateur behavior. Real pros design the feedback forms
           | in a way that only allows you to give them the answers they
           | want to hear.
           | 
           | "Which three company benefits are most important for you?"
           | Frankly, all of them are meaningless, but there are ten
           | checkboxes, and unless you mark three of them, the form won't
           | allow you to proceed.
           | 
           | "Do you understand how $buzzword can make you more
           | productive? (on a scale from 0 to 10)" Answering "yes"
           | implies that $buzzword is great. Answering "no" also implies
           | that $buzzword is great, but you are too stupid to understand
           | it, so you may be given some mandatory training on $buzzword.
           | (There is no way to indicate that $buzzword actually makes
           | you less productive.)
        
       | dboreham wrote:
       | Appreciate the time taken to write this, but imho the problem is
       | a bit worse: you grew up in a context where analysis of facts,
       | risks, knowing your stuff, were valued. That's your training data
       | and reinforcement function.
       | 
       | Here's the thing: the world in general didn't get that training
       | data upload. They don't care about your reasoned analysis. They
       | want a new boat. Like now!
       | 
       | I bet there's an email thread at Amazon years back with someone
       | saying "You're using DNS as a distributed database-- that's a bad
       | idea". But even after crashing the entire internet for a day, the
       | stock is up.
       | 
       | I recommend starting your own company or going freelance. Then at
       | least any organizational nonsense will be your nonsense. And if
       | there's any boat coming it'll be yours.
        
       | jjmarr wrote:
       | The military has a parallel system of officers (managers) and
       | enlisted/NCOs (sort of ICs).
       | 
       | Even generals will have an NCO reporting into them whose job is
       | to speak to the frontline and figure out wtf is actually going
       | on.
       | 
       | e.g. The Sergeant Major of the entire US Army used to post on
       | /r/army. If someone in the 950,000 person bureaucracy was really
       | getting screwed, he or his office would step in.
       | 
       | https://reddit.com/user/sma-pao/?sort=top
        
       | Viliam1234 wrote:
       | > The decision was made: ship now, refactor later.
       | 
       | I guess we already know how this ends. There will never be
       | "refactor later", because there will always be a new feature to
       | add, or a new product to ship. "Later" is merely a diplomatic way
       | to say "never". When the project is decommissioned 20 years
       | later, the refactoring tasks will still be in the project
       | backlog; that is if someone won't delete them first.
       | 
       | > The CEO approved 15% raises for remaining engineers. More left
       | anyway.
       | 
       | One possible explanation is that money wasn't the real issue. But
       | another possible explanation could be that the 15% was not
       | enough, but ironically it could have been the nudge that made
       | people think again about their salaries.
       | 
       | > Middle managers believe they are doing their jobs by "handling
       | problems at their level."
       | 
       | That is not necessarily a bad thing... unless they are handling
       | them by ignoring them.
       | 
       | > The monitoring system generated so many false alerts that
       | engineers had learned to ignore it.
       | 
       | That reminds me how I once told my manager: "If I get one alert a
       | week, I will immediately drop whatever I was currently doing, and
       | start investigating the issue. If I get several alerts a day, I
       | will finish my current work first, and probably handle the issues
       | in batch at the beginning or at the end of the day. If I get
       | several alerts per hour, I will just mute my phone and ignore
       | them."
       | 
       | > They watch decisions being made that will cause problems, they
       | raise concerns, and they are told to implement anyway. When the
       | predicted failure occurs, they are blamed for not preventing it.
       | 
       | Even better, they get assigned an on-call duty during evenings
       | and weekends to fix the failures when they occur. The on-call
       | duty is such a wonderful thing -- every time a bad technical
       | decision is made, you know someone's evening or weekend is going
       | to get ruined, but it is rarely going to be the person who made
       | the decision.
       | 
       | > If Sarah is leaving, maybe I should look too. Engineers assume
       | departing colleagues know something they do not.
       | 
       | I think this is a needlessly complicated explanation. More
       | likely, Sarah was a good friend, and the colleagues who were
       | already unhappy about their jobs procrastinated with leaving the
       | company because of Sarah. Now that Sarah is gone, they realize
       | they don't have any more positive job-related emotions.
       | 
       | Of course the company can speed this up by giving them Sarah's
       | work on top of the work they already had. Then everyone will
       | start interviewing like crazy, because they will be scared of
       | being the last person who stays at the company and inherits
       | everyone's work.
       | 
       | > The test: would a 20% raise keep them? If yes, it is
       | compensation. If no, it is something else and they are being
       | diplomatic.
       | 
       | Or maybe it's compensation, and the other company offers them 50%
       | more.
       | 
       | > Regular skip-level conversations. Allocating several hours per
       | week for direct conversations across all levels provides ground
       | truth.
       | 
       | I have seen a situation where a manager did skip-level
       | conversations, but only used them to tell the engineers his
       | glorious vision, not to listen to them. It's like most management
       | advice -- even if the original idea is great, most people will
       | just take the buzzword and do something else instead.
        
       | dogleash wrote:
       | I love the optimism that senior leadership is just in the dark
       | and wouldn't agree with a high percentage of the bad dynamics.
       | With the benefit of hindsight the causal link to attrition is
       | highlighted. In the moment, how many concerns would have been
       | brushed aside as nerds getting carried away with nerd priorities
       | instead of business priorities?
        
       ___________________________________________________________________
       (page generated 2025-11-05 23:01 UTC)