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

51–60 of 316 posts

Re: How to drive away your best engineers

#51

Post by blowski »

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.

The Cynefin framework can be really useful for having this conversation. https://lizkeogh.com/cynefin-for-developers/

How well do the people executing the project know the codebase, data, and tech stack they're working with? How understood and confirmed are the requirements? The less those things are true, the less certain you can be with estimates. At the extreme, all you can do is poke the system and commit to providing feedback on what you've learned.

At the same time, you should be trying to make the system more lucid, both for yourself and new joiners on the team, such that estimates can become more accurate. The more senior you are as an engineer, the quicker you should be able to do that.

Re: How to drive away your best engineers

#52

Post by noduerme »

threatripper wrote: post #30
romanovcode wrote: post #9

Earlier quoted context omitted.

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated). What one developer can do in a week - two developers can do in two weeks!

It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.

Re: How to drive away your best engineers

#53

Post by quickthrower2 »

mwcampbell wrote: post #26
ozim wrote: post #20

Earlier quoted context omitted.

Not having team of six can be alleviated by setting realistic expectations. If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees. Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. Right, in that case, I'd probably give up my vacation instead.

Or keep deploying daily anyway so when everyone is out the production env. is pretty up to date and undeployed feature inventory low.

Re: How to drive away your best engineers

#54

Post by WJW »

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.

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 boss")

Re: How to drive away your best engineers

#55

Post by greenbit »

Gigachad wrote: post #49
noduerme wrote: post #45

Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It…

It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.

This. Oh definitely, this.

Re: How to drive away your best engineers

#56

Post by chrisseaton »

mwcampbell wrote: post #26
ozim wrote: post #20

Earlier quoted context omitted.

Not having team of six can be alleviated by setting realistic expectations. If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees. Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago. Right, in that case, I'd probably give up my vacation instead.

Why does anyone have to give up a vacation?

Unless you're building intelligence or defence software or something like that.

Re: How to drive away your best engineers

#57

Post by hibernator149 »

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.

If engineers are unwilling to commit to a schedule, then here are some things that might help:

- Make sure that the requirements are solid (you can't commit if you don't know to what you are committing)

- Make sure that the environment is consistent (I can't commit to a timeline if the people on my team are constantly rotated around)

- Ask the enigneers why they can't or don't want to commit and fix that

Re: How to drive away your best engineers

#58

Post by someguydave »

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…

Why would you want to drive away engineers?

Re: How to drive away your best engineers

#59

Post by hericium »

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…

> If you can't deliver then maybe you're not a good enough for the job.

I've seen more than once projects with ill-equipped team members. I've been one myself, too.

Even in established tech corporations, the process of team creation can be screwed up due to multiple reasons. I've seen DevOps engineers tasked with writing apps because PM did not checked what their role was. And that was a high-importance project in a huge, publicly traded, tech corporation.

Expecting engineers to estimate work they haven't done before ends up in guesstimation which is almost never correct.

PMs asking for estimations in pioneer projects create problems for themself, which they sometimes later blame on team members.

Re: How to drive away your best engineers

#60

Post by the_gipsy »

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.

There are so many actors and groups and dynamics and forces in effect in the relations that we commonly call "work", that trying to reduce it to a single purpose is laughably naïve.
Post reply on HN