Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

Post reply on HN
Print view View original

241–250 of 316 posts

Re: How to drive away your best engineers

#241

Post by edgyquant »

lifeisstillgood wrote: post #175
nonrandomstring wrote: post #18

I'm sure we can all add plenty of fresh examples of bad organisational dynamics. Other than texts like Gall's "Systemantics" is there an equivalent to Acemoglu and Robinson's "Why Nations Fail" but for companies and projects? Here's some of mine: Put "security" before all else. Pointlessly surveil and monitor your staff for feelgood security theatre. Mandate MFA for every trivial login so that simply checking your em…

I argue it's democracy. (That can save Nations and presumably companies) Imagine voting for the CEO. Imagine voting to allocate budgets. Yes there will be a lot of pork barrel- but it might just work. I mean the idea that companies are like single cells / autonoma so they don't have to be democratic leads us to silly ideas like trying to put in place rules for not abusing the electorate. I mean if a boss is sexually…

Maybe but that can also stifle innovation. If Netflix had been a democracy they likely wouldn’t have voted to switch to the unproven online streaming business, etc.

Re: How to drive away your best engineers

#242

Post by Buttons840 »

dalbasal wrote: post #62

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…

> An effective 15 person team can outperform a 150 person team

Which is subtly different than saying a 15 person team can do the same job as a 150 person team. The full story is the first 15 people (be they developer or project managers) will determine whether you need 150 people in the future.

Naturally, all of my jobs have been at 150 companies (since that's where most of the jobs are), places where the earlier developers and PMs have balloon the amount of work to be done is a very unhealthy and inefficient way. Then I'm hired and continue to do the same.

I learned about R0 ("r not") in the pandemic, the number of other people someone infects on average, and I've imagined a "W0" at my jobs. How much work does a developer, on average, add or remove from the future of the company? Unfortunately, I believe I am a >1 W0 developer in my current job, my current work will only create more work in the future, and the company will have to hire more and more developers forever. I don't consider this my fault, but the fault of project management. It's also why I'm not worry about future job security.

Re: How to drive away your best engineers

#243

Post by cyberge99 »

kevinventullo wrote: post #235
dghf wrote: post #229

Earlier quoted context omitted.

But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.

Don’t forget the most important operation: rm -rf the whole directory and re-clone the main repo.

git reset HEAD —hard

Re: How to drive away your best engineers

#244

Post by mannyv »

This is way too simplistic. In reality, everyone has a role, and if you don't understand that role then problems occur.

The fact is, in every organization there's the technical side and there's the political side. The bigger the organization the more need there is for a political, not a technical, manager. The former manages the people, stakeholders, etc. The latter manages the product itself.

In many organizations both roles are done by the same person, who tends to do one side better than the other. In engineering organizations the manager is probably more on the technical side because engineers.

The problem is that large organizations (insert your definition of large, it could be >20) or organizations with multiple customers managing upstream expectations and prioritization are really important. These people are paying the bills, after all. At that point you need to start fending off salespeople, account managers, and other executives.

Unfortunately, telling customers to fuck off you're busy isn't the greatest path to customer satisfaction, retention, etc. You need a political manager to do that for you.

I know of a few large orgs that have formalized this tech/political manager structure, because it's effective. But you need to understand what's happening and why. If something rolls downhill to engineering it's because the political side believed it was required; you need to accept that. Likewise if the political manager gets pushback they need to understand that the issue is real.

So taking a step back, the article is complaining that you should have managers that understand what engineers do. I'd flip that - we need engineers that understand what managers do. Engineers are not special. Neither are managers. It takes people working together to get stuff to happen, period.

Re: How to drive away your best engineers

#245

Post by drc500free »

skeeter2020 wrote: post #189

I get why these "Managers are so clueless!" posts feel good and are often well received. One thing that would help is if technical talent didn't naturally position leadership as comprised of people who are totally different from them, who intentionally strive to create an unpleasant counter-productive environment that makes it hard to create and deliver software. I get the pain expressed here, it's real, and the prob…

The day that engineers accept the reality of reporting to investors who only care about cashflow and time is the day all those MBAs and managers go away. Until then, someone always needs to impedance match between the world of ROIC and the world of hackers.

Re: How to drive away your best engineers

#246

Post by Jensson »

Buttons840 wrote: post #242
dalbasal wrote: post #62

Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…

> An effective 15 person team can outperform a 150 person team Which is subtly different than saying a 15 person team can do the same job as a 150 person team. The full story is the first 15 people (be they developer or project managers) will determine whether you need 150 people in the future. Naturally, all of my jobs have been at 150 companies (since that's where most of the jobs are), places where the earlier dev…

People who want to be managers tend to create solutions where you need to assign more reports to them. I don't think this is incompetence, it is a reasonable way to advance your career at the expense of the company, similar to how engineers tend to choose frameworks that helps their careers etc.

Re: How to drive away your best engineers

#247

Post by davesque »

woevdbz wrote: post #109

The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump ar…

This would only be true if finding another job was a simple (and reliable) process for most people. I imagine you might come back and say, "But finding another job should be easy for a talented engineer!" To which I would say, nope! Not true! The tech interview grind is often inconsistent and demoralizing. Even talented people might make a reasonable calculation to avoid the trouble and just stick with their current job.

Re: How to drive away your best engineers

#249

Post by therealdrag0 »

nevinera wrote: post #139
dalbasal wrote: post #101

Earlier quoted context omitted.

IDK. If you're in one of these too-small-high-pressure teams, and then all these extra "resources" get poured in... It can go quite badly too. IMO, engineers themselves are sometimes responsible by leaning on "we need more resources."

I think engineers often say "we need more resources" but mean "we need to have hired more resources two years ago".

Yap, I’m leading a project that could use more engineers (just two of us) cuz it’s going to be tight to hit an upcoming scaling deadline. But the thought of spending my time ramping up other engineers at this point doesn’t sound good.

Re: How to drive away your best engineers

#250

Post by dilyevsky »

ClumsyPilot wrote: post #116
woevdbz wrote: post #109

The underlying principle I've been using to understand this is, no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well. The opportunity cost of talented software engineers is much too high in general. This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump ar…

> no engineer worth their salt will be spending a material amount of time working at an organization that they don't believe utilizes their talents well So is everyone developing advertising at google is a second rate engineer?

In my time Ads org had some pretty interesting engineering challenges, relatively fast promotion track and good pay
Post reply on HN