Live data from Hacker News

How to drive away your best engineers

blog.hulacorn.com

31–40 of 316 posts

Re: How to drive away your best engineers

#31

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…

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

> Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline.

So you're saying that 1) engineers have to be forced to "commit to a schedule" and b) that schedule then turns out to be fantasy.

I want you to think harder about what you said and where the problem actually lies. Maybe the engineers know something, about what's knowable upfront, that you don't.

Re: How to drive away your best engineers

#32

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…

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

> Nobody can work with engineers who are unwilling to commit to a schedule

Inability to state a time estimate is not the same as unwillingness to commit to a schedule. You sometimes do pioneering work which you really have no clue how long can take.

Estimating just writing code or doing something repetitive is easier than estimating research + prototyping/engineering.

Re: How to drive away your best engineers

#33

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…

Your list is more likely to contain your personal pet peeves - reasons you personally wouldn’t want to work in a company. There are plenty of people who’d say the absence of those things would be bad.

That highlights the real problem. Growing a company is very hard.

Re: How to drive away your best engineers

#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 anyone primarily responsible for 'labor' vs. 'management'.

The 'best engineers' empathize with the perspective of 'management,' that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.

Re: How to drive away your best engineers

#35
post #24

Earlier quoted context omitted.

Nobody can work with engineers who are unwilling to commit to a schedule. Often it is very hard to make them commit and even if they do initially they often start missing deadline after deadline. A total nightmare for project management.

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

Re: How to drive away your best engineers

#36

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…

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 :)

Re: How to drive away your best engineers

#37
post #4

I totally agree with this. I am in a situation right now where the skip level manager is asking to schedule meetings every other day to talk on a problem that requires research. They want to talk about a solution and not letting us find one. Another one is defining aggressive timelines when I don't even know what to solve. Obviously the timelines were shot to hell in the worst way possible.

It's a mentality and culture difference. Manager-type people solve issues by having meetings, lots of meetings. Their work is accomplished in the meetings. The can have 7 meetings on the same day, each about a completely different subject and still manage to get something done.

Programming on the other hand requires uninterrupted blocks of time. Working on 7 projects on the same day just means you have 7 projects that didn't progress. Having to sit in a meeting every other hour means you're not getting anything done between meetings because context switching takes time.

Re: How to drive away your best engineers

#39
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…

> 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?

Post reply on HN