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

131–140 of 316 posts

Re: How to drive away your best engineers

#131

Post by threatripper »

greenbit wrote: post #65
theshrike79 wrote: post #36

Earlier quoted context omitted.

In those cases the correct answer is "Dunno, but I'll have an estimate by tomorrow after I do some prototyping". Then you do the janky prototype and try to extrapolate how long will it take to finish it properly. Then double that and be the miracle worker who delivers in half the time :)

But do not under any circumstances be tempted to demonstrate said janky prototype, unless you want to get re-tasked while said janky prototype gets merged into the build because 'schedule' .. and then be haunted by the damned thing for at least the next three years

I know exactly what you're talking about. The first rule of the meeting is "shut up" and the second rule is "keep silent" and "watch your mouth". I don't know why it is so hard to stick to those simple rules when the solution to the engineering problem seems so obvious.

Re: How to drive away your best engineers

#132

Post by Ensorceled »

hibernator149 wrote: post #46
hericium wrote: post #12

Agree with most points but one which is making a manager do coding/shipping. Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one. Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understan…

- Manager: How long would it take to migrate from A to let's say B? - Me: How would I know that? - Manager: Just make an educated guess. - Me: Maybe X months? I really don't know. - Manager writes down X. - Me makes a mental note to not trust Manager again... Maybe it's better to have any plan than to have no plan, but having a plan based on known bad data can't be the solution. Dear Managers, if your plan requires d…

- Manager: How long would it take to migrate from A to let's say B?

- Me: What do we want to accomplish from the migration? I'm assuming cost reduction?

- Manager: Yeah, the guys at B are much cheaper.

- Me: Ok, give me until EOD Friday to do some investigation.

- Manager: EOD Thursday would be better, don't need a full roadmap, just enough for an ROI. I'll flip over the CEO's spreadsheet that she's using for the calculation.

- Me: This means Feature X is dropping from this sprint.

- Manager: Yep.

Dear Mes: Grow up and participate in the process rather than starting off with snark.

Re: How to drive away your best engineers

#133

Post by DoubleGlazing »

> Stop estimating.

This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure.

I've had so managers who just don't get that there are so many unknown variables in the software development process.

No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of not knowing what you're doing. Estimate long, but come in short? Then you are expected to shorten all future estimates. Estimate right? Nah, that never happens.

Every price of software developed is different and will take a different amount of time to be developed. It is really quite stressful for a dev who is working their ass off to hit difficult targets in an organisation that refuses to be flexible about that sort of stuff.

Re: How to drive away your best engineers

#134

Post by legulere »

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.

Especially managers should know that this is not true. Business is a lot about politics and egos, and especially managers are the ones engaging in it.

Re: How to drive away your best engineers

#135

Post by threatripper »

magicalhippo wrote: post #95
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.

When I'm asked by my boss to estimate, I break it down for him. This part here I'm confident is 1-2 days of work, this part here can potentially be tricky so could be 1 day could be a week, and this part here I can't tell without digging into the details. If this is based on a customer request I'll try to find some restrictions he could take back to the customer to narrow the scope and provide a better estimate assum…

What if he asks you for a number instead of a range? After all you have to use the company template to present your project and that does not have ranges on it.

Re: How to drive away your best engineers

#136

Post by 23B1 »

EnKopVand wrote: post #72
astura wrote: post #50

Earlier quoted context omitted.

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.

I think the point here may be that when you’re dealing with an occupation in which the best engineers can pick and chose. Then you’re likely to lose your best engineers unless you’re exceptionally good at managing them. Especially if you introduce boundaries and restraints. I’m not sure it’s naive to view the world like the author does. I’ve worked both sides of the fence, and while I’m now back in software developme…

> the best engineers can pick and chose

Sorta. I would take a less-qualified but more personable engineer over their more capable peer any day of the week, for the aforementioned reasons: engineering isn't the only skill required – those who don't insist on managerial perfection don't actually need a lot of managing as a result. It's a positive feedback loop.

Also if engineers think we don't check references and backgrounds anymore – including reputation – those days are long past. It's too much of a liability to have the 'talented asshole' as part of a team anymore.

> Especially if you introduce boundaries and restraints.

Boundaries and restraints are a professional reality.

> So when/if management go down the route of treating Software Development like they treat any other department.

It's this exceptionalism that earns engineers the reputation of being jerks, and creates a negative feedback loop. Want to be free and clear to operate without too much bureaucracy? Play the cooperation game. This is as true with engineering as it is literally any other thing that requires more than one human.

Re: How to drive away your best engineers

#137

Post by twobitshifter »

kayodelycaon wrote: post #113
netfortius wrote: post #84

Just reading the beginning of the article, and I couldn't help re-re-emphasizing how critical it is - as a manager at any level - to conduct "exit interviews" with your report-tos and other dependents, right when taking over a group. This was one of the best methods I leveraged, in my over 25 yrs career, in all sorts of low or senior management positions, i.e. serious "exit interview" with any team I got anew, which…

I think some nuance is being missed here. I’ve had a manager come in and ask questions like this and immediately turn around and use the feedback to fire people and rearrange the department.

That sounds like a good thing or was it too fast? Most companies do nothing to address the problems following exit interviews and them end up with terrible retention

Re: How to drive away your best engineers

#138

Post by FrankyHollywood »

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…

The question is often 'how long does it take to implement'. Engineers know if it is more or less clear what the functional requirements.

In practice, workdays are constantly interrupted by meetings. An 8 hr workday is effectively 2-4hrs product building. Than there are unforseen deployment problems, some requirements change, solve merge conflicts, perform code reviews, frameworks need vulnerability updates, etc.

An experienced PM knows this and should not use implementation time as project duration.

Re: How to drive away your best engineers

#139

Post by nevinera »

dalbasal wrote: post #101
pid-1 wrote: post #82

Earlier quoted context omitted.

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

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

Re: How to drive away your best engineers

#140

Post by elcritch »

raisin_churn wrote: post #128
noduerme wrote: post #52

Earlier quoted context omitted.

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.

I refer you to the discussion a few days back on people not being accurately modeled as rational agents: https://news.ycombinator.com/item?id=32181987

Companies and entire markets follow similar patterns of only having bounded rationality, IMHO. Markets can also have decades of slack or delay from stimulus to outcomes. Take the slow decline of Boeing after acquiring McDonnell Douglas and their MBA heavy structure. https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-merg...

Post reply on HN