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

101–110 of 316 posts

Re: How to drive away your best engineers

#101

Post by dalbasal »

pid-1 wrote: post #82
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…

> If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad. I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.

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."

Re: How to drive away your best engineers

#102

Post by jen20 »

threatripper wrote: post #35
bratbag wrote: post #24

Earlier quoted context omitted.

I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.

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…

Funnily enough, engineers want to do actual work and not manage up for hapless Machiavellian middle managers.

Re: How to drive away your best engineers

#103

Post by woevdbz »

astura wrote: post #50
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…

This article could be a parody with how shockingly naive it is. The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.

?? Where is there any reference to amusement or self-actualization in TFA?

Re: How to drive away your best engineers

#104

Post by bobthepanda »

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…

MFA is ideally combined with SSO so you auth at most once a workday.

Re: How to drive away your best engineers

#106

Post by Dudeman112 »

threatripper wrote: post #35
bratbag wrote: post #24

Earlier quoted context omitted.

I don't agree. Its perfectly reasonable not to have any idea about an estimate until after an investigation or prototype has been produced. Demanding an estimate up front for something totally new just makes you look inexperianced or bad at managing engineers.

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…

I'm glad you're not my manager and that I can choose not to work for managers like you

Re: How to drive away your best engineers

#108

Post by kqr »

code_runner wrote: post #97
kqr wrote: post #90

Earlier quoted context omitted.

This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small variations mean you're not done exactly when you said you'd be done. If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.

I’m interested but not totally sure what you mean here. Do you have a source or name for this intervals/calibration stuff? I’ve always had issues when people are using hours instead of points. The one time we properly used points on a team it went really well.

A good reference is Douglas Hubbard's How to Measure Anything. The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.)

This is really easy to practise and test too, since all you need are a bunch of questions where the answer is known, but you are uncertain of it. Then you can guess a range in which you are 90 % certain the true answer lies, and after 10 such questions, you should be correct roughly 9 times.

Points are a way to do this, but I prefer engineers who are calibrated. It's very powerful to ask someone for a calendar day when something will be done (or really just about any other question about anything), and be able to be reasonably confident in the span they respond with.

Re: How to drive away your best engineers

#109

Post by woevdbz »

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 around because they felt their "world class" talents weren't being put to good use, some unsuccessfully, but some rather successfully fooling their way through the ranks of management. But I've also (more frequently) seen disillusioned, extremely talented engineers leave an org that was paying them obscenely well already, but was making them feel like they were wasting their time, for a shot at a startup dice roll which does not pay off as well (on average).

Re: How to drive away your best engineers

#110

Post by jmyeet »

On the issue of estimation, you want to drill down to:

1. Why are you asking? and

2. What happens if I'm wrong?

I subscribe to the view that you can either launch based on features or launch based on time. You cannot do both. If your product is a compiler and you want to support, say, ARM and that requires a bunch of work, you have to choose to release a version at a particular time or to launch with that feature complete. Many people just don't get this.

You can try and hit a time goal by resourcing but this is often done in a counterproductive way eg by throwing bodies at the problem when it's far too late and as we know that can just slow down the process as the people who know what they're doing have to ramp up the people who don't.

Often you're being asked for an estimate because management wants to ignore this and is fine with forcing their team into "crunch time" to meet some arbitrary goal.

As for what happens if I'm wrong with an estimate, basically am I going to get "punished" for underestimating? Be that through getting a bad performance review, a lower bonus, a lower stock grant or whatever.

If so, you've just created an incentive structure for me to completely overestimate because there's typically zero benefit in overdelivering (other than a perfunctory "ata boy"). So if I think something will take a day, I'll end up estimating 1 week, maybe even 2.

You should build some buffer into any estimate but if you are punished for taking longer and not rewarded for being faster, what do you think is going to happen?

Now you might have a bug to fix a typo on a website and if you say that'll take a month obviously that won't fly but a team will generally settle on estimates that are really large without being large enough to draw scrutiny.

Even then, many managers will take an estimate of 6 days and negotiate down to 3 days without knowing what went into that estimate. That too will lead to buffers being padded.

If someone takes longer through no fault of your own (eg it just turns out to be really complicated in a way you couldn't anticipate) then I've seen it more than once where a manager will throw that engineer under the bus to save their butt from their own management.

In short, estimates are an almost sure-fire way to create an adversarial environment between engineers and their direct management.

Post reply on HN