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

71–80 of 316 posts

Re: How to drive away your best engineers

#71

Post by wildrhythms »

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…

Don't forget management having engineers stop what they're doing to build elaborate dashboards to track OKRs, satisfaction metrics, whatever else, only to never look at it and only parade it around to other managers as a show of how in-tune with the product they're supposed to be.

Re: How to drive away your best engineers

#72

Post by EnKopVand »

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.

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 development I do see the appreciation for my experience with creating the most business value out of your resources that managers come with. The thing is, though, if I don’t have to work in a place with too much bureaucracy or too many constraints then I’m not going to do so. I obviously try not to be an asshole about it. I don’t follow the company dress code in the basement troll factory where they placed IT, but I do have a suit at work that I can change into whenever I leave the “cave”. Those sort of things, so naturally I’ll play a long way in regards to what management want, but I’m never going to do estimates by the hour until the job market actively forces me to do so. Which likely won’t be in our lifetime. So when/if management go down the route of treating Software Development like they treat any other department (which like you state also are under significant constraint) then the company is just very likely to lose their most talented developers very quickly. I suspect that it would be (and probably is) exactly like that in any department, it’s just easier to get away with in engineering because we’re privileged enough to be able to leave our jobs today and have another good job by tomorrow.

Re: How to drive away your best engineers

#73

Post by crowdyriver »

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.

Re: How to drive away your best engineers

#74

Post by wildrhythms »

bryanrasmussen wrote: post #28
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…

Most engineers can guestimate, but I do know one that would say the following: no idea, I will have to do two days of research on the matter and come back to you with an estimate in standup the day after tomorrow. (really, he said exactly that one time, it was a wonderful expression of his character I thought) The person who just says no idea, and doesn't have a way to get to an idea, seems to have a very problematic…

I don't agree with this. If an engineer can't estimate how long something will take, usually that's an indication that your requirements are unclear, or there's a history of changing up requirements on people. What you've labeled as a limitation is probably an engineer being honest with you.

Re: How to drive away your best engineers

#75

Post by wildrhythms »

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

Manipulative, psychopathic behavior, and you are a bad manager.

Re: How to drive away your best engineers

#76

Post by wildrhythms »

pikaynu wrote: 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.

> defining aggressive timelines when I don't even know what to solve

I love this one. Someone is desperate to build a Kanban board to show their manager; who cares if the underlying projects are imaginary!

Re: How to drive away your best engineers

#77

Post by a-walker »

> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting.

What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort required to solve a problem and the general time it takes to solve them in order to do a forecast?

Re: How to drive away your best engineers

#78

Post by FrankyHollywood »

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 much management can go rogue and burn millions on fancy tech and frameworks without making anything useful.

The only successful projects I have seen is with a capable senior engineer in the team, who can listen and understand what a tradeoff is. If this senior is trusted by both the team and the manger the team can be effective.

Re: How to drive away your best engineers

#79

Post by SideburnsOfDoom »

wildrhythms wrote: post #75
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…

>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. Manipulative, psychopathic behavior, and you are a bad manager.

Yep. "I'm asking you to estimate this unknowable thing, pressure you to give me a small answer, and if you get it wrong, you're 'weak'".

This is tinpot-tyrant stuff. I saw that in a movie: "no, the German people have failed _me_, they were weak, and deserve to suffer for it".

Re: How to drive away your best engineers

#80

Post by [deleted] »

krapp wrote: post #68
WJW wrote: post #54

Earlier quoted context omitted.

That is just an opinion and not a statement of fact. There are many different types of people and not all people have the same motivation. A lot of people care quite a lot about amusement and self-actualization at work. What a business owner might want does not change that. (and let's face it, there are many many business owners who care way less about business problems being solved than they care about "being the bo…

> What a business owner might want does not change that A business owner decides what the purpose of the business is, and what constitutes useful "work" within that context. If I'm hired to do x,y and z and I decide my motivation is rather to surf the web all day or spend all my time on personal projects, that doesn't change the purpose of work, it just means I'm not working.

[deleted]
Post reply on HN