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

91–100 of 316 posts

Re: How to drive away your best engineers

#91

Post by LadyCailin »

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.

Yeah, but if a business owner decides “x” is the purpose of work, and literally no one wants to do that because of the conditions that the business owner has created (especially if the conditions are tangential to x), then that is the business owner’s problem, not the employees problem.

Re: How to drive away your best engineers

#92

Post by ebiester »

a-walker wrote: post #77

> 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 req…

Forecasting looks like this: https://medium.com/expedia-group-tech/monte-carlo-forecastin...

It’s running through simulations based on previous team behavior to give a range.

Re: How to drive away your best engineers

#93

Post by forgotusername6 »

katzgrau wrote: post #44

"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and…

There are different types of hard. Digging ditches is hard work, getting people to do what you want them to do is hard work, writing complex software is hard work. When engineers think about hard work they usually think about it being intellectually difficult. It isn't arrogance, more that they are just focusing on the definition of hard work that they are used to.

Re: How to drive away your best engineers

#94

Post by JonChesterfield »

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…

Manager (or possibly his boss) needs a leaving present of the mythical man month

Re: How to drive away your best engineers

#95

Post by magicalhippo »

bratbag wrote: post #24
threatripper wrote: post #16

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.

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 assuming those restrictions.

Most of the time this is all he needs.

Re: How to drive away your best engineers

#96

Post by JonChesterfield »

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…

Security above output is a big deal. Put email behind the unreliable VPN on the magic corporate laptop of extra slow booting when we used to read it through an arbitrary web browser and revel in the increase in tail latency on replies. From minutes to days.

Re: How to drive away your best engineers

#97

Post by code_runner »

kqr wrote: post #90
a-walker wrote: post #77

> 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 req…

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.

Re: How to drive away your best engineers

#98

Post by spookierookie »

plus:

* Put them oncall on Xmas when they are new to the team (because teams are like army where the newcomers must suffer)

* be pedantic and hysteric in code reviews

* have meaningless processes that drag for hours. E.g. iteration planning that goes on for 2 days

* enforce nebulous "principles" (e.g. anything by RC Martin) because manager that hasn't touched code in a decade went to a show of him and was "impressed"

* have clueless architects design systems and processes. Specially anything microservices-related.

* have lesser engineers run the teams and processes. The kind that is good in Public Relations but have little or no real skills

* have id-politics matter more than anything else. E.g. most important problem this week being why women employees got a pink promotional cup and how is that discrimination

* do not allow access to web mail and a gazillion other sites because "security"

* do not allow local code (if you see this - run) and instead promote "dev" in remote controlled envs

* foster a blame culture (who did that?)

* foster a toxic culture where politics run the place

* fire good engineers and keep the above mentioned Public Relations ones

* have and promote managers that are good in gaslighting and not much more

* work for managers and with colleagues that you'd advise your kid to stay away from because they cannot be trusted

* hire titles with no real experience and many ego issues and push them hard through the ladder. Classic example PhDs straight from uni.

Re: How to drive away your best engineers

#99

Post by sokoloff »

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…

I think the mismatch is partly that your early experiences (family, teachers, and team leads) are with leaders who literally know more than you about most topics and could do any task they’re asking you to do. That imprinting is strong.

Then, when you get to interact with Directors and VPs who have teams across 5-20 disciplines and the senior leader could be an expert in a maximum of one of them, you start to question why this person can’t do your job and therefore think, they must be an idiot.

They might be, but it’s more likely they’re past the point where they are more subject matter expert in the field than the people they lead.

Re: How to drive away your best engineers

#100

Post by jen20 »

threatripper wrote: post #16
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…

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.

> A total nightmare for project management.

If there is not enough information to make informed schedules, the only reasonable option is to DO MORE RESEARCH, not guess. Better still is to not try to create some master plan that requires things like this to be known at all.

Post reply on HN