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

121–130 of 316 posts

Re: How to drive away your best engineers

#121

Post by kidgorgeous »

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?

Yes. First rate engineers are designing rockets at Space-X

Re: How to drive away your best engineers

#122

Post by WJW »

crowdyriver wrote: post #73
mwcampbell wrote: post #10

> In my opinion, Have a minimum team size of six. So I guess this post is only for big companies and VC-funded startups. I'm the technical cofounder of a tiny bootstrapped company, and for now, I'm the only engineer. Being the sole engineer is stressful, but it's currently necessary, and I think it's worthwhile to maintain the control and integrity that we'd probably have to give up if we pursued the funding to hire…

Currently at my company I'm the only one dev. Advantages and disadvantages, but having all code at one head really simplifies communication overhead. I hope I keep complexity sufficiently down so we won't need more than 2 or 3 more engineers.

What's the plan for if you get hit by a car and can't work anymore?

Re: How to drive away your best engineers

#123

Post by elric »

donw wrote: post #27
tmikaeld wrote: post #23

Earlier quoted context omitted.

There's a huge difference between a team of 6 full-stack developers and a modularized team where everyone has their own projects.

Six is where you start figuring out how you're going to split the team. Eight is where you actually make it happen (either into 4+4 or 6+2).

Agreed. Teams that are any bigger than that inevitably run into communication problems. Small teams are good for close cooperation. Big teams are good for wasting time.

Re: How to drive away your best engineers

#124

Post by threatripper »

SideburnsOfDoom wrote: post #39
threatripper wrote: post #35

Earlier quoted context omitted.

We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak char…

> Many weak characters break that way. The trick is to make them choose their own deadline and fail. That way you take away the scapegoat "they set unrealistic deadlines" because the engineer digged their own grave. IDK, but this seems just psychopathic?

Yes, very much so. Although I wonder if those involved are aware of this.

Re: How to drive away your best engineers

#125

Post by nonrandomstring »

FrankyHollywood wrote: post #78
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…

The book would be an anthropological study. Having worked as a freelancer for more than 15 years, seen many companies from startups to large finance I see these patterns over and over again, it's like human nature. Totally unrelated companies have these exact same flaws. Clueless middle management driven by money and ego making these destructive decisions. At the same time, a group of engineers at a startup without m…

Yes, I think it would. Anthropology.

Way too late in life I discovered what anthropologists actually do after stumbling upon Alan McFarlane's lectures about "The origins of Modernity" [1]. Nobody ever made history seem so interesting and clear why What's Past Is Prologue. A big shout-out to all anthropologists!

https://fortnightlyreview.co.uk/2013/07/anthropology-empire-...

Re: How to drive away your best engineers

#126

Post by WJW »

mwcampbell wrote: post #26
ozim wrote: post #20

Earlier quoted context omitted.

Not having team of six can be alleviated by setting realistic expectations. If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees. Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. Right, in that case, I'd probably give up my vacation instead.

This is only a feasible plan for people without any children or committed relationships though. Telling your spouse that you'll skip the vacation because work is more important than them will not go over well, for obvious reasons.

Re: How to drive away your best engineers

#127

Post by threatripper »

hericium wrote: post #59
threatripper wrote: post #35

Earlier quoted context omitted.

We don't want to manage engineers we want to manage projects and projects have budgets and deadlines. If you can't deliver then maybe you're not a good enough for the job. If you can't even promise then why are you still working at our company? One of the best ways to drive away engineers is to make them commit and then watch them fall into misery when they desperately try to somehow make the deadline. Many weak char…

> If you can't deliver then maybe you're not a good enough for the job. I've seen more than once projects with ill-equipped team members. I've been one myself, too. Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a…

They are asking because they have been asked themselves. To me it seems like a chain of incompetence from top to bottom, from bottom to top. Everyone is stretched beyond their abilities. The whole company is a house of cards. But yet it keeps on working and often it delivers results that keep everything else up and running. I don't understand why it works this way but it does.

Re: How to drive away your best engineers

#128

Post by raisin_churn »

noduerme wrote: post #52
threatripper wrote: post #30

Earlier quoted context omitted.

It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.

If MBAs weren't economically efficient, the market wouldn't make so many of them and companies wouldn't pay them so much.

Re: How to drive away your best engineers

#129

Post by bloggie »

23B1 wrote: post #34

Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company's hiring and resource management, and a perfect understanding of the software's requirements. These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but a…

I'm not sure I would want to run a company without any gantt charts or deadlines. Management needs to know when a project becomes unmarketable or unsustainable so that project can be killed and resources moved to more viable projects. These decisions depend on variables that engineers can't see, though budgets and timelines are a few of them. Of course engineers can't take it personally when a project is killed either - some projects turn out that way. The best engineers know this. Your comment highlights well the narrow view of the subject article.

Re: How to drive away your best engineers

#130

Post by sascha_sl »

LaurensBER wrote: post #6

Not included in this list but definitely worth mentioning; - Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors. - Not involving your current team in decis…

There hasn't been a single job where I didn't have to explain Git to someone. Or that Git is not GitHub.

Wherever I was somehow in charge of some authentication / account management (never been my primary responsibility, but "people who know cloud" teams often get that honor anyway) I have always had someone who didn't understand MFA. Either they assumed because MS Authenticator sends them a push, AWS should send them a push or they would have a clock desynced so hard that the most generous TOTP grace windows couldn't save them.

My partner is in a place right now that had to be introduced to python dependency management. Really. No containers or anything like that either. Just alternate runing the script and installing the latest of a package until the import errors disappear.

I really don't mind tutoring, but many of these people also would rather wait 20 minutes for you to respond than 5 minutes on Google. Or even your internal documentation. That's linked in the Slack channel they're asking. It drives me nuts people value their peers time so little.

Post reply on HN